IMHO:
- 5xx in response to RCPT is a permanent failure. The client SHOULD NOT
try to deliver that message to that recipient via other MXes.
- If a server wants to say "try another MX" in response to RCPT then it
SHOULD respond with 4xx. There's no guarantee that the client will
use a different MX on the next try, but a robust client will do so.
- Mail domains that implement rejection policies based on IP address or
other criteria SHOULD implement them consistently across all incoming
message paths. (note that this doesn't necessarily mean that all
MXes should implement the same policy at the SMTP level; it means that
a message that is rejected for policy reasons will be rejected at
some point in the signal path no matter which MX the client chooses)
- Servers SHOULD NOT trust third party blacklists when deciding whether
to reject messages. They are notoriously unreliable.
Keith
On another list we have a - meanwhile rather emotional - discussion
about aggressive delivery attempts.
The origin of the discussion and the aggressive delivery attempts are
- large sites rejecting (valid, i.e. non spam) emails from certain IP
addresses based on policy decision, while they accept the same email
from other IP addresses without any problems (DUL lists like AOL
uses them for 5xx greetings or prodigy.net uses them to answer
RCPT TO with "550 5.0.0 Access denied")
- some unclear wordings in RFC 2821 (and historic 974) about what a
delivery is and what a "successful" delivery is.
In particular does a "5xx" code as an answer to a RCPT TO qualify
for a "successful delivery" in terms of a "successful connection"
or is a "successful delivery" to be interpreted in terms of a
"successful transmission" (RFC974 makes some differences but is
unclear about details, just as RFC 2821 is).
This discussion led to a view topics, namely
- how authoritative are answers from any MX server for a domain or
is the authority of the answer limited to that particular mailserver
- is a 5xx code from one of the MXs of a domain to be treated as a
global permanent failure or is it valid (and backed by wording in
e.g. RFC974
"Implementors are encouraged to write mailers so that they
try the MXs in order until one of the MXs accepts the message,
or all the MXs have been tried."
if I get e.g. a "550 go away" as an answer to a RCPT TO command to simply
disconnect and try the next MX and if I am through with all of them
to inject the message at a smarthost (e.g. my ISPs mailserver).
- how to interpret the 5xx code that e.g. AOL uses for a greeting if they
reject connections for policy reasons.
The originator of the aggressive delivery strategy argued
- if you don't want me to use any other of your MX hosts in case of
a 5xx code then don't list them.
- if you don't want me to annul the policies set for a specific MX
then take care that all of your MXs enforce the same policy
- there is no clear way for a receiving MTA to tell the sending MTA about
its policies like "we don't accept email from your IP but probably
will if you use your ISPs mailserver".
Would it be desirable to have specific message codes signalling policies to
sending MTAs?
Comments and clarifications highly welcome,
\Maex
--
SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
proportional to the amount of vacuity between the ears of the admin"
--
Regime Change 2004 - better late than never.