ietf
[Top] [All Lists]

RE: Last Call: <draft-ietf-dkim-mailinglists-10.txt> (DKIM And Mailing Lists) to BCP

2011-05-13 13:18:39
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org 
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of SM
Sent: Friday, May 13, 2011 12:16 AM
To: ietf(_at_)ietf(_dot_)org
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>