I am running into a problem with zend mail sending functionality.
I have a functionality where we have set up some cron jobs and those cron jobs processes some php script and then sends a mail. Actually mails are going fine, but sometimes it is getting dropped into spam directory. After some research I have found that the return-path of mail body is causing problem. Since the mail sending script us as a root, so the return-path is root#domain.com and I want change it to support#domain.com
Is there any way I can achieve that.
Note: I did try to add that in headers, but it is not working.
It's return-path not reply-to... There's no such thing as reply-path :)
There are lots of parameters for being marked as spam and I'm not sure it's because of return-path only. You have to fix it though and you can try by altering the headers while sending:
$mail = new Zend_Mail();
$mail->addTo($this->email, $this->name)
->setFrom($message->from_email, $message->from_name)
->setSubject($message->subject)
->setBodyHtml($message->getHtmlEmailContent($subscriber))
->setBodyText($message->getTextEmailContent($subscriber))
->setReturnPath($settings->get('return_path'))
However SMTP servers might override this (gmail definitely does). Just open the email in raw and see if your header is there and if it's overriden or not.
If mails are marked as spam in your test account randomly you might want to check the contents and subject of your email. SPF records for your SMTP domain is important too.
See https://www.campaignmonitor.com/blog/post/1971/what-are-some-good-methods-for
and http://mailchimp.com/resources/guides/how-to-avoid-spam-filters/ for some details.
See this answer for the explanation of reply-to and return-path.
Related
I'm sending mails from PHP using postfix at ubuntu:
mail($to, $subject, $body, "Return-Path: <test#mail.com>");
Trying to set Return-Path header but it seems that postfix rewrites it to user#serverdomain
Found in postfix documentation message_drop_headers variable that by default has value bcc, content-length, resent-bcc, return-path
Tried to change it's value in postfix/main.cf but it gives warning on start:
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: message_drop_headers=bcc content-length resent-bcc
What could be the reason? How can I configure postfix not to rewrite Return-Path header?
Setting the Return-Path: header on outbound email is pointless because it will be replaced by the recipient's MTA. If you want to control what gets written there, set the envelope sender (traditionally, sendmail -f address#example.com)
In some more detail, when you send a message, there are two layers: An envelope, which specifies the actual recipients, and the message itself, which often contains headers with the same information ... but sometimes it doesn't, and sometimes those headers lie, blatantly.
When that message is delivered to a recipient, the receiving MTA (Sendmail or Postfix or Exchange or what have you) will copy the envelope sender information into the Return-Path: header, adding one if it's missing, and usually simply overwriting it if it already existed.
So it doesn't really matter how you configure Return-Path: on your outgoing server; in order to properly control this, you would need to control the receiving behavior on every server which delivers the message to a recipient.
As a trivial example, subscribe to a public mailing list, observe how the headers often say something like:
From: Popular mailing list <popular-list#example.com>
To: Popular mailing list <popular-list#example.com>
And yet it arrived in your inbox. How did that happen? Why, by way of the envelope recipient information. The list software basically adds a Bcc: to every subscriber, but also convinces the server to ignore the actual To: address in the headers. This is surprising until you realize that the headers actually don't matter, and only the envelope addresses actually control where the message is eventually delivered.
Briefly, the envelope is specified by the SMTP MAIL FROM: and RCPT TO: verbs which are defined in RFC5321 (originally 822) and the actual message (including all the headers) are communicatd in the SMTP DATA section which is really just pure data as far as SMTP is concerned at this point. Their specification is RFC5322 (née 822) and once a message is actually delivered, the receiving server will actually add some headers of its own, but the From: and To: headers are still just basically ignored.
The solution is to declare a smtp_generic_maps table in Postfix main.cf and list local user and corresponding email in it.
For example :
www-data test#mail.com
Look at https://www.postfix.org/generic.5.html for more infos.
Of course use only a real domain you manage and with at least a SPF record allowing sending mails from this server.
I stumbled on the following script today for sending an e-mail using PHPMail.
<?php
$to = "some_address#domain.com";
$subject = "Test mail";
$message = "Hello! This is a simple email message.";
$from = "my_address#domain.com";
$headers = "From:" . $from;
mail($to, $subject, $message, $headers);
echo "Mail Sent.";
?>
Above can be runnable through php mail.php and instantly you'll get an e-mail sent to $to from $from despite not needing to set outgoing/ingoing servers out.
It really intrigued me, since my CMS uses an SMTP outgoing server (well, same way Mail PHP does), which I need to set up with my Outlook SMTP username and password - some sort of verification.
However, about Mail PHP just.. sends an e-mail. To the address you set it as. From the address you set it as.
Looking at PHP docs it does not really reveal how it works. Does Mail PHP not have any issues with spamming since anyone can send anyone anything anytime programmatically without verification of the from identity?
EDIT:
It's rather funny the people in the comments were talking about the POTUS, since I had the exact thing in mind:
It did land in my junk folder, but I'm sure it isn't hard to make this look convincing enough and still be considered "oh damn spam filter lost my e-mail!"
The mail function uses the settings from php.ini. The details of this configuration can be found in Mail Runtime Configuration.
The defaults can be set in php.ini, although you can override them using ini_set.
I bet you sent the mail from a PHP script on a hosted server. That server probably has SMTP settings configured beforehand. If you would try this locally on a WAMP/LAMP server, you would have to do this configuration yourself, since PHP cannot read your Outlook/WhateverMailclient settings.
As stated in the comments, you can specify the sender/from address yourself. SMTP doesn't require this to be the actual sender domain, so that's why this works. The missing link is the pre-configured SMTP server of your host.
Some relay servers do check for this, and your mail might be blocked or sent to a junk mail folder. You can however configure this in your DNS to indicate that <Your server's IP> is indeed allowed to send email for <yourdomain>. For more information about that subject, you might want to read this question on ServerFault.
It uses the smtp protocol or send_mail, you can even configure what php should use to send mails in php.ini. It can send e-mail but the e-mail will end-up in your spam filter take a look to DKIM and SPF records for more information
This question already has answers here:
PHP mail function doesn't complete sending of e-mail
(31 answers)
Closed 7 years ago.
I want to script a simple registration form with activation mail and so on. But for some reason mail() doesn't send the emails, or my 3 different email accounts (hotmail,gmail,yahoo) don't receive them and therefore don't even put them in the spam folder.
Code:
<?php
$mailto = 'xxx#example.com';
$subject = 'the subject';
$message = 'the message';
$from = 'system#example.net';
$header = 'From:'.$from;
if(mail($mailto,$subject,$message,$header)) {
echo 'Email on the way';
}
?>
Everytime it outputs 'Email on the way' so mail() returns true, right? I really don't get it, I've even tried to turn off my little snitch (although I didn't block SMTP).
See this article by Jeff Atwood.
In short: Just because your code has handed the e-mail to a Mail Transfer Agent, it doesn't mean it will be delivered. Yes, mail() returning true means "accepted for delivery" - which means "Looks like an e-mail, I'll try to deliver this", not "It is delivered". Even the manual for mail() says:
It is important to note that just because the mail was accepted for delivery, it does NOT mean the mail will actually reach the intended destination.
Soooo: check your MTA (is the e-mail sent from your local computer?), try to send to a local address (if the address is local, does it get delivered?), try to send an e-mail from your mail client, using the same settings as your PHP script, try to send to a smaller mail-hoster which allows you tu switch off antispam (is it delivered outside your network?). Also, read that article, and check the points mentioned there.
Maybe your server is not configured to handle mail().
<?php
print phpinfo();
?>
and look at sendmail_path
You may need to add correct end of line characters to the Headers. It may be \n or \r\n
Check your phpinfo and/or php.ini for your mail settings and make sure you can send mail with whatever program php is trying to use. The function will succeed if the command executes but doesn't know if the mail actually went out.
Check your mail server's mail log. On Unix-ish systems, it's generally /var/log/maillog. On Windows, who knows, but there should be a log somewhere. If mail is returning TRUE, then whatever mail server it's connecting to has accepted the mail for eventual delivery. After that, mail() is no longer involved in any way and it's up to the SMTP servers to do the actual delivery.
In real world terms, mail() is you walking a letter down the block and dropping it into a mail box. Everything after that is utterly outside of PHP's scope and control.
If this is a linux server it's probably set up to send to the local mail queue. When I had this problem I got it working by adding an MX entry on the DNS server used by the linux servers which pointed to our ISP's mail server.
I had the same problem on Ubuntu and I resolved it following the next tutorial:
http://www.nixtutor.com/linux/send-mail-with-gmail-and-ssmtp/
I hope it works for you also.
A few days ago, i can send email via mail() function on my server. But now, mails doens't sending . There isn't anything at error log. I don't get any error. I don't know, why emails not sending.
What can i do? How can i solve this?
EDIT
Now i get all emails (about 18 mails :) ) . Why mails delayed?
PHP's mailer function does not actually deliver the mail. It simply hands it off to an SMTP server for that. Whether or not it actually gets delivered is not considered by mail(), it's just concerned with the hand-off.
If the SMTP server accepts it, then mail() will return true and pretend everything worked fine. The SMTP server may delete the mail, send it to the wrong place, route it through a tangle of other SMTP servers causing the mail to be delayed by a year, etc..., but mail() will still have said everything's fine.
The place to look for the cause of this is your mail server's own log. If there was a delivery problem, there'd be a list of each delivery attempt in there somewhere.
Have you tried doing this?
The problem seems to be that PHP use
the ini directive sendmail_from to set
the from email address in the SMTP
protocol. If this is not correctly
set, or if it does not match the from
header in the email headers, the email
is caught by spam protection software.
The simplest solution is to set the
directive during execution:
ini_set("sendmail_from", $email_from);
$headers = "From: $email_from";
mail($to, $subject, $message,
$headers);
Ok, now i have got 18 mails together. I don't know, why mails are delaying.
Maybe your receiving mailserver implemented greylisting (http://en.wikipedia.org/wiki/Greylisting) ...
Do you have access to the mailqueue or maillog of your webserver? In that case you can search for delayed or bounced messages there.
I have tested my email server on allaboutspam.com to see why the emails are beeing considered spam by hotmail and gmail servers.
The results was amongst other faults, the BATV.
This is the complete result from allaboutspam.com on my BATV:
BATV is a mechanism wherein an outgoing Email server adds a tag to the Envelope From address of all outgoing Emails. For example, if an Email address goes out with From address as <info#allaboutspam.com>, the Envelope From is changed to <prvs=SBDGAUJ=info#allaboutspam.com>, where 'SBDGAUJ' is the added tag. This tag is generated using an internal mechanism and is different for each email sent.
If any bounce is received by the Incoming email servers, they are checked to see if the Bounce address has the proper tag (in above case 'SBDGAUJ'). If not, the email is rejected.
Could somebody explain this in simpler words... How is it configured?
currently I have this setup when sending email with php:
$mail_message="text_text_text_text";
$headers="MIME-Version: 1.0"."\n";
$headers.="Content-type: text/plain; charset=UTF-8"."\n";
$headers.="From: Skuffen <no-reply#domain.se>"."\n";
$subject="SUBJECT HERE";
mail($email, '=?UTF-8?B?'.base64_encode($subject).'?=', $mail_message, $headers, '-fno-reply#domain.se');
This is a swedish language so you know (utf-8)...
Thanks
I think that you need to set this up in your Mail Transfer Agent. The PHP mail() command sends mail through the local sendmail (or compatible, like Exim, Postfix or Qmail) installation. That's where BATV needs to be configured.
If you are on a simple shared hosting, contact your hosting provider.