[ietf-dkim] Last Call: <draft-ietf-dkim-mailinglists-10.txt> (DKIM And Mailing Lists) to BCP
vesely at tana.it
Fri May 13 11:12:02 PDT 2011
On 13/May/11 09:15, SM wrote:
> In Section 4.1:
> "In an idealized world, if an author knows that the MLM to which a
> message is being sent is a non-participating resending MLM, the
> author SHOULD be cautious when deciding whether or not to send a
> signed message to the list."
> The author generally does not have any control over that decision as
> DKIM signing is not done at the MUA level. The usage of a key word
> is somewhat excessive here as the ideal world is out of scope for RFC 2119.
+1, should be lowercase.
> "This problem can be compounded if there are receivers that apply
> signing policies (e.g., [ADSP]) and the author publishes any kind
> of strict policy, i.e., a policy that requests that receivers reject
> or otherwise deal severely with non-compliant messages."
> The "definition of insanity is doing the same thing over and over and
> expecting different results". There are parallels between ADSP and SPF.
As a corollary, it is sane to do slightly different things over and
over until one catches the one that works. SPF is slightly better
than ADSP, though.
> In Section 5.1:
> "It is RECOMMENDED that periodic, automatic mailings to the list are
> sent to remind subscribers of list policy."
> This is currently being done by the IETF under the guise of mailman day.
Yes, the time-distributed database...
> In Section 5.8:
> "DKIM-aware authoring MLMs MUST sign the mail they send according to
> the regular signing guidelines given in [DKIM].
> Removing the MUST [...]
+1, the MUST is in DKIM's specs and thus is redundant here.
> In Section 5.10:
> "An FBL operator might wish to act on a complaint from a user about a
> message sent to a list."
> Shouldn't that be FBI? :-)
+1 (smiley not taken), FBL is a specific mechanism. As much of the
advice is also valid for other mechanisms, I suggest to change the
title to "Abuse Reporting Issues" or similar.
> 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."
-1, although it is a policy question, it has nothing to do with relaying.
> "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).
This should have been explained more clearly in RFC 5617. Perhaps, we
should say that "discardable" means "droppable" in general?
More information about the ietf-dkim