On Thu, Sep 04, 2014 at 12:37:50PM -0400, John R Levine wrote:
If you get 521 as a server greeting it means "I'm not a mail server." If
you get 521 as a response to RCPT TO it means "That's not a mail domain."
This overloading is unfortunate. It creates an implementation
challenge on the server side, because at least with Postfix, 421/521
responses can originate in milters, policy services, and access
tables.
As they can in our MTA. I fail to see the relevance.
In such cases the server interprets this as a "please drop
this client now" signal.
Huh? Since when does the client send SMTP status codes to the server?
Since nullmx recipient policy might well be implemented in miters
and the like, Postfix has no way to distinguish between this new
proposed code (which seems to not be a "drop" signal) and all
previous uses which are.
If that's really true, then Postfix needs work independent of this issue. It
has always been the case that statuses returned in response to RCPT TO are
recipient-specific, and thus have very different semantics from statuses
returned by MAIL FROM, DATA, BDAT, BURL, the final dot, etc., which apply to
the message as a whole.
And these statuses are in turn distinct from session-level stuff like STARTTLS
and AUTH.
When you get right down to it, SMTP isn't all that simple.
Postfix also supports "soft_bounce", which downgrades all 5XX
replies to the corresponding 4XX replies.
The structure of extended status codes guarantees that a 5.x.y shares semantics
with a 4.x.y. But this is not true for regular status codes, because the third
digits of those codes were assigned essentially on a first-come-first serve
basis. So you have things like 500, 501, 502, 503, 504, and 553 that don't have
a corresponding 4yz code, 551 and 451 have very different semantics, and the
proper downgrade code for 554 really needs to be 451.
Given this, I'd have to say that once again it's the implementation, not
the proposal, that needs work.
However 421 after RCPT
TO does not carry a "That's not a mail domain, but try again later"
meaning.
It doesn't carry that meaning anywhere. But again, just because someone
assumed, wrongly, that there's general equivalency between 5yz and 4yz and
added an option in support of that incorrect assumption, doesn't mean we should
cater to it.
The choice of 521 here seems rather unfortunate, and based on an
error the experimental RFC 1846. Please consider 550 or similar.
That's part of the problem: None of the existing codes that can be returned in
response to RCPT TO are right for the job. 550 is a mailbox access error, 552
is a storage allocation error, 553 is an invalid mailbox error, and 555 is a
parameter problem. Out of all these 553 is probably the closest, but it is
still not quite right.
Ned