http://blog.gmane.org/gmane.ietf.dkim hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.dkim/17043 <pre>FYI, in case anyone wants to comment. -----Original Message----- From: marf-bounces&lt; at &gt;ietf.org [mailto:marf-bounces&lt; at &gt;ietf.org] On Behalf Of The IESG Sent: Wednesday, February 29, 2012 6:58 AM To: IETF-Announce Cc: marf&lt; at &gt;ietf.org Subject: [marf] Last Call: &lt;draft-ietf-marf-dkim-reporting-11.txt&gt; (Extensions to DKIM for Failure Reporting) to Proposed Standard The IESG has received a request from the Messaging Abuse Reporting Format WG (marf) to consider the following document: - 'Extensions to DKIM for Failure Reporting' &lt;draft-ietf-marf-dkim-reporting-11.txt&gt; as a Proposed Standard 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 ietf&lt; at &gt;ietf.org mailing lists by 2012-03-14. Exceptionally, comments may be sent to iesg&lt; at &gt;ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo presents extensions to the DomainKeys Identified Mail (DKIM) specification to allow for detailed reporting of message authentication failures in an on-demand fashion. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-marf-dkim-reporting/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-marf-dkim-reporting/ballot/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ marf mailing list marf&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/marf </pre> Murray S. Kucherawy 2012-02-29T21:05:52 http://comments.gmane.org/gmane.ietf.dkim/17042 <pre>FYI -----Original Message----- From: ietf-announce-bounces&lt; at &gt;ietf.org [mailto:ietf-announce-bounces&lt; at &gt;ietf.org] On Behalf Of rfc-editor&lt; at &gt;rfc-editor.org Sent: Wednesday, February 29, 2012 10:59 AM To: ietf-announce&lt; at &gt;ietf.org; rfc-dist&lt; at &gt;rfc-editor.org Cc: rfc-editor&lt; at &gt;rfc-editor.org Subject: RFC 6541 on DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures A new Request for Comments is now available in online RFC libraries. RFC 6541 Title: DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures Author: M. Kucherawy Status: Experimental Stream: IETF Date: February 2012 Mailbox: msk&lt; at &gt;cloudmark.com Pages: 16 Characters: 31655 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-kucherawy-dkim-atps-16.txt URL: http://www.rfc-editor.org/rfc/rfc6541.txt This experimental specification proposes a modification to DomainKeys Identified Mail (DKIM) allowing advertisement of third-party signature authorizations that are to be interpreted as equivalent to a signature added by the administrative domain of the message's author. This document defines an Experimental Protocol for the Internet community. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor&lt; at &gt;rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC </pre> Murray S. Kucherawy 2012-02-29T19:22:39 http://comments.gmane.org/gmane.ietf.dkim/17041 <pre>Hi, all on June 17th 2011 (http://lists.opendkim.org/archive/opendkim/users/2011/06/1173.html) I sent a mail to the ietf-dkim list about an upcoming expert meeting in relation to the submission of DKIM for the 'Comply or Explain' standards list, used by the Dutch government and government agencies. As a followup I have another question. Is anyone aware of initiatives or regulations initiated by or endorsed by or 'observed' by any government in the country you live? We have seen an announcement on this list in November 2010 by Tsuneki Ohnishi about a DKIM Japan initiative, where the Japanese government has a status of observer (see http://web.archiveorange.com/archive/v/8JY9w5vRl0ZInsYJI0OV). I'm looking for examples of other/similar initiatives by government (agencies) or with involvement of government (agencies) with the purpose to aid in the adoption of DKIM on a country or state level. Thanks for any pointers or information, /rolf </pre> Rolf E. Sonneveld 2012-01-18T12:41:03 http://comments.gmane.org/gmane.ietf.dkim/17039 <pre>Now that this WG has not implemented greylisting: wcSmtpQue version: 2.6 250-Begin Mail Queue Manager #0001 Address : ietf-dkim&lt; at &gt;mipassoc.org Attempts: 4 NextTime: 01/10/2012 06:44:28 AM Response: 451 (451 4.7.1 Greylisting in action, please come back later) 250 End Mail Queue Manager and is causing delivery delays, maybe it can add logic to check for member's address and white list or support the SMTP extention for Greylist draft: http://tools.ietf.org/html/draft-santos-smtpgrey-01 To help alleviate the delivery delays and wasteful queuing/resend overhead of member's submissions. </pre> Hector Santos 2012-01-10T11:37:19 http://comments.gmane.org/gmane.ietf.dkim/17038 <pre>Hi all, This got approved by the IESG. Note that it is slightly different than the last time it was discussed here, courtesy of some suggested changes during IESG evaluation. OpenDKIM has already implemented the revised version and is thus available for interop testing if anyone wants to try this out. -MSK -----Original Message----- From: ietf-announce-bounces&lt; at &gt;ietf.org [mailto:ietf-announce-bounces&lt; at &gt;ietf.org] On Behalf Of The IESG Sent: Monday, January 09, 2012 2:01 PM To: IETF-Announce Cc: RFC Editor Subject: Document Action: 'DKIM Authorized Third-Party Signers' to Experimental RFC (draft-kucherawy-dkim-atps-16.txt) The IESG has approved the following document: - 'DKIM Authorized Third-Party Signers' (draft-kucherawy-dkim-atps-16.txt) as an Experimental RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Sean Turner. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-kucherawy-dkim-atps/ Technical Summary DKIM deliberately makes no binding between the DNS domain of the signer of a message and any other identity found in the message. Despite this, there is an automatic human perception that an author domain signature (one for which the RFC5322.From domain matches the DNS domain of the signer) is more valuable or trustworthy than any other. There is currently no protocol by which an ADMD can announce that DKIM signatures on its mail added by other ADMDs should also be considered trustworthy by verifiers. This presents an experimental mechanism for doing so. Working Group Summary This is an individual submission, but was discussed with the former DKIM participants, on the DKIM mailing list. Note that there is NOT general agreement that this protocol is important, or even useful. There is good consensus that experimentation is needed to determine utility, and this document sets up that experiment by proposing a protocol for it. Document Quality ATPS has been prototyped, in preparation for this experiment, and is available in an open-source implementation. Other implementations are expected as the experiment proceeds. Personnel Barry Leiba is the Document Shepherd. Sean Turner is the responsible Area Director. IANA Note The new registry should be nested under DKIM Parameters. _______________________________________________ IETF-Announce mailing list IETF-Announce&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce </pre> Murray S. Kucherawy 2012-01-09T22:17:57 http://comments.gmane.org/gmane.ietf.dkim/17038 <pre>Hi all, This got approved by the IESG. Note that it is slightly different than the last time it was discussed here, courtesy of some suggested changes during IESG evaluation. OpenDKIM has already implemented the revised version and is thus available for interop testing if anyone wants to try this out. -MSK -----Original Message----- From: ietf-announce-bounces&lt; at &gt;ietf.org [mailto:ietf-announce-bounces&lt; at &gt;ietf.org] On Behalf Of The IESG Sent: Monday, January 09, 2012 2:01 PM To: IETF-Announce Cc: RFC Editor Subject: Document Action: 'DKIM Authorized Third-Party Signers' to Experimental RFC (draft-kucherawy-dkim-atps-16.txt) The IESG has approved the following document: - 'DKIM Authorized Third-Party Signers' (draft-kucherawy-dkim-atps-16.txt) as an Experimental RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Sean Turner. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-kucherawy-dkim-atps/ Technical Summary DKIM deliberately makes no binding between the DNS domain of the signer of a message and any other identity found in the message. Despite this, there is an automatic human perception that an author domain signature (one for which the RFC5322.From domain matches the DNS domain of the signer) is more valuable or trustworthy than any other. There is currently no protocol by which an ADMD can announce that DKIM signatures on its mail added by other ADMDs should also be considered trustworthy by verifiers. This presents an experimental mechanism for doing so. Working Group Summary This is an individual submission, but was discussed with the former DKIM participants, on the DKIM mailing list. Note that there is NOT general agreement that this protocol is important, or even useful. There is good consensus that experimentation is needed to determine utility, and this document sets up that experiment by proposing a protocol for it. Document Quality ATPS has been prototyped, in preparation for this experiment, and is available in an open-source implementation. Other implementations are expected as the experiment proceeds. Personnel Barry Leiba is the Document Shepherd. Sean Turner is the responsible Area Director. IANA Note The new registry should be nested under DKIM Parameters. _______________________________________________ IETF-Announce mailing list IETF-Announce&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce </pre> Murray S. Kucherawy 2012-01-09T22:17:57 http://comments.gmane.org/gmane.ietf.dkim/17010 <pre>I have one comment to make which ties together both my stance on Otis' doublefrom crusade, and some reforms I have argued for in ADSP. Basically, at present the doublefrom trick is simply *unnecessary* for someone trying to pass me a forged mail. My MTA, Exim-4.76, does not natively support ADSP. It does support core DKIM, but without ADSP it's not reasonable for the DKIM result to have any effect on the message disposition. It probably wouldn't be *that* hard to cobble together some receiverside ADSP implementation using Exim's other features, but it's just not worth my while. I'm not afraid of any phish fooling me, but I am interested in anything that reduces the amount of "bad mail" reaching my inbox. But while a lot of spam is forged, it's forged to be from some ordinary schlub, not Paypal. I keep records going back to 2007, and since the start of that year 254 bad mails (spam and viruses) have gotten through to me. They represent 210 alleged From: domains. Of those domains, -absolutely none- of them, -today-, have ADSP records at all. Not even a "dkim=unknown"! Thus retrospective analysis shows ADSP is unlikely to make any difference. I may well implement double-From: detection alone. *It* would have blocked three spams from that interval (none of which bear any attempt at a signature). Now, all that aside, Paypal would probably still really like me to arm ADSP, just in case. But while it may be worth *their* time to sail 100km to meet me (that is, by actually maintaining no-mailing-list discipline so they can use discardable), it's not worth *my* time to drive 1km from my hilltop home to the port to meet them. If ADSP were fixed so that it could be deployed meaningfully at ordinary domains, with users who post to mailing lists, this might change. I've already stated my fix -- add "dkim=except-mlist", which states that any message with broken/absent signatures should be considered bogus if it is known not to be a mailing list message. While merely adding a fake "List-Id:" header might let forgeries of except-mlist domains get through to many users, that will never work on me. I recognize my mailing lists via other indicia that are harder to forge (the MAIL FROM:). ---- Michael Deutschmann &lt;michael&lt; at &gt;talamasca.ocis.net&gt; </pre> Michael Deutschmann 2011-07-27T07:13:29 http://comments.gmane.org/gmane.ietf.dkim/17006 <pre>Chaps I would like to bring to your attention and solicit comments on the following draft. http://tools.ietf.org/html//draft-oreirdan-rosenwald-ipv6mail-transition-00 Thanks Mike O'Reirdan </pre> O'Reirdan, Michael 2011-07-22T14:09:34 http://comments.gmane.org/gmane.ietf.dkim/16994 <pre>I would like to propose a small change in semantics to the current text in section 6.1, last sentence of 2nd paragraph: Therefore, a verifier SHOULD NOT treat a message that has one or more bad signatures and no good signatures differently from a message with no signature at all. Since there is a reference to a policy-based treatment of the message in section 6: A verifying MTA MAY implement a policy with respect to unverifiable mail, regardless of whether or not it applies the verification header field to signed messages. the text in 6.1 should be expanded or changed to indicate the possible consideration other that what is stated, i.e. an augmented security DKIM wrapper such as ADSP or other future policy-based DKIM security wrapper is being applied. I propose the changed text (or anything else one deems better): Therefore, in lieu of some policy-based valid signature requirement as outlined in section 6.0, a verifier SHOULD NOT treat a message that has one or more bad signatures and no good signatures differently from a message with no signature at all. </pre> Hector Santos 2011-07-11T05:01:38 http://comments.gmane.org/gmane.ietf.dkim/16981 <pre>One additional thought on the whole double-From: argument -- if RFC language on the issue is justified at all, it really belongs in the ADSP RFC, not a core DKIM one. A double-From: doesn't even rise to the level of theoretical threat except when dealing with ADSP (or a successor). If we, for example, invented an "LDSP" protocol to allow mipassoc.org to assert that any message bearing "List-Id: ietf-dkim&lt; at &gt;mipassoc.org" without a d=mipassoc.org signature is highly suspicious, then the operation of that defense would be entirely unexploitable by double-Froms. Of course, a lazy "LDSP" might be exploited with multiple List-Id: headers, and that would actually be more significant. List-Id: was invented after RFC822, so we can't claim multiple copies of it violate the protocol. To the core DKIM spec, "From:" isn't magic at all. Rather than enumerate every header that might be sensitive, we should put in a non-normative note that layered protocols should consider the issue: { Most expected applications of DKIM will involve signatures added by a sender in order to justify their use of a name in some other header of the message. For example, ADSP allows a domain to assert that their signature must be present for a message bearing one of their addresses in the From: header. It is suggested that such layered protocols include an explicit requirement to check for multiple copies of whichever header they defend. Otherwise, a situation could arise where a lazy validator approves a message based on all appropriate signatures being present for just one instance of the header, and yet a downstream entity falsely assumes a different instance was so validated. } ---- Michael Deutschmann &lt;michael&lt; at &gt;talamasca.ocis.net&gt; </pre> Michael Deutschmann 2011-07-09T23:19:17 http://comments.gmane.org/gmane.ietf.dkim/16931 <pre>Question: What is the advice or comments regarding a list distribution and/or a multi-rcpt session where the payload (DATA) is the same and then when signing the routed messages, they all have the same signatures? Depending on the processing speed, only when the t= seconds time changes does the signature (b=) change. I guess the question is, is it important or preferred that every message signature be signature unique? Or the opposite, if the t= time was retained for all message, then very message signature will be the same. Is there some validity that the single signature is correct, including time wise, given the fact the payload is 100% exact? Just wondering how much time I should spent on what appears to be one of the final considerations for our new revision of DKIM implementation. Thanks </pre> Hector Santos 2011-07-06T23:01:56 http://comments.gmane.org/gmane.ietf.dkim/16915 <pre>The 4871bis draft was on this past Thursday's IESG telechat, and mostly passed, but for a strongly held DISCUSS position from one AD, Pete Resnick. Pete had particular complaints about sections 8.14 and 8.15, along with some other issues, and was willing to block the document until they were resolved. The editors and the AD together worked diligently for resolution, and in the end came up with an updated version that they can all accept, and that we think the working group can as well -- at least to the extent that we had agreed before; these changes will not make Charles and Doug happy, but I think they retain the essence of the rough consensus of others. Because of the extent of the changes, though, the chair (I) thinks it needs to come back to the working group for another review. So the working group is now asked to look over the diffs, noting that in a few cases blocks of text were moved to other sections without being changed. ONLY diffs are in scope for reconsideration at this point, and we'll be looking for confirmation that the changes are acceptable, as well as complaints about the changes. Complaints SHOULD come with specific suggestions for alternatives. Pete apologizes for not having been involved with this earlier, promises to closely follow the mailing list thread on this, and will participate in any text negotiation that's necessary in order to get this right. We have a week. Murray will be posting the update (-14) very soon. Please review and comment by 11 July. Barry, as chair and document shepherd </pre> Barry Leiba 2011-07-03T03:26:49 http://comments.gmane.org/gmane.ietf.dkim/16897 <pre>Folks, I've been reviewing 4871bis for the IESG review on Thursday. I've got a huge number of comments. Some of them (e.g., the first two below) are quite trivial or simple issues that I expect you'd either have no issue with or that I'm happy to ignore; some of them are clearly not trivial at all. I have not entered a ballot position yet, and I haven't sorted through all of the comments to decide if any are worthy of entering a DISCUSS, but I suspect that some of them are. I therefore wanted to post this to the WG list so you all get an idea of what I'm thinking about. Tomorrow I'll spend some time cleaning these up and sorting them by category instead of by order of the document. I apologize for the lateness of this review; it's probably something I should have done a long time ago. Comments: 1. I find the use of the word "INFORMATIVE" throughout the document superfluous. No other word (e.g., NORMATIVE) is used in its place. I think they should all be removed. They serve no purpose. 2. The ABNF "0*" construct is not normally used. Why not just "*"? 3. Section 2.7: I don't understand what the word "module" means in this context. It sounds like some sort of specific implementation, not part of a protocol. I don't know what it means to deliver values to a module. 4. Section 3.4.4: INFORMATIVE NOTE: It should be noted that the relaxed body canonicalization algorithm may enable certain types of extremely crude "ASCII Art" attacks where a message may be conveyed by adjusting the spacing between words. If this is a concern, the "simple" body canonicalization algorithm should be used instead. This is not an attack, or at the very least it is not an attack on DKIM. You can play this same game with MIME encodings or other textual tricks. I don't see any justification for this note being in this document. 5. Section 3.4.5: INFORMATIVE IMPLEMENTATION NOTE: Using body length limits enables an attack in which an attacker modifies a message to include content that solely benefits the attacker. It is possible for the appended content to completely replace the original content in the end recipient's eyes, such as via alterations to the MIME structure or exploiting lax HTML parsing in the MUA, and to defeat duplicate message detection algorithms. To avoid this attack, signers should be wary of using this tag, and verifiers might wish to ignore the tag, perhaps based on other criteria. I don't understand how this is an attack. If the signer said, "I'm signing the first n bytes of the body of this message" and the verifier is able to verify that the signature is valid for n bytes of the body, the algorithm has succeeded. At most, this should lead to an admonition that unsigned data is not verified and therefore should not be trusted, but that seems obvious. There might be an attack on an MUA that does not verify the DKIM signature, but that seems outside the scope of this document. 6. Section 3.5: v= Version (MUST be included). This tag defines the version of this specification that applies to the signature record. It MUST have the value "1". Note that verifiers must do a string comparison on this value; for example, "1" is not the same as "1.0". Why "string comparison" here? There's no case sensitivity to worry about. There's no character encoding to worry about. Why not instead say, "Note that verifiers must (MUST?) ensure that the value is '1'; for exmaple '1' is not the same as '1.0'"? (Seem similar text in 3.6.1.) And why is the value not listed as "plain-text"? 7. Section 3.5: It would be nice to subsection each tag here. (e.g., "v=" could be 3.5.1, etc.) 8. Section 3.5, "h=": It would be nice to add a sentence similar to the one in 5.4: "The field MAY contain multiple instances of a header field name; this means that multiple occurrences of the header field are being signed by the signing algorithm." 9. Section 3.5, "h=": INFORMATIVE EXPLANATION: By "signing" header fields that do not actually exist, a signer can allow a verifier to detect insertion of those header fields after signing. However, since a signer cannot possibly know what header fields might be created in the future, and that some MUAs might present header fields that are embedded inside a message (e.g., as a message/ rfc822 content type), the security of this solution is not total. a. I don't understand what MUAs presenting "header fields that are embedded inside a message" has to do with anything. b. I don't know what the words, "the security of this solution is not total" are supposed to mean. Don't you simply mean: "However, since a signer cannot possibly know what header fields might be defined in the future, this mechanism can't be used to prevent the addition of any possible unknown header fields."? 10. Section 3.5, "h=": INFORMATIVE EXPLANATION: The exclusion of the header field name and colon as well as the header field value for non-existent header fields allows detection of an attacker that inserts an actual header field with a null value. I cannot parse that sentence. I have no idea what it means. 11. Section 3.5, "l=", "INFORMATIVE IMPLEMENTATION WARNING". See comment in 3.4.5 above. Same comment. 12. Section 3.6.1: It would be nice to subsection each of the tags. 13. Section 3.7: "content-hash" is not defined. 14. Section 3.9: a. Neither TEMPFAIL nor PERMAFAIL is defined at this point. b. I have no idea what the "output of a DKIM verifier module" is supposed to mean. I suspect that section 3.9 is at least misplaced in this document, and probably completely unnecessary as it sounds like implementation details. 15. Section 3.10: Is this not completely redundant with the text in 3.6.1 regarding "t=s"? 16. Section 4.1: The "INFORMATIVE EXAMPLES" don't need to be called out as such. The title of the section is "Example Scenarios". All of the text here is example, and as such it is all informative. 17. Section 4.2, first INFORMATIVE NOTE: Why is this an informative note? It seems like good protocol adivce and therefore should say that signers SHOULD NOT sign exiting DKIM-Signauture fields. 18. Section 4.2, last paragraph: PERMFAIL is still not defined to this point. I suspect sections 3.8 through all of section 4 belong after (or in) section 6. 19. Section 5.1, INFORMATIVE NOTE: Instead of saying "Signing modules may be incorporated into any", how about "A signer can be implemented as part of any"? 20. Section 5.1: I don't know what the term "signing address" means. 21. Section 5.3: Therefore, a verifier SHOULD NOT validate a message that is not compliant with those specifications. This section is about signing, not verifying. What is that sentence doing in there? 22. Section 5.4: INFORMATIVE ADMONITION: Despite the fact that [RFC5322] permits header fields to be reordered (with the exception of Received header fields) 5322 does *not* permit header fields to be reordered. It says: ...header fields SHOULD NOT be reordered when a message is transported or transformed. More importantly, the trace header fields and resent header fields MUST NOT be reordered, and SHOULD be kept in blocks prepended to the message. Suggest: "Despite the fact that [RFC5322] does not absolutely prohibit header fields to be reordered..." 23. Section 5.5: Though section 5.5 is titled "Recommended Signature Content", it is clear that the entire section is devoted to the topic of section 5.4: "Determine the Header Fields to Sign". These two sections should be combined, and might be subsections of a larger section. But it was very confusing to read these as separate. 24. Section 6.1: A verifier SHOULD NOT treat a message that has one or more bad signatures and no good signatures differently from a message with no signature at all; such treatment is a matter of local policy and is beyond the scope of this document. The two clauses in that sentence seem contradictory. Is there an interoperability requirement that I not treat messages in a particular way, or is it a matter of local policy? 25. Section 6.1, first "INFORMATIVE NOTE" on attack by many bad sigs: Shouldn't this be a security consideration instead? 26. Section 6.1 (and subsections): This section is playing some sort of game. The beginning of 6.1 describes some "statuses" and says things like, "The '(explanation)' is not normative text; it is provided solely for clarification." If it wanted to give an algorithm for Verfiers to follow, where there was a certain state machine with states of "PERMFAIL" and "TEMPFAIL", that would have been OK. But it is clear from the use of the phrasing, for example, "return PERMFAIL (signature syntax error)", the document is trying to sneak in some sort of actual APIs into the protocol spec. I think this is bogus and would much prefer that these sections be rewritten to say, "enters a PERMFAIL state", perhaps labeling each paragraph with the explanation. For example, the first paragraph of 6.1.1 could read: Signature syntax Implementers MUST meticulously validate the format and values in the DKIM-Signature header field; any inconsistency or unexpected values MUST cause the header field to be completely ignored and the verifier enters a PERMFAIL state. Being "liberal in what you accept" is definitely a bad strategy in this security context. Note however that this does not include the existence of unknown tags in a DKIM-Signature header field, which are explicitly permitted. Version compatibility Verifiers MUST enter a PERMFAIL state when presented a DKIM-Signature header field with a "v=" tag that is inconsistent with this specification. The current text is too cute by half, and I think it obfuscates the meaning. 27. Section 6.1.3: I don't understand the meaning of the note, "(note that this version does not actually need to be instantiated)". 28. Section 6.1.3: verifiers might treat a message that contains bytes beyond the indicated body length with suspicion, such as by declaring the signature invalid (e.g., by returning PERMFAIL (unsigned content)), or conveying the partial verification to the policy module. Up to the word "suspicion", fine. After that, it is complete nonsense. The signature is not invalid. If what you mean is "and may choose to treat the signature as if it were invalid (e.g., by going into the PERMFAIL state)", then say that. And again, this is trying to wrap APIs and implementations choices into the protocol. 29. Section 8.1: See comments above regarding section 3.4.5. 30. Section 8.2: I don't see how this is DKIM specific. More importantly, this section doesn't explain how user private keys relate in any way to keys used in DKIM. Shouldn't this be a discussion about security of private keys in general (not just ones on user machines)? 31. Section 8.5: I don't understand what the attack here is that has anything to do with DKIM. I especially don't see why the accomplice is an essential part of the example, unless all that is meant by "accomplice" is "relay". The attack sounds like, "people can spam signed messages", which is not an attack. 32. Section 8.14: This is a complete mischaracterization of the problem. This is absolutely not an attack vector. If a signer wishes to prevent additional *known* header fields from being verified, it can simply use the technique outlined in 8.15. If the signer chooses not to do that, it is expressing the intent that it considers messages valid that have additional header fields added. *That's* the security consideration: Signers should know that failing to include, e.g., "h=...:from:from:..." on messages with one "From:" header field are leaving themselves open to this attack. The attack is not on the verifier. Additionally: Note that the technique for using "h=...:from:from:...", described in Section 8.15 below, is of no effect in the case of an attacker that is also the signer. That sentence is utter nonsense. The signer *can't* be the attacker for purposes of DKIM when it comes to the header fields it's willing to sign. The Introduction (section 1) makes it absolutely clear that DKIM is about transmitting information from a signer to a verifier. Section 8.14 needs to be completely rewritten. It is nonsensical as it stands. 33. Section 8.15: However, [RFC5322] also tolerates obsolete message syntax, which does allow things like multiple From: fields on messages. The implementation of DKIM thus potentially creates a more stringent layer of expectation regarding the meaning of an identity, while that additional meaning is either obscured from or incorrectly presented to an end user in this context. DKIM can perfectly well deal with the obsolete syntax. The signer can sign as many "From:" fields as the message has when signed, and add a ":from" to the "h=" tag to insure that the right number of them are verified. As in 8.14, the attack is not on DKIM per se; it's on signers that don't properly use the "h=" tag to sign those header fields that they don't want added to. Other malformed input might cause problems for a DKIM implementation, but multiple header fields where 5322 3.6 only allows one is not that sort of attack. </pre> Pete Resnick 2011-06-29T04:46:06 http://comments.gmane.org/gmane.ietf.dkim/16854 <pre>Dear all, after some off-list conversation with Dave he suggested I might want to send this to the list. I apologize in advance if this message does not apply to you. I also apologize if you get this message twice, when you are subscribed to both ietf-dkim and the opendkim list. The Dutch government maintains a list of standards, which can/should be used by the Dutch government and semi-government, to improve interoperability. This list is called the 'comply or explain' list: if a government body has very good reasons to not comply, they can get away with it, but if they have no good reasons, they have to use the standards that are on this list in the various area's they apply, to improve interoperability. To give some examples: ODF is on the list, as well as IPv6. The complete list can be found at http://www.open-standaarden.nl/fileadmin/os/documenten/OS_lijst_open_standaarden_voor_pas_toe_of_leg_uit.pdf, unfortunately there is no English version of it, AFAIK. Background information can be found at *http://standards*.gov/*standards*_gov/sos_rfi_docs/47_*Netherlands*.pdf. By some people this list of standards is also seen as a list of standards, that need some extra support to achieve a critical mass, to solve the problem of chicken-and-egg that's often a problem in standards acceptance. Last year in November I submitted DKIM as a candidate for this list. Now, before it will be accepted for the list 'comply or explain', there are a number of steps to be taken. One of these steps will be an expert group meeting in July; in this expert group people from government, semi-government, industry etc. are present, to give their view about whether DKIM should or should not be on this list. Now the committee, that is preparing this expert group meeting, is happy with gov/semigov and industry participation, but they also want some technology experts in the expert group meeting (of course, why else would it be called an expert meeting :-)). Unfortunately the experts will have to have the Dutch nationality, or at least speak Dutch, I'm not sure why; it seems to be a matter of rules. Now my question is: if you're a Dutch member of this list, or you know someone who is/speaks Dutch and has expertise in the area of DKIM please let me know. The website with information about the expert meeting can be found at: http://www.open-standaarden.nl/actueel/item/titel/oproep-aanmelden-voor-expertgroepen/ (ignore the deadline of June 8th). If you're interested, send mail to openstandaarden&lt; at &gt;logius.nl and refer to this mail. Please note: it is possible that a selection will be made, to achieve a balance in the expert meeting group between the various parties, or to limit the number of members of the expert group. Regards, /rolf </pre> Rolf E. Sonneveld 2011-06-17T20:05:09 http://comments.gmane.org/gmane.ietf.dkim/16852 <pre>Hi all, does anybody know about commercial/free DKIM verifiers that produce a certificate of "valid email message", or similar, for archival usage by the requesting party? TIA </pre> Alessandro Vesely 2011-06-17T15:13:18 http://comments.gmane.org/gmane.ietf.dkim/16848 <pre>My IP(210.21.231.102,trustechpcb.com) is listted in you service,please deleting !THKS!</pre> 資訊室 劉大通 2011-06-16T23:59:15 http://comments.gmane.org/gmane.ietf.dkim/16652 <pre>Borrowing the style in RFC1123 (Internet Mail Hosting Requirements) I did a regular expression grep for {MUST}|{SHOULD}|{MAY}|{RECOMMENDED}|{OPTIONAL}|{REQUIRED}|{SHALL} to begin to look at all the RFC2119 semantics. At first, I was going to pull out some old prolog AI code that makes associations and connections in sentences to see if there was a "AI" way to validate RFC2119 conformity but instead I just wrote this draft table summarizing all the RFC4781bis references to RFC2119 semantics. I first I started to just record it as it appeared in the document searches, then I began to consolidate by role and as it appeared in the doc. I did come across some things that arguably in conflict with RFC2119, but I footnoted the ones I believe may need some attention. The top one (#1) was that signer has no MUST explicit statements for using C14N "simple" or "relaxed" unlike an explicit statement for verifiers. Also, I did find section 5.6 a little ambiguous. DKIM is a complex beast. I think once we see there are no conflicts, we can consolidate the table into a DKIM component roles like it was done in RFC1123 and like RFC1123 was very helpful, a table like this for DKIM will be helpful as well. DKIM REQUIREMENTS SUMMARY (DRAFT) +-----------------------------------------------------------------------+ | | | | | |S| | | | | | | | |H| |F| | | | | | |O|M|o| | | | |S| |U|U|o| | | | |H| |L|S|t| | | |M|O| |D|T|n| | | |U|U|M| | |o| | | |S|L|A|N|N|t| | | |T|D|Y|O|O|t| |FEATURE |SECTION | | | |T|T|e| |-----------------------------------------------|-----------|-|-|-|-|-|-| |SIGNER ISSUES | | | | | | | | | | | | | | | | | |DKIM-Quoted-Printable |2.11 | | | | | | | | encode any character |2.11 | | |X| | | | | encode control characters |2.11 |X| | | | | | | encode white spaces |2.11 |X| | | | | | | after encoding add FWS |2.11 | | |X| | | | | remove whitespace after decoding |2.11 |X| | | | | | | | | | | | | | | |Tag=Values | | | | | | | | | Tags unencoded semicolon |3.2 | | | | |X| | | Tags case sensitive |3.2 |X| | | | | | | Tags values case sensitive |3.2 |X| | | | | | | Duplicate Tags |3.2 | | | | |X| | | Retain WS tag value |3.2 |X| | | | | | | Add tag=value defaults |3.2 | | |X| | | | | add "v=1" |3.5 |X| | | | | | | add "a=" |3.5 |X| | | | | | | add "b=" |3.5 |X| | | | | | | ignore "b=" WSP |3.5 |X| | | | | | | add "bh=" |3.5 |X| | | | | | | ignore "bh=" WSP |3.5 |X| | | | | | | add "c=" |3.5 | | |O| | | | | add "d=" SDID |3.5 |X| | | | | | | SDID valid DNS name |3.5 |X| | | | | | | encode IDN as A-LABEL |3.5 |X| | | | | | | add "h=" |3.5 |X| | | | | | | empty list |3.5 | | | | |X| | | order header field list |3.5 |X| | | | | | | non-existing header fields |3.5 | | |X| | | | | contain DKIM-Signature Header |3.5 | | | | |X| | | folding WSP |3.5 | | |X| | | | | header name case insensitive |3.5 |X| | | | | | | add "i=" |3.5 | | |O| | | | | omit local part |3.5 | | |X| | | | | domain related to "d=" |3.5 |X| | | | | | | encode IDN as A-LABEL |3.5 |X| | | | | | | local part related to From |3.5 | | |X| | | | | same name space |3.5 | | |X| | | | | represent users |3.5 | | |X| | | | | persistent with same signer sphere |3.5 | |X| | | | | | add "l=" body length |3.5 | | |O| | | | | larger than actual body length |3.5 | | | | |X| | | add "q=" query method |3.5 | | |O| | | | | implement recognized method |3.5 |X| | | | | | | ignore unrecognized method |3.5 |X| | | | | | | method changes interpretation |3.5 | | | | |X| | | "dns" type uses "txt" |3.5 |X| | | | | | | add "s=" |3.5 |X| | | | | | | encode IDN as A-LABEL |3.5 |X| | | | | | | add "t=" |3.5 | |R| | | | | | support 40 bits |3.5 | |X| | | | | | DoS Attacks ignore 12 digits |3.5 | | |X| | | | | ignore future timestampes |3.5 | | |X| | | | | add "X=" |3.5 | |R| | | | | | greater then "t=" value |3.5 |X| | | | | | | add time-shifted fudge factor |3.5 | | |X| | | | | add "z=" |3.5 | | |O| | | | | add FWS |3.5 | | |X| | | | | removed added FWS |3.5 |X| | | | | | | | | | | | | | | |Signing by Domain t=s |3.10 | | |X| | | | | if set, d= equal i= domain |3.10 |X| | | | | | |Provide Agent or User Identity |3.11 | | |X| | | | | | | | | | | | | |Hashing: | | | | | | | | | Implement rsa-sha1: |3.3 | |X| | | |1| | truncate/convert from native form |3.3.1 | | | |X| | | | algorythm public exponent of 65537 |3.3.1 | |X| | | | | | Implement rsa-sha256: |3.3 |X| | | | | | | sign with rsa-sha256: |3.3 | |X| | | | | | truncate/convert from native form |3.3.2 | | | |X| | | | Implement other rsa algorithms |3.3.4 | | |X| | | | | Compute two hashes (bh=, b=) |3.7 |X| | | | | | | Signer compute hashes in order |3.7 |X| | | | | | | Verifier compute hashes in order |3.7 | | |X| | | | | Hash Message Body |3.7 |X| | | | | | | Hash h=, than DKIM-Signature |3.7 |X| | | | | | | end header with CRLF |3.7 |X| | | | | | | add non-existing headers |5.4 | | |X| | | | | treat as NULL string |5.4 |X| | | | | | | hash last header for duplicates |5.4 |X| | | | | | | Add multiple h= fields |5.4 | | |X| | | | | Sign each multiple field (Bottom to Top) |5.4 |X| | | | | | | Add additional h= fields |5.4 | | |X| | | | | Match header fields |5.4 | | | | |X| | | b= treated as NULL string |3.7 |X| | | | |2| | include all tags |3.7 |X| | | | | | | Hash 5322.From |5.4, 5.5 |X| | | | | | | Hash Any Header |5.4 | | |X| | | | | Hash Non-Persistent Headers |5.4 | | | |X| | | | Hash headers after body |3.7 |X| | | | | | | Include DKIM-Signature in own h= |3.7, 5.4 | | | | |X| | | Hash Other DKIM-Signature |3.7 | | |X| | | | | hash with c= methods |3.7 |X| | | | | | | hash after encoding |3.7 |X| | | | | | | verify incorporate hash before decoding |3.7 |X| | | | | | | verify computer hash before SMTP dbl dot |3.7 |X| | | | | | | | | | | | | | | |DKIM Messages | | | | | | | | | CR/CRLF translation |5.3 |X| | | | | | | Output RFC5322 |5.3 | |X| | | | | | Prepare Verifiers/Receivers |5.3 |X| | | | | | | Plain Text |3.7 | | |X| | | | | MIME format |3.7 | | |X| | | | | Convert to quoted-printable, base64 |5.3 | |X| | | | | | MUA/MSA perform conversion |5.3 |X| | | | | | | MIME format |3.7 | | |X| | | | | Sign MIME attachments |3.7 |X| | | | | | | Sign other DKIM-Signatures |4.2 | | |X| | | | | Add two DKIM-Signatures (SHA1, SHA256) |4.2 | | |X| | | | | Remove signed headers |4.2 | | | |X| | | | | | | | | | | | | Insert DKIM-Signature |5.7 |X| | | | |3| | Same as privious |5.7 |X| | | | |3| | b= set to new value |5.7 |X| | | | |3| | before others (prepend) |5.7 |X| | | | | | | | | | | | | | | |Canonicalization (C14N) | | | | | | | | | Implement "simple" |3.4 |?| | | | |4| | Implement "relaxed" |3.4 |?| | | | |4| | use C14N for minimum damage risk |5.5 | |X| | | | | | Add "c=" tag |3.4 | | |X| | | | | Add "l=" body length |3.4.5 | | |X| | | | | body length set to C14N length |3.4.5 |X| | | | | | | no intermediate processor, use l= |5,5 | | | | |X| | | for mailing list, set l= |5,6 | | |X| | | | | hash entire body |5,5 | |X| | | | | | set l=0 |5,5 | | | |X| | | | Add future C14N |3.4 | | |X| | | | | Change transmitted data |3.4 | | | | |X| | | "simple" header fields persistent |3.4.1 |X| | | | | | | "simple" header fields folded |3.4.1 | | | | |X| | | "simple" header fields WSP changed |3.4.1 | | | | |X| | | follow "relaxed" header algorithm order |3.4.2 |X| | | | | | | unfold "relaxed" headers |3.4.2 |X| | | | | | | remove "relaxed" header CRLF |3.4.2 | | | | |X| | | retain "relaxed" header colon separator |3.4.2 |X| | | | | | | follow "simple" body algorithm order |3.4.4 |X| | | | | | | remove "simple" body line CRLF |3.4.4 | | | | |X| | | | | | | | | | | |Public Key: | | | | | | | | | remove or revoke any time |6.0 | | |X| | | | | sign with at least 1024 bit |3.3.3 |X| | | | | | | add unknown tags |3.6.1 | | |X| | | | | ignore unknown tags |3.6.1 |X| | | | | | | add "v=DKIM1" first |3.6.1 |X| | | | | | | discard record not starting with "v=" |3.6.1 |X| | | | | | | add "h=" |3.6.1 | | |O| | | | | ignore ignore values |3.6.1 |X| | | | | | | add "k=" |3.6.1 | | |O| | | | | support "rsa" type |3.6.1 |X| | | | | | | ignore ignore values |3.6.1 |X| | | | | | | add "n=" |3.6.1 | | |O| | | | | add "p=" |3.6.1 |X| | | | | | | error with revoked keys |3.6.1 | |X| | | |5| | add "s=" |3.6.1 | | |O| | | | | ignore ignore values |3.6.1 |X| | | | | | | ignore unknown service type |3.6.1 |X| | | | | | | add "t=" |3.6.1 | | |O| | | | | ignore unknown flags |3.6.1 |X| | | | | | | t=y invalid signatures |3.6.1 | | | | |X| | | t=y track abuse |3.6.1 | | |X| | | | | t=s match i= and d= |3.6.1 |X| | | | | | | using t=s |3.6.1 | |R| | | | | | | | | | | | | | |DNS Binding: | | | | | | | | | DNS TXT |3.6.2 |X| | | | | | | Concatenate TXT RR strings |3.6.2.2 |X| | | | | | | Unique TXT RR |3.6.2.2 |X| | | | | | | | | | | | | | | |-----------------------------------------------|-----------|-|-|-|-|-|-| |VERIFIER ISSUES: | | | | | | | | | | | | | | | | | |Tag=Values | | | | | | | | | Ignore unrecognized tags |3.2, 3.5 |X| | | | | | |Verifiers implement SHA1, SHA256 |3.3 |X| | | | | | |support 512 to 1024 bits |3.3.3 |X| | | | | | |support larger than 1024 bits |3.3.3 | | |X| | | | |ignore unknown hash algorithms |3.3.4 |X| | | | | | |Verifiers implement c14n "simple" |3.4 |X| | | | | | |Verifiers implement c14n "relaxed" |3.4 |X| | | | | | |Verifiers ignore unknown c14n |3.4 |X| | | | | | |Treat DKIM-Signature as trace line |3.5 | |X| | | | | |Reorder DKIM-Signature |3.5 | | | |X| | | |Prepend DKIM-Signature |3.5 | |X| | | | | |Calculate "b=" as empty string |3.5 |X| | | | | | |Calculate unknown tags |3.5 |X| | | | | | |Unknown SDID invalid signature |3.5 |X| | | | | | |verifier implement q=dns/txt |3.5 |X| | | | | | |verifier invalidate expired signatures |3.5 | | |X| | | | |RFC5322 Input |3.8 | |X| | | | | |RFC2045 Input |3.8 | |X| | | | | |Output Verifier Status |3.9 |X| | | | | | |Output Verifier SDID |3.9 |X| | | | | | |Output Other Values |3.9 | | |X| | | | |Communicate SDID to Trust Assessor |3.11 |X| | | | | | |Communicate AUID to Trust Assessor |3.11 | | |X| | | | |Evaluate Independent Signatures |4.2 | |X| | | | | |Process Signatures in any other |4.2 | | |X| | | | |Check all signatures until first valid |4.2 | |X| | | | | |Limit total number of signatures |4.2 | | |X| | | | |Ignore PERMFAIL |4.2 | |X| | | | | |Invalidate RFC4409 Authorized Messages |5.3 | | | | |X| | |Mailing list check signatures |5.6 | |X| | | | | | make modifications |5.6 |X| | | | |6| | | | | | | | | | |border or MTA verify signatures |6.0 | | |X| | | | |MTA reporting signature results |6.0 | | |X| | | | |MTA implement policy |6.0 | | |X| | | | |Verify Order |6.0 |X| | | | | | | Extract signature in any order |6.1 | | |X| | | | | Assign multiple results meanings |6.1 | | | | |X| | | treat invalid sigs different than no sig |6.1 | | | | |X| | | Limit signatures |6.1 | | |X| | | | | cease processsing PERMFAIL |6.1 |X| | | | | | | cease processsing TEMPFAIL |6.1 |X| | | | | | | queue for retry verification |6.1 | | |X| | | | | process next signature |6.1 | |X| | | | | | record invalid |6.1 | | |X| | | | | Validate headers |6.1.1 |X| | | | | | | incorrect values invalid sigs |6.1.1 |X| | | | | | | incorrect v=1 invalid sigs |6.1.1 |X| | | | | | | missing required tag invalid sigs |6.1.1 |X| | | | | | | missing AUID set to "&lt; at &gt;"+SDID |6.1.1 |X| | | | | | | check AUID is SDID or subdomain |6.1.1 |X| | | | | | | mismatch invalid sigs |6.1.1 |X| | | | | | | missing h=from invalid sigs |6.1.1 |X| | | | | | | expiration invalid sigs |6.1.1 | | |X| | | | | invalid signer invalids sigs |6.1.1 | | |X| | | | | prepare unacceptable domains |6.1.1 | |X| | | | | | invalid sig for any reason |6.1.1 | | |X| | | | | Public key | | | | | | | | | retrieve key record using g=, d=, s= |6.1.2 |X| | | | | | | tempfail retried later |6.1.2 | | |X| | | | | permfail for missing key |6.1.2 |X| | | | | | | validate key record |6.1.2 |X| | | | | | | invalidate malformed records |6.1.2 |X| | | | | | | invalidate incorrect v=DKIM1 tag |6.1.2 |X| | | | | | | invalidate mismatch key h= and sig a= |6.1.2 |X| | | | | | | invalidate missing p= |6.1.2 |X| | | | | | | invalidate mismatch k= and a= |6.1.2 |X| | | | | | | Compute Verification | | | | | | | | | case-insensitive headers |6.1.3 |X| | | | | | | invalid body hash mismatch |6.1.3 | |X| | | | | | invalid header hash mismatch |6.1.3 | |X| | | | | | Reporting | | | | | | | | | Insert report headers before sig |6.2 | |X| | | | | | Use AUTH-RES |6.2 | | |X| | | | | remove AUTH-RES from other systems |6.2 | | |X| | | | | Interpretation | | | | | | | | | Consumers not accept invalid sigs |6.3 | | | |X| | | | DATA permanent rejects 550 5.7.X |6.3 | |X| | | | | | DATA temporary rejects 45x |6.3 | |X| | | | | | use 45x for crypto failures |6.3 | | | | |X| | | use 451 4.7.5 |6.3 | | |X| | | | | convey to identity assessor |6.3 |X| | | | | | | highlight SDID mismatch with From.Domain |6.3 | |X| | | | | | log failures |6.3 | |X| | | | | | treat invalid sigs as no sigs |6.3 | |X| | | | | | | | | | | | | | |Security | | | | | | | | | Verify key records from DNS |8.7 |X| | | | | | | Be prepared for malformed DKIM-Signatures |8.8 |X| | | | | | | Verify ignore unlikely domains |8.13 | | |X| | | | | | | | | | | | | +-----------------------------------------------------------------------+ FootNotes 1. No explicit statement for signer and sha1 2. is a NULL string an asciiz String? 3. Section is confusing, mixes up sections (i.e. "previous steps" ... what steps?) 4. There is no explicit statement for a signer MUST implement simple or relaxed, unlike explicit MUST statements for verifier. 5. Should this say "invalid signature"? 6. Ambiguous? </pre> Hector Santos 2011-05-20T23:30:22 http://comments.gmane.org/gmane.ietf.dkim/16629 <pre>Hi, all, recently someone asked me whether it would have any added value if the DKIM public key, which is stored in DNS, would be 'certified' in some (yet to be determined) way by a 3rd party like VeriSign, Thawte etc.? My first reaction was, that it made no sense, but I'm no longer sure whether that's the only possible answer. For example: does it have an added value if a VeriSign Trust Seal certificate would be used for the DKIM public key? Maybe I should send this question to the domainrep list, as 'certifying' a DKIM public key may have more to do with domain reputation and accreditation then with DKIM itself. Anyway, any thoughts on this topic appreciated. /rolf </pre> Rolf E. Sonneveld 2011-05-19T21:32:31 http://comments.gmane.org/gmane.ietf.dkim/16622 <pre>Can anyone remember why there's a SHOULD for the downgrade to 7-bit in RFC4871 Section 5.3, rather than a MUST? The likelihood of breakage is so high when sending 8-bit data that DKIM almost becomes pointless without the upgrade. Not advocating for this to be changed in -bis (yet), but someone's asking me for the history behind that decision. </pre> Murray S. Kucherawy 2011-05-19T17:50:18 http://comments.gmane.org/gmane.ietf.dkim/16597 <pre>Version -10 says More formally, pseudo-code for the signature algorithm is: body-hash = hash-alg (canon-body, l-param) data-hash = hash-alg (h-headers, D-SIG, content-hash) signature = sig-alg (d-domain, selector, data-hash) where: body-hash: is the output from hashing the body, using hash-alg. Shouldn't it say More formally, pseudo-code for the signature algorithm is: body-hash = hash-alg (canon-body limited by l-param) data-hash = hash-alg (h-headers, D-SIG with body-hash) signature = sig-alg (d-domain, selector, data-hash) where: body-hash: is the output from hashing the body, using hash-alg. It is set as the value of the bh= tag in D-SIG for computing the data-hash. ? </pre> Alessandro Vesely 2011-05-17T16:52:39 http://comments.gmane.org/gmane.ietf.dkim/16538 <pre>Oh wow! This is nuts! With all the issues with l=, I saw it mostly with spammers, or some eMarketing source. But I would never expected a major US bank to use the Body Length Tag especially when they don't really need to. Summary Problem: Domains sending DKIM signed DSN with the Body Length Tag (l=) set. This happen with a major US bank when a bad guy sent a spoofed message using an unknown user bank email address to our list server and the MLM issued a non-membership notification. When the bank got the notification to the unknown user which it first accepted at the SMTP level, it then created a non-delivery DKIM signed DSN with the "l-" tag set. So whats gan we learn from this? 1) It appears to me the signers or its software is mis-interpreted the specification and are blindly setting the "l=" tag for all its mail, including needlessly with a DSN. 2) I looked in RFC4671bis and see no guidance regarding signing bounce mail, but it MUST NOT be done with "l=" tag set. 3) MLM should be using a NULL return path for its notifications. Not all MLM do this when it comes to list notifications. A List non-membership notification should be viewed as a SMTP 550 no local user account rejection. Comments? </pre> Hector Santos 2011-05-15T04:24:42 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.dkim