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

Reply via email to