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