> -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of SM > Sent: Friday, May 13, 2011 12:16 AM > To: ietf@xxxxxxxx > Cc: ietf-dkim@xxxxxxxxxxxx > Subject: Re: Last Call: <draft-ietf-dkim-mailinglists-10.txt> (DKIM And Mailing Lists) to BCP > Hi SM, By my read, the bulk of your comments fall into these categories: (1) Remove the normative language, publish as Informational As I said to John, I'd be fine with this. The document started out as Informational but there was working group momentum in the direction of a BCP instead, hence the conversion to use of RFC2119 language. I personally don't have strong feelings about that so if the preferred course of action is to go back to that, I'd be fine. As for the idea of using PS instead, that doesn't seem appropriate to me given we're not standardizing a protocol here, and at best we don't have enough implementation experience to back up the claims. (2) Editorial changes I'd be fine with all of the changes you proposed. (3) RFC5451 discussion > In Section 5.11: > > "Receivers SHOULD ignore or remove all unsigned externally-applied > Authentication-Results header fields, and those not signed by an ADMD > that can be trusted by the receiver." > > Quoting Section 5 of RFC 5451: > > "For security reasons, any MTA conforming to this specification MUST > delete any discovered instance of this header field that claims to > have been added within its trust boundary and that did not come from > another trusted MTA." > > "For simplicity and maximum security, a border MTA MAY remove all > instances of this header field on mail crossing into its trust > boundary." > > The MUST and the MAY are aggregated into a SHOULD. Is that > intentional? Yes, I believe they are consistent. The citation you made from RFC5451 directs implementations to delete forgeries (the MUST) and optionally delete everything else as well (the MAY). The citation from this document does not dispute the MUST, and provides further guidance for this particular application (which is also consistent with other parts of RFC5451) in terms of how to deal with what's left after the MUST part is done. > From Section 5.11: > > "Upon DKIM and ADSP evaluation during an SMTP session (a common > implementation), an agent MAY decide to reject a message during an > SMTP session. If this is done, use of an [SMTP] failure code not > normally used for "user unknown" (550) is preferred; therefore, 554 > SHOULD be used." > > 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." 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. 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. But to be conformant, I suppose 550 5.7.0 would be appropriate. > Quoting two sentences from the same section to provide better context: > > "In such cases where the submission fails that test, the receiver or > verifier SHOULD discard the message but return an SMTP success code, > i.e. accept the message but drop it without delivery. An SMTP > rejection of such mail instead of the requested discard action > causes more harm than good." > > I would remove the SHOULD as the argument (second sentence) is > clear. The usage of the SHOULD raises the question about whether > this is a SMTP receiver action and whether it is appropriate to > create a black hole (silent drop of message). If we are leaving the normative language in (for BCP, should that status stay) then I think the SHOULD is appropriate in the sentence that defines the normative action. Thanks for the review! -MSK _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf