Re: [courier-users] Local sendmail errors not logged

[Sam V. <mr...@co...>]

Alexei Batyr' writes:

> « HTML content follows »
> Sam,
>
> I've installed Courier (version 0.65 from FreeBSD ports) on our web server as  
> replacement for sendmail. It's only purpose is sending mails generated by  
> local PHP scripts - no incoming SMTP, users, auth, etc. At the first glance  
> everything was OK, however after some time webmasters started complaininig  
> about lost (sent but not delivered to recipients) messages. Searching maillog  
> revealed nothing helpful.
>
> After some digging around I've recognized that lost messages had "bad"  
> headers (with non-ASCII characters) and/or body. Setting BOFHBADMIME=accept  
> and MIME=none solved this problem, but some messages still was not get  
> delivered. I've found out that body of these messages had too long lines  
> (>5000 chars). And still nothing in the log.
>
> So questions arised:
> 1 (most important). Why local sendmail silently discards "bad" messages  
> without writing any errors to syslog?

Because no historical version of any mail handler with an externally-invoked  
"sendmail" command ever logged errors to syslog. Errors that resulted in  
submitted mail getting refused, no different than any other error  
encountered by any other executed command, they get reported to standard  
error, and the command terminates with a non-zero exit status.

And that's what occurs here. sendmail terminates with a non-zero exit code,  
after emitting an error message. It is the responsibility of whatever forks  
and executes a child process, and waits for the child process to terminate,  
to check its exit code, and report any failures.

The "sendmail" command in Courier is not a daemon that logs to syslog. It's  
an interactive command. In the original Sendmail sendmail, its "sendmail"  
was both, an executed command, and a daemon. The externally-executed  
sendmail command, if it rejected a message for its own reasons, would also  
print a message on standard error and terminate with a non-zero exit status.  
Same thing here.

> 2. Shouldn't "bad MIME" checks be applicable only to the messages received by  
> incoming SMTP for delivery to local users, not for outgoing messages?

No, bad mail is still bad mail, no matter where it comes from.