Re: Improvement suggestions for mail() delivery

Hello, On 05/13/2002 07:22 AM, Melvyn Sopacua wrote:

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.

That should be upto the hosting responsible to decide. Having that and better error messages is not mutually exclusive.

- 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.

Spelling errors is not the only reason for mail delivery failure. For instance some ISPs require SMTP autentication or some other requirement that leads to an immediate message delivery failure.

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.

I use my own set of mail delivery classes that are even more powerful than PEAR's, but the issue here is not solving my problem because I don't have one. The issue here is to help people solve mail delivery problems of their applications or applications that they grabbed that use the mail() function. Telling people to use this or that class may solve individual problems, but will not end the increasing rate of help requests on PHP lists from people that are clueless to why their messages do not get delivered. If PHP could provide better built-in methods to provide useful feedback so that users can figure what is going on, it would reduce many PHP users' frustration and reduce the rate of calls for mail() help in PHP lists, don't you think?

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.

That is why I suggested providing a SMTP based delivery. It is even possible to enable direct delivery to the destination SMTP server as an optionaly primary delivery method that would fallback to a relay SMTP server in case of failure. The advantage of this is that, if for some reason the sender envelope (return-path) is set to a unreachable address like some people have nobody@localhost, at least you could see in the logs that the end server is not accepting the message for some reason. I am suggesting this because I use it in a production environement and it is very helpful. Some times is a temporary fault in the remote server (very frequent in Yahoo servers I can tell) and this way you will know immediatly. In any case making the mail implementation more verbose terms of the errors that it returns or information it can log would be a step forward because the way it is, is leaving more and more people to the lists asking for help but with insufficient information that can be used to help them. -- Regards, Manuel Lemos