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) specif</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 Identifie</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 Summ</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 Summ</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</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 si</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 DKI</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</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</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 fo</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 o</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.</pre> Hector Santos 2011-05-15T04:24:42 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.dkim