I have a daily newsletter I send out to a list of people each day. I use PHP and the PHPMailer object to send the emails.
This has been working fine up until today when I didn't get an email (test) and I checked the logs to find that intermittently I was getting SMTP errors back from
mail->Send();
Method of the class on SOME of the people - not all of them.
All of the emails were exactly the same size (length in characters) apart from their name and email address.
The error details from
$mail->ErrorInfo;
Included these two errors
SMTP Error: Data not accepted.<p>SMTP server error: 2.1.5 Ok
SMTP Error: Data not accepted.<p>SMTP server error: </p>
Why there are broken P tags in the error message I have no idea - also why the first error has OK in it??
However other people in the loop had emails go out fine.
Also when I put the script into test mode so ONLY these failures were emailed out (so one call of the script = one email to one person), I found no problem and the people got their emaail.
Now I asked tech support what the error meant and got back "Google it" and I can't find the error 2.1.5 OK anywhere. I don't really get why it says OK after an error either.
As a test for tomorrow I put a test in for a failed Send and then a Sleep for 5 seconds with a retry.
I don't know if this will help but I thought that maybe my SMTP server which is on the same server as my script (Rackspace VPS Linux) was having temporary issues connecting so a sleep might be handy in this situation.
This is the first time I have had this issue, I haven't rebooted APACHE or my server (or mailserver) and before this script I had another one send out 403 emails without any problem.
It would be nice to know what the error is and why it happened though.
Rob
That error is defined exactly where you would expect it to be - in the RFC that defines SMTP error codes. 2.1.5 means "Destination address valid". That it starts with a 2 means it's not an error as such, but a response code - warnings and errors start with 4 and 5. Why you got it, I don't know, but it certainly seems it was not expected in that context. Mail servers often have problems - they run out of disk space, get swamped by spam filtering, and this is why mail servers have queues. Sending directly using PHPMailer's SMTP class is not appropriate for high-volume sending - using SMTP is fine, but point it at a proper (nearby) MTA that can handle deliveries properly.
As for the garbled ErrorInfo content, I suspect you are using an old version of PHPMailer - the debug output has been cleaned up fairly recently. Another thing that changed lately is the handling of errors during single sends to multiple recipients (e.g. BCCs) - it's now much more likely to get to the end of a long recipient list without giving up than it was before.
Related
PHPMailer 5.2.28
Running inside Zen Cart PHP based ecommerce system.
I may be misunderstanding things but I'm stepping through PHPMailer when I accidentally mistype the host or port number and the useful error message that is created gets discarded before PHPMailer returns from Send().
The sequence of events is:
Create PHPMailer instance with Host = 'mistaken-smtp.gmail.com', everything else normal and try to send an email.
smtpConnect() calls $this->smtp->connect
in class.smtp.php the connect() function sets a custom errorHandler: set_error_handler(array($this, 'errorHandler'));
The call to fsockopen() fails because of the mistyped hostname
errorHandler is invoked, calls $this->setError($notice, $errno, $errmsg) with a useful message like 'cannot connect to host mistaken-smtp.gmail.com'
Because the connection failed, connect() then calls setError itself (line 319), overwriting the error object set by the errorHandler but still has some useful information about what caused the connection failure, and returns false.
Because $this->smtp->connect returned false, PHPMailer.smtpConnect skips the workhorse body of the function and skips to line 1727 where it calls $this->smtp->close() and will return false.
The call to $this->smtp->close causes the smtp class to complete wipe out its error object with $this->setError(''); .. it's here that any useful error messages get completely lost.
Because smtpConnect() returned false, PHPMailer.smtpSend throws a phpmailerException on line 1558 which is caught in postSend() on line 1352 and PHPMailer.setError is called with the exception's message, which by now is a rather unuseful "SMTP connect() failed. https://github.com/PHPMailer/PHPMailer/wiki/Troubleshooting"
PHPMail.setError does try to inspect $this->smtp->getError() on line 3273 instead of using the plain $msg passed in, but because the close() earlier wiped out the error details in the smtp object, PHPMailer.setError simply sets ErrorInfo to the unhelpful error string from the exception.
This behaviour seems to have been around for ages so I imagine no-one has cared enough to address it in detail. I can certainly work around this but it seems buggy. Is there another way to get error info out of PHPMailer in this case?
This came to my attention because we hit some kind of quota limit with gmail, trying to mailshot via smtp.gmail.com sent 100 emails OK but then repeatedly failed to connect, the only error message coming to our code being 'SMTP connect() failed'. In our case the hostname, port etc were fine (unlike the fictional case above) but the gmail server refused the connection and the error handling I mentioned above was invoked, it's just hard to reproduce easily. It would have been very valuable to get the actual SMTP error message returned that was lost due to the dodgy error handling I outline above. (For anyone else hitting this, I spent an hour on live chat with google support to be told to use smtp-relay.gmail.com instead of smtp.gmail.com and this does appear to get around the quota problem.)
I'm aware there's a version 6 which may not contain this behaviour, but as it's a major breaking release and we're dependent on the integration of 5.x in our ecommerce system and upgrade is not possible right now.
I am currently in the process of doing a project in magento.
I have a problem with my contact form: emails are not sent to me.
I did a test and I still get this message:
Unable to submit your request . Please, try again later
It's probably because an exception is thrown as you can see in the file
app/code/core/Mage/Contacts/controllers/IndexController.php in the postAction() function, you should try to debug from here.
Maybe the contact email failled to be sent (if you are in localhost and have no mail server?), that could cause the exception that shows this error.
I've been struggling with this for a day as nobody gives a clear answer on the topic.
In order to get it working there are 2 options:
Configure smtp server for email sending using smtp pro extension from Magento connect
Make Magento use the SendMail function of the webserver
As the first option didn't work for me, as my hosting provider somehow block the smtp outgoing connection, I needed to use the SendMail function.
The quick and dirty trick I used, was to change /app/code/core/Mage/Core/Model/Email/Template.php line 116:
Zend_Mail::setDefaultTransport($transport); → //Zend_Mail::setDefaultTransport($transport);
After this my error message at the contact form was gone and I received
the email correctly.
Be carefull: This is not a good solution as it will be undone at a Magento update. Also it was not tested for the other email functions of Magento.
Whenever a new user tries to create a new account, they get this message
Tried to send you an email but failed!
I tried setting up an email and using the smtp settings in Site
Administration -> Message output -> Email and that did not work.
I called my Host company (inmotion hosting) and they verified that my
settings were correct.
I tried just leaving the settings blank in email so that the phpmailer would send the emails, but that is not working and I still get the same message.
I have searched all overand I cannot find any helpful information on why this is happening,
but I find A LOT of people who are having this issue.
This has turned into a MAJOR show stopper and I am wondering what avenues I have to troubleshoot this. Does anyone have any information on how this is fixed?
Thanks in advance.
It might be missing a "from" email - have you got a support email set up?
/admin/settings.php?section=supportcontact
Or go to Site Administration > Server -> Support contact
I've had a similar issue. It works fine for the first three users created (in quick succession) but then fails for a few minutes. Enabling debugging (Site Admin -> Development -> Debugging page) showed that this was due to timeouts:
Debug info:
Error code: auth_emailnoemail
Stack trace:
line 463 of /lib/setuplib.php: moodle_exception thrown
line 106 of /auth/email/auth.php: call to print_error()
line 70 of /login/signup.php: call to auth_plugin_email->user_signup()
Output buffer: profile_field_PC<pre> SMTP -> ERROR: Failed to connect to server: Connection timed out (110)SMTP connect() failed. </pre>
This appears to be an anti-spam "feature" of the Amazon SES service we were using, which we will need to get around.
I know this is an old post but I will add my solution and give many thanks to Russell for that part of it.
This site had been moved over to Bluehost and come to discover that client did not set up an email account for Admin User - so in addition to checking that there is an email in the Admin settings, also verify that that email address exists and is reachable!
I run three Magento web stores. All the orders e-mails are working just fine, with the exception of 7 e-mails that didn't even got sent from the webserver. Upon investigating the issue I discovered the following logs:
Magento log:
2013-08-08T11:44:59+00:00 ERR (3):
exception 'Zend_Mail_Transport_Exception' with message 'Unable to send mail. ' in /var/www/website.com/lib/Zend/Mail/Transport/Sendmail.php:137
Postifx log:
Aug 8 12:44:59 bv-webserver postfix/sendmail[18647]: fatal: sales#website.com(33): No recipient addresses found in message header
Aug 8 12:44:59 bv-webserver postfix/postdrop[18648]: fatal: uid=33: malformed input
This is very strange, because hundreds of e-mails were sent just fine and only these 7 got this exception. In some cases the clients just purchased again from the store and then received the e-mail as expected.
I thought it could be a resource problem. But I run the newrelic agent and the server is at 20% load at most during peak hours (both memory and processors).
Edit: Forgot to mention, I run nginx with php-fpm.
You'll always have an issue if you try to send emails without a recipient address. Postfix is telling you:
8 12:44:59 bv-webserver postfix/sendmail[18647]: fatal: sales#website.com(33): No recipient addresses found in message header
Fix that and you should be Ok.
You might need to look into why the application apparently lost the email addresses for the seven transactions in question.
When I execute my email script via browser a timeout fatal error is returned (unless I drastically increase the execution time, then it will run ok, not the solution I'm looking for). The email is sent tho, but it takes forever (5 min. average) to arrive (at my inbox)!
(Considering that via command line it works perfectly I think that SMTP at php.ini is certainly well configured.)
So this is the code executed by browser request:
<?php
mail('amatos#example.com', 'test subject', 'test body', 'From: Andre Matos <amatos#example.com>');
?>
and when I run this same (is it really the same? I'm starting to doubt myself) code via command line:
php -r "mail('amatos#example.com', 'test subject', 'test body', 'From: Andre Matos <amatos#example.com>');"
it works perfectly! The script runs, it stop and the email arrives instantly (2/3 seconds).
So, what can cause this difference and how to fix it? Any ideas?
Thanks in advance.
[edit] some extra info:
- the machine is windows
- the server is localhost
- php.ini is the same for both the browser and the cli instance
[edit2]
Thank you all for trying to guess which was the problem. I placed the question hopping that someone had the problem before and knew of something specific. Given nothing specific showed up and none of the suggestions really worked, I've decided to accept the one that allowed me to reach more conclusions about the problem... +1 For all your helpful knowledge/thoughts (/guesses) :-)
I've hypothesised some couses, but I used to linux and on windows I can olny guess:
php_cli and mod_php are 2 different binaries, mod_php can be slightly damaged
php_cli and mod_php use 2 different users, the network profile of apache user can be the problem (dns, firewall, proxy...)
your php script is on "problematic" location or contains some problematic character, but your cli script is by param, try to execute same script: php -f z:\path\to\php\mail.php
Given this note from http://php.net/manual/en/function.mail.php, it seems very likely that the issue is with the MTA and not PHP directly:
The Windows implementation of mail() differs in many ways from the Unix implementation. First, it doesn't use a local binary for composing messages but only operates on direct sockets which means a MTA is needed listening on a network socket (which can either on the localhost or a remote machine).
Perhaps it has something to do with the way the MTA is responding to the particular user, or user-specific firewall rules for outgoing mail connections on your machine. Can you run the command-line as the web server user rather than yourself? If so, does that re-create the problem from the command-line?
How about having the web server execute the command-line PHP rather than the parsed PHP file? (For example, perhaps you can run a batch script via CGI.) Does that solve the problem?
(Sorry that these are more guesses than definite answers.)
Just to be clear: The php-instance used by the script is the same as the one used by the command line code?
Many web hosts use smtp-relay, which will gather a bunch of emails and send them all at once, so it won't be strange behaviour if your mail is late. However, the long execution time is not normal.
Before you send your mail in the script make sure to print out the ini_get() of the variables SMTP, smtp_port, and sendmail_from and be certain that these are working values. PHP running on Windows does not have the benefit of sending mail out via Sendmail, and whatever the PHP devs cobbled together for it is sketchy at best.
I always like to test mail via telnet so I can see if the server is giving an error that is not being passed back properly by the client:
c:\> telnet smtp.domain.com 25
220 smtp.domain.com ESMTP Postfix
helo mailtest
250 smtp.domain.com
mail from: user#local.com
250 2.1.0 Ok
rcpt to: user#remote.com
250 2.1.5 Ok
data
354 End data with <CR><LF>.<CR><LF>
from: user#local.com
to: user#remote.com
subject: test mail
this is a test message
.
250 2.0.0 Ok: queued as 42AD8364FE0E
quit
221 2.0.0 Bye
Try to set username and password to "From" mail id. so it can authenticate and sends the mail quickly.
Have you tried PHP mailer?
In my observation its sends mails within seconds. Below example will give you a quick look how to use php mailer class.
include "class.phpmailer.php";
$msg="Hello! This is a test..."
$mail=new PHPMailer();
$email="someone#friend.com"; //person who receives your mail
$mail->IsSMTP();
$mail->Host = "localhost";
$mail->SMTPAuth = true;
$mail->Username = "admin#example.com"; //your mail id
$mail->Password = "sdfsd441"; //password for your mail id
$mail->SetFrom('admin#example.com', 'admin'); //from address
$mail->AddAddress($email);
$mail->Subject ="Test Mail";
$mail->Body = $msg;
$mail->IsHTML(true);
$mail->MsgHTML($msg);
$mail->Send();
EDIT :
In PHP manual they stated like this,
The Windows implementation of mail() differs in many ways from the Unix implementation. First, it doesn't use a local binary for composing messages but only operates on direct sockets which means a MTA is needed listening on a network socket (which can either on the localhost or a remote machine).
so that may cause delay? I think this link might help you.
My first guess would be that the browser version of your mailing has already a context or connections ready for the sending.
On the contrary, the direct (php -r) execution has to load the mailing context.
To confirm this idea, you can make a loop for sending 10 mails and check wether the mails after the first are much quicker.