Re: Improvement suggestions for mail() delivery problems

At 13:34 11-5-2002, Manuel Lemos shared with all of us:

- I don't use Windows myself but many complains come from Windows users. They say that when mail() fails it just throws a "Server error" or something vague like that. So, one improvement suggestion is would be to put out more explicit error messages, stating the server address that was tried to connect or the SMTP error message that was returned.

A FALSE return error would be enough, IMHO. Putting out that information, would not be wise, as it may not be desirable to spit out, which server a user relays it's email by.

- Sometimes the problems are silent. No error returns but the messages do not get delivered.

Welcome to mail. No really - Any mailserver/sendmail daemon in queue mode, will return "OK", even if the address is nobody@non-existent.com. This may not even be your daemon, but it may be the provider's daemon, like: speling-error@majorprovider.com. They're queuing, relaying to internal servers, then find out, the mailbox is full, return a delivery failure, which could be picked up, say 2 mins later in /var/log/maillog. But php's mail() is still successfull. Php's mail() function is a convenience IMHO. PEAR has options to let you have more control and logging, still - you need to know how SMTP works (in theory AND practice) to be able to troubleshoot. That's the main problem if you ask me. The other one would be solid troubleshooting of these errors. "mail() returned true, but the user didn't receive it", can mean anything from procmail to usertypos. "Sendmail gives a 255 return status, but mail() returns true" is a good description. Met vriendelijke groeten / With kind regards, IDG.nl Melvyn Sopacua Webmaster