Re: [ietf-dkim] Last Call: (DKIM And Mailing Lists) to BCP
At 08:02 12-05-2011, The IESG wrote: >The IESG has received a request from the Domain Keys Identified Mail WG >(dkim) to consider the following document: >- 'DKIM And Mailing Lists' >as a BCP > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send substantive comments to the >i...@ietf.org mailing lists by 2011-05-26. Exceptionally, comments may be From Abstract Section: "Based on deployment experience with DKIM, this Best Current Practices document provides guidance for the use of DKIM with scenarios that include Mailing List Managers (MLMs)." Although one can extrapolate from experience and provide some guidance, I would not call it "Best Current Practices". I suggest a change to that sentence: Based on deployment experience with DKIM, this document provides guidance for the use of DKIM with scenarios that include Mailing List Managers (MLMs). Quoting the Introduction Section: "The goal for this document is to explore the use of DKIM for scenarios that include intermediaries, and recommend Best Current Practices based on acquired experience." The Intended Status of this document is BCP. I cannot support a recommendation for "Best Current Practices" that is not based on existing practices. If the IETF wants a stick to tell the outside world what to do, it can publish this document as a BCP. If the IETF would like to provide guidance, leave it to the outside world to adopt that and then document the current practice, it should not publish this document as a BCP. From Section 2.5: "Each of these could have different security policies imposed against them, or there might be a desire to insulate one from the other (e.g., a marketing campaign that gets reported by many spam filters could cause the marketing stream's reputation to degrade without automatically punishing the transactional or user streams)." Shouldn't that be sending policies instead of "security policies"? If we go a stretch further, a marketing campaign might end up be labelled as a terrorist act and that falls under the Security Area. I'll translate that paragraph for a wider audience. Some companies send out spam; it keeps businesses happy if it is called a marketing campaign. These companies also send out messages that the receiver actually wants to read. On the receiving side, there is a lot of zealotry that goes on. One way to mitigate the effects of that zealotry is to provide the receiver a means to separate the spam from other mail. In Section 3.3: "Some lists prepend or append a few lines to each message to remind subscribers of an administrative URL for subscription issues, or of list policy, etc." It's funny to see how some MUAs adapted to that by hiding these lines thereby rolling back that "fix". 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. "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. 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. In Section 5.5: "In that case, authors SHOULD create a mail stream specifically used for generating signatures when sending traffic to MLMs." I suggest using "DKIM signatures". "This suggestion can be made more general." Shouldn't that be recommendation? In Section 5.8: "DKIM-aware authoring MLMs MUST sign the mail they send according to the regular signing guidelines given in [DKIM]. One concern is that having an MLM apply its signature to unsigned mail might cause some verifiers or receivers to interpret the signature as conferring more authority or authenticity to the message content than is defined by [DKIM]. This is an issue beyond MLMs and primarily entails receive-side processing outside of the scope of [DKIM]. It is nevertheless worth noting here." Removing the MUST and saying: DKIM-aware authoring MLMs signs the messages they send according to the regular signing guidelines given in [DKIM] gives more weight to the last
Re: [ietf-dkim] DKIM and mailing lists
On 12 May 2011, at 17:44, Hector Santos wrote: > > For the record, the old MLM was read as well Levine's poison pill MLM. > > With no intent nor suggest the writer is stupid, writers do say stupid > things and that paragraph was "stupid" then and it remains to be > "stupid" as in a stupid manner; "he had stupidly defined a one way > ticket for DKIM." I'm sorry, but in English, it's almost impossible to say that an idea is stupid without implying that the person who had the idea is stupid. I understand that the Spanish language may be different in this respect, in that it's much easier in Spanish to say that something bad has happened without assigning direct responsibility to some person involved. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM and mailing lists
Perhaps its a cultural thing. You should hear the number of the times my Jewish wife had said; "oh silly! stop being stupid!" or New York, Miami Cuban or Ricans cousins saying "stupppid" (its a special prolonged funny emphasis), or Cuban exiles elders calling me a "Stupid Communist" just because I want the Cuban embargo to end, Elian going back to this dad) or an Italian uncle saying "was a studid (Dominoes) move!" but I really hate it when he calls me a "Paper Hat!" Oh, really gets to me! Whatever, I remain convinced that particular paragraph is "terrible," "wrong", "improper," even "incompatible."But I can also see where that can imply, infer, suggest, insinuate or make people silently erroneously ponder the writer is a terrible, wrong and improper person writing incompatible material. All of which, all this, is chippy and infers signs of disrespects. Mucho Gracias, Ciao, Bonjour, Cheerio!, Catch you later, see ya on the rebound, Bye Bye! Ian Eiloart wrote: > On 12 May 2011, at 17:44, Hector Santos wrote: > >> For the record, the old MLM was read as well Levine's poison pill MLM. >> >> With no intent nor suggest the writer is stupid, writers do say stupid >> things and that paragraph was "stupid" then and it remains to be >> "stupid" as in a stupid manner; "he had stupidly defined a one way >> ticket for DKIM." > > I'm sorry, but in English, it's almost impossible to say that an idea is > stupid without implying that the person who had the idea is stupid. > > I understand that the Spanish language may be different in this respect, in > that it's much easier in Spanish to say that something bad has happened > without assigning direct responsibility to some person involved. > -- 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
Re: [ietf-dkim] Last Call: (DKIM And Mailing Lists) to BCP
> -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of SM > Sent: Friday, May 13, 2011 12:16 AM > To: i...@ietf.org > Cc: ietf-dkim@mipassoc.org > Subject: Re: Last Call: (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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: (DKIM And Mailing Lists) to BCP
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
Re: [ietf-dkim] Last Call: (DKIM And Mailing Lists) to BCP
On 5/13/11 8:12 PM, Alessandro Vesely wrote:
[...]
>> "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?
The problem what 'discardable' means has been introduced in RFC5617 and
I don't think draft-ietf-dkim-mailingslists-10.txt has to 'fix' that
problem. The meaning of 'discardable' has been discussed on this list at
least two times (see for example
http://mipassoc.org/pipermail/ietf-dkim/2008q1/009557.html) and this has
AFAIK not resulted in one unambiguous conclusion. Furthermore, as it's
not primarily an MLM issue (but an ADSP issue), I don't think we should
re-open the discussion again. Don't get me wrong, I agree with you that
it's important to define what we mean with discardable, but not here,
not now.
I'd propose to put this item ('writeup a definition of 'discardable') on
the to-do list of a successor of RFC5617, if there ever will be one. Or
on another future 'policy' document.
/rolf
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: (DKIM And Mailing Lists) to BCP
Rolf E. Sonneveld wrote: > On 5/13/11 8:12 PM, Alessandro Vesely wrote: > > [...] > > >>> "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? > > The problem what 'discardable' means has been introduced in RFC5617 and > I don't think draft-ietf-dkim-mailingslists-10.txt has to 'fix' that > problem. Nothing wrong with DKIM=DISCARDABLE. What is wrong is trying to dictate to others MLM should ignore ADSP. As a MLM vendor, I have technical and ethical engineering obligation not to cause problems when taking on a new inherently incompatible technology that doesn't naturally fit with a MLM. Hence, there are two general solutions for the MLM: MLM-LEVINE: Ignore all DKIM ADSP restrictive policies MLM-SANTOS: Preempt all DKIM ADSP restrictive policies I know as a matter of fact MLM-SANTOS is a better DKIM mail integration fit because we implemented it. Also, you can't dictate to receivers they should ACCEPT and DROP. Although that could be feasible solution to solve MLM ignorance to support ADSP, its a very difficult issue when increasing receiver practice is rejecting bad mail at the DATA level. What I had proposed is is method (rule) at the DATA filter: if message fails ADSP and has a LIST-ID, then respond 250 and discard the message if message fails ADSP and has no LIST-ID, then reject with 55x The problem is the MLM that is *ignoring* ADSP and passing on the buck to ADSP ready member receivers adding the overhead to receivers and also creating new MLM problems for itself. A repeated SMTP level rejection will cause harm to list member by the MLM sender creating false automated unsubscribing notifications when the attempts are exhausted. So if the receivers can detect its a MLM sender incorrectly sending ADSP protected mail, then the only recourse, in the name of not causing problems and backing up the ignorant MLM, is to accept (250) and then drop the message. But the real solution is for the MLM to follow proper DKIM mail integration considerations when adding something new it hasn't done in 40 years. -- 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
[ietf-dkim] IETF-SMTP signed mail DKIM BODY HASH Failures
I am wondering if anyone else can confirm BODY HASH errors with the originating author domain DKIM signature mail submitted to the IETF-SMTP fora. The IETF-SMTP MLM does not resign and in addition, it does not change the subject (adding [IETF-SMTP]) and does not appear to change the body by adding any list footer. Here is a few A-R headers by my verifier all showing the same error. Authentication-Results: dkim.winserver.com; dkim=fail (DKIM_BODY_HASH_MISMATCH) header.i=santronics.com header.d=santronics.com header.s=tms1; Authentication-Results: dkim.winserver.com; dkim=fail (DKIM_BODY_HASH_MISMATCH) header.i=mrochek.com header.d=mrochek.com header.s=mauve; Authentication-Results: dkim.winserver.com; dkim=fail (DKIM_BODY_HASH_MISMATCH) header.i=messagingengine.com header.d=messagingengine.com header.s=smtpout; I was thinking it was an C14N issue, but the first two are simple/simple and the last one is relaxed/relaxed. What could be hidden in this body that is different? -- 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
Re: [ietf-dkim] Last Call: (DKIM And Mailing Lists) to BCP
Hector Santos wrote: > Nothing wrong with DKIM=DISCARDABLE. What is wrong is trying to > dictate to others MLM should ignore ADSP. > > As a MLM vendor, I have technical and ethical engineering obligation > not to cause problems when taking on a new inherently incompatible > technology that doesn't naturally fit with a MLM. > > Hence, there are two general solutions for the MLM: > > MLM-LEVINE: Ignore all DKIM ADSP restrictive policies > MLM-SANTOS: Preempt all DKIM ADSP restrictive policies > > I know as a matter of fact MLM-SANTOS is a better DKIM mail > integration fit because we implemented it. Keep in mind that I recognize MLM-LEVINE solution but that is based on ignoring all originating DKIM information - pass, fail or unknown. The theory is based on: A) The Member is already authorized based on being a list member already, CONCUR B) No expectation of getting fraud submissions, and if so, a negligible amount, CONCUR C) Ignorance for DKIM failure promoting a relaxed atmosphere of DKIM unknown signer mail, OBJECT. D) Trust the single signer domain at the SYSTEM LEVEL (global), OBJECT. Assuming this MLM-LEVINE is the acceptable solution, then the optimized, lower overhead receiver operation is to first check to see if the signer(s) are known before even trying to verify any signature. > What I had proposed is method (rule) at the DATA filter: > >if message fails ADSP and has a LIST-ID, > then respond 250 and discard the message > >if message fails ADSP and has no LIST-ID, > then reject with 55x Note, by fails ADSP, it is presumed the policy is DKIM=DISCARDABLE To complete the logic for always accept systems: if message fails ADSP then discard the message You got to understand there is a split of how systems operate; many systems for scalability reasons, especially in earlier days, always accepted the message and then applies any mail filters. As hardware and software (multi-threaded OSes) improved, and also to address the bounce problem, more systems began to do more dynamic rejections at the DATA level. The technical responsibility to issues bounces is very strong. The idea of discarding was largely frown upon. This multi-decade BOUNCE requirement mindset, which touches base with 1986 US EPCA provisions for avoid censorship claims, has changed for the first time in RFC5321 with new semantics that recognizes the contemporary needs to "drop mail" when reasonable non-frivolous new considerations are appropriate. I pushed for this recognition known new technology like Sender-ID and ADSP was on the horizon. In short, Levine did a good thing by technically "legalizing" discarding of mail. -- 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
Re: [ietf-dkim] Last Call: (DKIM And Mailing Lists) to BCP
Hi Murray, At 11:17 13-05-2011, Murray S. Kucherawy wrote: >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. Ok. >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. Ok. >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. You can use 550 5.7.1. The enhanced status code used in the draft is appropriate. Thanks for the quick response. BTW, I forgot to the "best current practices" in Section 8. It's an editorial nit. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
