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? _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
