SM wrote:
Hi Hector,
At 11:43 14-05-2011, Hector Santos wrote:
See section 4.3.2
DATA
I: 354 -> data -> S: 250
E: 552, 554, 451, 452
E: 451, 554, 503
From http://www.rfc-editor.org/rfc/rfc5321.txt
DATA
I: 354 -> data -> S: 250
E: 552, 554, 451, 452
E: 450, 550 (rejections for policy reasons)
E: 503, 554
Regards,
-sm
Hi SM,
Updated 5321 noted. I had the 2821 doc open.
Lets keep in mind that these DATA EOD temporary or permanent reject
codes are almost always local policy reasons, including 552 and 554.
Since 550 is quite often used at RCPT TO or even at in DATA are for
"unknown users" semantics, something other than 550 is preferred. We
must remain backward compatible for clients who are not supporting
RFC3463 and receivers as well not issuing RFC3463 status codes.
I recommend (prefer) text that reflects receiver w/o RFC3463 support.
554 Messages refused by ADSP violation,
From.Domain=<RFC5322.From.domain>
554 5.7.0 Messages refused by ADSP violation,
From.Domain=<RFC5322.From.domain>
(Note, I don't care if its From=<RFC5322.From> and/or ADSP changed to
Signing Practice)
The reasons are:
1) We got more ~30 years under 821/2821 with the EOD 552, 554 possible
code, only 2 years with RFC3521, and even if we want to promote the
modern recommendations using 550,
2) The client could be a MLM MTA not reading extended codes or the
receiver not sending extended codes and the 550 may not be enough to
preempt false automated unsubscribed notifications.
We can not presume that adding DKIM support also means adding RFC34563
support.
Practically coding, a DKIM aware MLM adding this conditional check
might look for three or five triggers:
554
5.7.0
5.8.0 or 5.8.1
"ADSP" or "POLICY" or some other recommended work that could be used.
I think that the I-D should not lock in and be more general about this.
--
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