Alessandro Vesely wrote:
SM wrote:
(3) RFC5451 discussion
This falls under policy decision. The usage of a 554 code is
inappropriate. From Section 3.6.2 of RFC 5321:
"If it [SMTP server] declines to relay mail to a particular address
for policy reasons, a 550 response SHOULD be returned."
Which is not always used. RFC2554 (ESMTP AUTH) allows the usage of
530 when you want to show an unauthorized state considition applicable
to RCPT TO:
530 Authentication is required for relaying.
A quick log grep of RCPT TO relay rejections show a unique set of these:
501
530
550
550 5.1.1
550 5.1.2
550 5.4.1
550 5.7.1
551
553
554 5.7.1
554
571
3.6.2 applies to relays, not recipients. A relay might try DKIM
validation and ADSP evaluation, but that's not the model this
document discusses.
For the record, unauthorized relay rejects can be done at the data
level as well. RFC5321 3.3:
However, in practice, some servers do not perform recipient
verification until after the message text is received.
Yes, my understanding of that SMTP snippet is that it concerns
responses to RCPT TO:<particular address>, while DKIM and ADSP can
only be evaluated after <CRLF>.<CRLF>. (In this respect, mentioning
"user unknown" in the MLM spec may cause some confusion in readers not
familiar with SMTP.)
However, if that doesn't matter, unfortunately this makes the
distinction we're trying to make impossible without using enhanced
status codes, which aren't universally used.
+1 for keeping 554 as is.
+1
But to be conformant, I suppose 550 5.7.0 would be appropriate.
Conformant to what?
Well RFC5321 does has open-ended 550 text that includes policy semantics:
550 Requested action not taken: mailbox unavailable (e.g.,
mailbox not found, no access, or command rejected for
policy reasons)
But 554 or 552 is technically correct for a DATA EOD reject.
You can clearly see this in section 4.2.2 showing Reply Codes by
Function Groups. The wo codes next to each other:
354 Start mail input; end with <CRLF>.<CRLF>
554 Transaction failed (Or, in the case of a connection-opening
response, "No SMTP service here")
And you also have section 4.3.2
DATA
I: 354 -> data -> S: 250
E: 552, 554, 451, 452
E: 451, 554, 503
552 and 554 are the technically correct permanent reject codes for the
end of data state. Since 552 is related to storage, 554 is the more
appropriate response.
Ideally, if Murray wishes to support Jeff McDonald's Anti-Spam ID that
is intended to update RFC3463, he might use (since this is all new
anyway):
554 5.8.0 Undefined Policy detail
554 5.8.1 Message refused by local policy
or perhaps Murray can propose to Jeff to add a 5.8.27 status code
specifically for ADSP related policy rejects:
554 5.8.27 Message refused by ADSP From.Domain=<IDENTITY-ODID>
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html