steven@??? (Steven Christensen) [Tuesday, September 03, 2002 11:24 AM]:
> Hmm... that's interesting. If this is a standard (and I did indeed
> find it in RFC 2421), then it looks like BellSouth is doing something
> non-standard. They are rejecting DSN/NDN messages to their servers.
> Are they allowed to do this (per RFC) ?
There is an event where exim will reject MAIL FROM:<> - where the sending
domain does not resolve in DNS at all.
Like for example if a box where exim thinks it is localhost.example.net
sends a DSN to exim, exim would reject it - when headers_sender_verify or
headers_sender_verify_errmsg is set (that's 3.x syntax - haven't looked up
what the equivalent is in 4.x).
There's code in src/verify.c to do this - since the 3.x days.
FWIW - from the 3.x spec -
> headers_sender_verify
> Type: boolean
> Default: false
>
> If this option is set with sender_verify, and the sending host matches
> sender_verify_hosts, Exim insists on there being at least one verifyable
> address in one of the Sender:, Reply-To:, or From: headers (which are
checked
> in that order) on all incoming SMTP messages. If one cannot be found, the
> message is rejected, unless headers_checks_fail is unset, in which case a
> warning entry is written to the reject log.
>
> If there are any headers whose names start with `Resent-', it is that set
of
> headers which is checked. If there is more than one instance of a
particular
> header, all of them are checked.
>
> Unfortunately, because it has to read the message before doing this check,
> the rejection happens after the end of the data, and it is known that some
> mailers do not treat hard (5xx) errors correctly at this point -- they
keep
> the message on their spools and try again later, but that is their
problem,
> though it does waste some resources.
>
> headers_sender_verify_errmsg
>
> Type: boolean
> Default: false
>
> This option acts like headers_sender_verify, except that it applies only
to
> messages whose envelope sender is `<>', that is, delivery error messages
> whose sender cannot be verified at the time the SMTP MAIL command is
> received.
--srs
