If e-mail is delivered to a program which generates too much output, then sendmail may issue an error:
timeout waiting for input from local during Draining InputMake sure that the program does not generate output beyond a status message (corresponding to the exit status). This may require a wrapper around the actual program to redirect output to /dev/null.
If e-mail is delivered to a program which does not read the whole
e-mail but just closes the connection after some amount of data,
then sendmail may cause a core dump on certain OS if the e-mail
is very large and delivery takes very long. sendmail only checks
the error flag on the output stream every few operations, not
the result of the output operation directly.
Such a problem has been reported once for vacation on Solaris 2.6.
From:friend@domain OKin the access map doesn't override a DNS based BL.
-v -q, the patch has been posted to comp.mail.sendmail.
Return-Receipt-To:header, if you re-compile sendmail and set a switch.
NOTICE: It is possible to relay mail through a system which the anti-relay rules do not prevent: the case of a system that doesn't use FEATURE(`route_uucp') (system A) and relays local messages to a mail hub (e.g., via LOCAL_RELAY or LUSER_RELAY) (system B). If system B does use FEATURE(`route_uucp'), addresses of the form <firstname.lastname@example.org> would be relayed to <email@example.com>. System A doesn't recognize `!' as an address separator and therefore forwards it to the mail hub which in turns relays it because it came from a trusted local host. So if a mailserver allows UUCP (bang-format) addresses, all systems from which it allows relaying should do the same.