Re: [ietf-dkim] Final update to 4871bis for working group review
On Jul 11, 2011, at 6:56 AM, Murray S. Kucherawy wrote: Given that today's the deadline, we will have to go with something like this or nothing at all (which in fact I would prefer because I think all of this is adequately covered by existing text, and I believe consensus and the AD concurs) +1 to letting the clock run out. What we have is more than sufficient. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Doublefrom language should be in ADSP, not core
On Jul 11, 2011, at 7:49 AM, Dave CROCKER wrote: On 7/10/2011 7:51 PM, Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman Sent: Sunday, July 10, 2011 6:46 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Doublefrom language should be in ADSP, not core I think we should make it clear that singleton header fields like From (and Subject and Date) can be added without breaking signatures unless one is careful as a signer and/or a verifier. This is related to a core DKIM design principle and doesn't need ADSP (or other non-standard measures) for it to be something we should care about. I think the language we've proposed in response to the DISCUSS covers this appropriately. +1 +1 -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Enough already, Final update to 4871bis for working group review
On Jul 8, 2011, at 7:05 AM, John R. Levine wrote: I'm not seeing much agreement on any changes to Murray's final draft, so may I suggest that it's good enough and we should ship it? The potential benefit of the proposed changes doesn't impress me as worth the amount of argument they're provoking. +1 Having the same argument again and again hasn't and won't convince anyone to change their minds. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Final update to 4871bis for working group review
On Jul 2, 2011, at 9:58 PM, John R. Levine wrote: Please review and comment by 11 July. I would have liked to strip even more of the cruft out of 4871bis, but this is considerably better than the previous draft. Ship it. Regardless of any remaining cruft, I'm glad to see this particular cruft removed. I think Pete made the right call. Ship it. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Certifying the DKIM public key?
On May 22, 2011, at 12:27 PM, John R. Levine wrote: It occurs to me that since mail certification is likely to make assertions about behavior as well as identity, the SSL model in which certs last for a year won't work, since behavior can change rapidly. Either the certifier has to issue a stream of short-term certs to everyone it certifies, or the verifiers have to check CRLs, which is tedious. By the time you do all that, a DNS check, even one with DNSSEC, looks pretty attractive. That's how it works at the IP level today. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 8bit downgrades
On May 19, 2011, at 4:53 PM, Pete Resnick wrote: In RFC 2119 (the document that defines MUST, SHOULD, etc.), MUST does not mean vitally important and SHOULD does not mean really really important, but less important than MUST. MUST means you have to do this or you're not going to interoperate. SHOULD means, there are ways to not do this which will still interoperate, but you had better know what those ways are and you better be sure to do them, and if you don't, then you MUST NOT do this. That is, SHOULD is equivalent to MUST unless you know exactly what you are doing. Sounds like we SHOULD all go back and re-read RFC 2119. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
On May 15, 2011, at 9:42 PM, Barry Leiba wrote: The author can be a human using an MUA (Mail User Agent) or an automated mail robot with an MTA. I don't see that automated mail robot with an MTA is right at all. But I see what you're getting at, and I'd support a change such as this: The author can be a human using an MUA (Mail User Agent) or an automated process that may send mail (for example, the cron Unix system utility). +1 -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
On May 13, 2011, at 3:40 PM, Rolf E. Sonneveld wrote:
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.
+1
--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLM and C14N
On May 15, 2011, at 8:44 AM, John R. Levine wrote: Hi Hector, At 15:20 14-05-2011, Hector Santos wrote: Shouldn't the MLM I-D say something regarding C14N and CR/LF related mutations? No. +1 to the No. +1 to the No. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Issue: Consider deprecating l=
On May 9, 2011, at 5:14 PM, John Levine wrote: I think it was a mistake to include l= in the first place, but I find Murray's arguments against taking it out now persuasive. Agreed (which is a -1 to removal.) I would also really like to have a better idea of how people are using it, notably, for all those messages where l= doesn't cover the whole body, what's in the naked part. Agreed. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] I-D ACTION:draft-ietf-dkim-mailinglists-08.txt
On May 8, 2011, at 11:16 PM, Murray S. Kucherawy wrote:
-Original Message-
From: Franck Martin [mailto:fmar...@linkedin.com]
Sent: Sunday, May 08, 2011 9:12 PM
To: Murray S. Kucherawy; ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] I-D ACTION:draft-ietf-dkim-mailinglists-08.txt
such as a signing and author subdomain {DKIM 12} - such as a signing
and author subdomain {DKIM 12} or a totally different domain
I'm on the fence on this one. Does anyone else have an opinion?
It is a best practice document so the full realm of possibilities should
be included.
It doesn't make general sense to list all possibilities in something that's
supposed to espouse a best practice. Although you're right that it could be
any domain, I think the best practice when it comes to creating mail streams
is the subdomain option.
Agreed, that seems to be the best currently-deployed practice.
Do you have some specific text you want to propose here? I couldn't
imagine any based on this comment.
Yes it is hard, because we don't want to endorse any product/service. Let
me try.
Some MTA senders and receivers can enter in bilateral agreements or via a
third party to receive out of band reports on failed signatures.
That's true, but is it advice specific to the MLM environment? And is 5.2
the right place to talk about this?
It'd fit nicely into a separate BCP on handling signature failures -- perhaps
after there's more widespread operational experience with
draft-ietf-dkim-reporting?
5.3 postmaster should inform their users that messages are likely to be
discarded if sent via a MLM.
Is this inbound or outbound? I assume inbound given the title of the
section. But again I couldn't concoct text in my head to match your
remark. Can you propose some?
I thinking outbound. As this document is to give postmasters a quick
start, then it is good to mention if you choose ADSP, there is no way
the message can go via a mailing list and survive. I thought it was
possible before reading this RFC that you could tweak a MLM in a manner
that ADSP would not break, but I realize while possible it is absolutely
impractical and as you say a cooperating MLM better drop the message out
front.
What I'm worried is that it does not set a mindset with other email
policies that can be created.
I think it's safer to let the MLM operator decide, since that person knows
whether or not the list software will tend to break signatures on messages it
re-sends.
Or if they don't know, this will encourage them to find out.
--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Ticket #24
On May 6, 2011, at 11:21 AM, Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of John Levine Sent: Friday, May 06, 2011 11:15 AM To: ietf-dkim@mipassoc.org Cc: barryle...@computer.org Subject: Re: [ietf-dkim] Ticket #24 I appreciate the work that Doug and Charles put into their proposal, but for reasons already discussed, I think we should leave section 6.1 as is in -09. +1. Sections 3.8, 8.14 and 8.15 already say enough about this issue. +1 -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Ticket 23 -- l= and Content-type
On May 1, 2011, at 10:15 AM, Dave CROCKER wrote:
On 4/30/2011 11:43 PM, Murray S. Kucherawy wrote:
I'd like to leave in MIME and HTML exploits as examples if people agree that
wouldn't be harmful, such as this updated text in 4.4.5:
tINFORMATIVE 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,
{DKIM 2} perhaps based on other criteria./t
I'm worried that without this, a neophyte won't see what the attack is.
+1
+1
--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output requirements
On Apr 29, 2011, at 12:18 PM, Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Alessandro Vesely Sent: Friday, April 29, 2011 12:03 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output requirements How about mentioning ignored signatures, e.g., The output MAY include further data, such as properties or result meta-data of any signatures, including ignored ones, for use by modules that consume those results at any stage of the verification process. (Just to make clear that all the SHOULD ignore are not conflicting with this.) Works for me. +1 -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Ticket 23 -- l= and Content-type
On Apr 29, 2011, at 12:32 PM, John R. Levine wrote: On Fri, 29 Apr 2011, Murray S. Kucherawy wrote: On further consideration, I'm with Dave. Suggest removing the current language about l= and MIME boundaries, and replace with a note that if you use l=, added content can change the appearance of a message in hard to anticipate ways. Replace the whole section with just that, or only the first paragraph? Sheesh, you actually want me to read the thing? Oh, all right. In 4.4.5, delete Signers of MIME messages that include a body length count SHOULD be sure that the length extends to the closing MIME boundary string. Also delete the subsequent INFORMATIVE IMPLEMENTATION NOTE. The note earlier in the section says the bad guy can replace the displayed contents, so I don't think we need to say it again. +1 to three changes above. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
On Apr 20, 2011, at 4:36, bill.ox...@cox.com wrote: Indeed lack of support for 3rd party signers was where I gave up any interest at all in adsp As I remember it, there was (or appeared to be) consensus to get ADSP out there for testing by the entities it might work for, AND simultaneously work on something for the 3rd party scenarios. What ever happened to that work? I know there were a couple of drafts, and Murray added support for one to OpenDKIM...if the 3rd party stuff is really that important, why isn't anyone using it? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
On Apr 18, 2011, at 1:23 PM, Michael Thomas wrote: Murray S. Kucherawy wrote: If ADSP is too weak or dangerous a protocol, and there are no current viable alternatives, then failing to beat the streets to get the industry to deploy it is an act of responsibility, not one of omission or laziness. My feeling is that it conflicts with too many (would-be) industry third parties' self interest in selling reputation/policy, and hence why the FUD bullhorn was on full blast through the entire exercise, and remains on to this day. Could you provide some evidence of reputation/policy vendors spreading FUD about ADSP? Press releases, blog posts, even links to mailing list archives. It's possible that it happened, but if so I'd really like to know who was doing it. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Working Group Last Call on 4871bis// A-label requirement
On Apr 19, 2011, at 3:35 PM, John R. Levine wrote: Sorry, this message makes no sense. The IETF has been working on non-ASCII domain names and e-mail for over a decade, and we are certainly not going to do random things that ignore that effort and the many RFCs that describe the use of IDNs in the DNS. Sounds like what we actually need is some way to point to the relevant work elsewhere in the IETF, even though it's apparently a moving target with many strong opinions continuing to shove it in multiple directions. Is it permissible to simply reference the working group's tools page? -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Issue: Repeated headers
On Apr 19, 2011, at 3:55 PM, John R. Levine wrote: I don't want to re-hash all the arguments. What we have is a compromise between two hard-argued positions, and I think reopening it now will just drag everything out even longer. I agree that the current language addresses the issue about as well as it could be addressed, and see no advantage in rearguing it. +1 -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Working Group Last Call on 4871bis
On Apr 12, 2011, at 1:14 PM, Barry Leiba wrote: Please post minor editorial things to this thread. In 3.1, the examples of selectors are january2005 and february2005 and such, which clearly shows the age of the text. Maybe update 'em to 2011? (This may be the most minor nit ever.) -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: verifier message editing language
On Apr 12, 2011, at 6:03 PM, John R. Levine wrote: Per Murray's request, here's just the changes to take out the verifier message editing +1 to these changes. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Working Group Last Call on mailinglists
On Apr 12, 2011, at 1:18 PM, Barry Leiba wrote: Please post minor editorial things to this thread. If you find substantive issues, please start a new thread for each, and prefix the subject with Issue:. As we discuss those, if any come up, let's keep the discussion focused on the issue. The abstract and introduction both talk about an ADMD, but I'm not sure that's right. The ADMD is /often/ equivalent to the DNS domain, but not always. And actually, lists are a pretty good example of when they're separate: all my lists are on a Mailman installation that's configured as lists.disgruntled.net, but some of the lists' addresses are in other domains -- and they're all signed with d=disgruntled.net on the way out. So, I think allows a DNS domain to assume some responsibility would be more accurate. The background section refers to an agent of the email architecture instead, which may also be more accurate. (Or maybe it allows an ADMD to /assign/ responsibility to a DNS domain? But that's a more confusing concept, and I don't think this document is the place to wrestle with those issues.) Last paragraph of the introduction: As each type has... (not types) Section 1.3 feels out of place, but I'm not sure how to improve it. Maybe move all of the FBL-related text (currently 1.3, 5.9, and 6) to a single section? Section 3.3, Major body changes: insert should be inserting First paragraph of 4.1 reads oddly; perhaps: ...the author SHOULD be cautious when deciding whether or not to send a signed message to the list. Final paragraph of section 5.1 reads oddly as well; perhaps Expressions of list-specific policy (e.g., rules for participation, small advertisements, etc.) are often added to outgoing messages by MLM operators. ... This sort of information is commonly included in footer text appended to the body of the message, or header text prepended above the original body. The first [ADSP] in 5.2 isn't an xref. Later in that paragraph: ...a resending MLM SHOULD reject outright any mail from an author whose domain posts such a policy, as those messages are likely to be discarded by any ADSP-aware recipients... In that same paragraph, it may not be necessary to talk about discouraging subscribers -- that's covered in 5.3. In 5.5, suggest removing although this is not yet formally documented because this document is documenting it. *grin* When mentioning FBLs in 5.7, it'd be helpful to have a reference to section 1.3. Later in 5.7, should we stipulate that a DKIM-aware resending MLM SHOULD NOT use the l= tag? In 5.10, third paragraph: replace deliverability with delivery (or just other issues.) Should the security considerations section also explicitly refer to (see also...) the security considerations from [DKIM], [ADSP], et cetera? Appendix A: I prefer J.D. rather than JD, though neither is technically accurate. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: non-ascii header text
On Apr 13, 2011, at 12:07 PM, Dave CROCKER wrote: On 4/13/2011 10:31 AM, J.D. Falk wrote: I'm generally in favor of updating the document to match the current state of IDN and EAI work, but I don't know it well enough to comment intelligently on whether John's proposed text does so. as phrased, I'll disagree with this. one spec should not try to track fluid developments of other specs. it should cite stable specs, and preferably ones that have gained adoption. Yeah, that's a good point. If that work isn't stable yet, it may be better to simply point to the working group. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)
On Apr 2, 2011, at 12:02 AM, Murray S. Kucherawy wrote: OpenDKIM's statistics show that almost half of signatures use i=, in contrast to how few used g= in other than the default way. Of those that do, only about 35% are using it in other than the default way. So that's at least 17% of signatures overall that are trying to do something with i=. That's non-trivial. I was about to ask you if there were stats on i= usage. I agree, that's far too many to just dump it without figuring out why those 35% are using it. So, count this as -1 towards removing it, at least until we know more. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Security Area Directors
On Mar 19, 2011, at 8:50 AM, Mark Delany wrote: Many thanks to Stephen for doing a sterling job. I'm sure the success of this WG is largely due to having competent, caring and persistent chairs who have pulled us back from many a rat-hole and dead-end to maintain our focus on delivering the end-product. Much appreciated. +1 -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re-thinking the organization of the DKIM spec
On Jan 11, 2011, at 4:12 AM, Eliot Lear wrote: 2. The mechanisms in DOSETA were designed for DKIM. If we are generalizing along the lines that Dave has mentioned, I would prefer that DOSETA in particular not advance to draft status, as it ought to be tested in at least two separate applications for a time. Otherwise we run the risk of ossifying something prematurely. This is a good point. But also, speaking of ossification, seems like it'd be far more annoying in the long run to create DOSETA as something entirely parallel to DKIM, and have DKIM not reference it -- in other words, two nearly-identical parallel specifications. It's not an easy or obvious decision, and I appreciate that we're having a frank and friendly discussion about it. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposed documentation split between DKIM and DOSETA
On Jan 7, 2011, at 3:48 PM, Rolf E. Sonneveld wrote: • it has taken some four years to make DKIM what it is now. And with that, I don't mean the protocol specification itself, but I mean adoption, deployment, acceptance of DKIM, the level of knowledge about DKIM within organizations, reputation of the spec. etc. Although the adoption rate may seam slow, over time we see real progress in the percentage of DKIM signed messages. Today someone forwarded me the following announcement of Google: http://googleappsupdates.blogspot.com/2011/01/email-authentication-using-dkim-now.html . My concern is that, after all these years, now redefining what DKIM is, will certainly not help acceptance and deployment growth. It may work counterproductive and it may make organizations afraid of investing in such a changing technology, even if the changes are much smaller then they seem to be. Technology is one thing, Public Relations is something completely different. • although I understand the reason why you would like to redefine DKIM and make a distinction between the core elements (DOSETA) and the mail-specific implementation of these elements (DKIM), in my view it's too late to make this split. Splitting up these things will cause a lot of confusion with the public (CEO's that need to decide whether to invest in something like DKIM). Let us be realistic: today many people don't exactly understand what DKIM does; the discussions about DKIM on this ietf-dkim list illustrate this very well (see threads like 'What DKIM provides, again' and 'The usual misunderstanding about what DKIM promises' etc. etc.). Even on this list there is no consensus about what DKIM really is. Splitting up DKIM now will mean even less people understand what we're doing here and what DKIM really is. So to summarize: from a technology point of view it may be a good idea to make this split, from a DKIM acceptance point of view this will turn into a deception. I absolutely understand where your concerns come from -- I've been working on the political layer of DKIM for years too -- but I'm not sure I agree that this split would cause us to return to the bad old days of companies refusing to implement because it's just a draft. We'd still have DKIM, it'd still be called DKIM, and (I assume) it'd still be in a document called DomainKeys Identified Mail (DKIM) Signatures. (Though I wonder: would it remain RFC 4871 after the split?) We'd also have a new thing, DOSETA, which we could (quite accurately) point to as another example of the rightness of the original DKIM approach. And when DOSETA is used to add an authentication layer to other technologies, the proponents can approach the political layer by calling it DKIM for foo, immediately gaining a positive comparison. But the main reason I like the approach Barry and Dave have been describing is that it gives us a way to take all this effort -- both technical and political -- and apply it to other forms of messaging. Examples I've seen so far include SIP calls, RSS articles, XMPP messages...and those are just the open, standard protocols. Even if there is some political risk -- and I admit there's some, though I believe it'll be minor -- I'd say the potential benefits outweigh the risk. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Getting resolution on the double header issue
On Nov 8, 2010, at 1:20 AM, Barry Leiba wrote: 2. The DKIM spec should probably say that signers need to sign valid messages, and, therefore, SHOULD NOT sign things like this. Text along the line of this might work well: Signers SHOULD take reasonable steps to ensure that the messages they're signing are valid according to [RFC 5322, etc]. Leaving the definition of reasonable out allows flexibility. It may be waffly, but I like the approach in this case. +1 3. It'd be reasonable for the DKIM spec to remind verifiers that signers aren't supposed to sign stuff like this, so they might consider that when deciding what to do with it after verification. It'd be reasonable to remind them of this particular case. But I think that all ought to be informative text. Seems unnecessary per #2 above, but I don't care all that much either way. 4. We should agree to this or some variant of it, and then move on. This is not meant to satisfy everyone. In fact, it isn't what I'd prefer, if I had my full choice. But it takes care of the problem in a way that I think is sufficient, and allows us to resolve the issue. +1 On Nov 8, 2010, at 7:52 AM, Scott Kitterman wrote: Rather than fall back purely on 5322, I'd prefer to see something in security considerations that says if the count of a particular header field that is supposed to be limited (e.g. From and Subject) present in a message exceeds the number of signed fields, then the signature shouldn't be verified. I'd have no objection to this either. At this point the only strong objection I'd have would be if the consensus measurement were based on one or two people repeatedly expressing Very Strong Feelings while the rest (like me) mostly don't care. A meh result is not the same as a yes or no. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] I-D Action:draft-ietf-dkim-mailinglists-04.txt
On Oct 16, 2010, at 9:36 AM, Alessandro Vesely wrote: *scope* Apparently, there is consensus that Discussion lists and broadcast lists are not the same thing [WV]. Section 3.2 exemplifies newsletters and bulk marketing mail as authoring MLM modes. In facts, most of the advice covers mailing lists proper. Should ESP-lists be removed from the I-D entirely, e.g. by saying they are not covered right after their definition? I think it's important to point out the differences. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] More on layer violations
On Oct 21, 2010, at 11:01 AM, Steve Atkins wrote: On Oct 21, 2010, at 9:53 AM, Murray S. Kucherawy wrote: Take a tour through the eleven parts of Section 7 of RFC5451, and then Appendices A and C. They provide all kinds of warnings about misinterpreting the data provided, which amounts to pretty firm implementation advice, and identifies ways you can shoot yourself in the foot. But none of those sections are normative. (Actually there are two SHOULDs in 7.4, but in retrospect they shouldn't really be there.) That's what I'm advocating here: The normative stuff defines the core mechanics of the protocol itself, and the informative stuff explains why it's done that way, detailed implementation advice including stuff about other layers, and how one should (and shouldn't) interpret the output. +1 +1 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
On Oct 14, 2010, at 5:09 AM, Dave CROCKER wrote: On 10/13/2010 1:52 PM, Jim Fenton wrote: I propose removing section 3.6.1.1 in its entirety. Not only do I support this, but I think we can remove all references to DomainKeys, except for the obvious historical reference to its role as input to DKIM. At the time DKIM was developed, worrying about compatibility with, and transition from, DomainKeys was essential. Now it isn't. +1 We've done a surprisingly good job of getting the word out that DK is over and DKIM is the future. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On Oct 13, 2010, at 1:59 PM, Mark Delany wrote: On Wed, Oct 13, 2010 at 04:09:34PM -0400, MH Michael Hammer (5304) allegedly wrote: Having said that, if an MUA is going to present an indication of DKIM PASS to the enduser, then a reasonable person would expect some relationship between what is passed and what is presented to the enduser. That makes sense. And at least one MUA already renders DKIM verified mail differently. I would think such an MUA could take the additional step of rendering verified payload differently too. I know we're not in the MUA business, but if DKIM makes no difference to what an end-user finally sees, then it serves a very limited purpose indeed. I'm looking forward to a draft on MUA considerations for DKIM. With all these opinions on the matter being expressed so adamantly, somebody must have already started one...right? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] signing and verifying invalid messages
On Oct 5, 2010, at 4:45 PM, Michael Thomas wrote: On 10/05/2010 01:36 PM, John Levine wrote: Still, though, it's a solution to deal with malformations to which MUAs are susceptible, and not strictly a DKIM problem. Would it be a good idea to recommend in 4871bis that DKIM implementations should not sign or verify invalid messages? I cheerfully admit that I haven't thought out all the implications thereof. I'd suggest that it would be better to take that up with rfc5822-bis since this is hardly a dkim-specific problem. +1 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
On Oct 6, 2010, at 1:22 AM, Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Mark Delany Sent: Tuesday, October 05, 2010 8:06 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE There was an assertion in RFC4780 about conforming emails that must only have a single 2822.From header. That got lost in the translation to 4781 I guess. Unfortunately, 4780 failed to specify what conforming means explicitly. I also know that this WG has repeatedly stated that messages that are not within standard MUST fail verification. That this is not in 4871 seems to be mostly a WG assumption that should be made explicit. I think several of us thought it was in there, but on review it apparently was indeed lost somewhere along the way. We've certainly, as I understand it, been proceeding from that assumption for a very long time. I like the idea of saying so explicitly in 4871bis, and applying it both to signers and to verifiers. +1 I don't like the idea of being any more specific than that. That is, I don't want to create specific text for specific cases we know about because that means anything we don't list could be perceived as less critical. A blanket admonishment to implementers is sufficient and appropriate. +1 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Working group last call on draft-ietf-dkim-implementation-report
On Oct 4, 2010, at 5:06 PM, John R. Levine wrote: to Draft Standard. Everyone please review it, and post comments/issues. Please also post here if you've reviewed it and think it's ready to go. I have reviewed it, and it looks ready to go. +1 Regarding Hector's complaint, I think a separate usage report focused on 1st/3rd party signing practices may be appropriate -- but I don't think it makes sense to hold up the advancement of the DKIM base spec for that. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Discussion lists and broadcast lists are not the same thing
On Sep 24, 2010, at 11:05 AM, John Levine wrote: Do concepts generalize enough to allow issuing draft-ietf-dkim-mailinglists also for these authoring MLMs? No. All of the complications in mailing lists arise from the fact that the author of the message is not related to the operator of the list. Even though ESPs are generally sending mail on behalf of customers, their relationship to the customers allows them to be the customer, as far as mail authentication is concerned. There are some issues about how a customer delegates part of its identity to its ESP, but they are completely, totally, unrelated to the MLM issues we've been arguing about. A document on those delegation issues might be helpful also. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-lindsey-dkim-mailinglists-00
On Sep 15, 2010, at 2:35 PM, IETF I-D Submission Tool wrote: Filename: draft-lindsey-dkim-mailinglists Nice work. I totally understand what you're trying to do there, and it all seems consistent with the idea of separating things that have been tried from things that haven't been tried. So, I think the obvious next question is: who's trying it? Seems like it wouldn't take all that much testing to figure out whether or not this idea will work on today's mail systems. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-vesely-dkim-joint-sigs
On Sep 16, 2010, at 11:03 AM, Alessandro Vesely wrote: On 16/Sep/10 13:05, MH Michael Hammer (5304) wrote: Ian, this makes no sense to me. If a signing domain is concerned enough to choose to implement ADSP, why would they reduce what they are signing to accommodate a small percentage of their mail going to MLMs that they may or may not be able to identify? I don't remove the locks on my doors because there is a possibility that someone might break one of my windows. I've said it before and I'll say it again. MLMs are the tail, not the dog. Don't wag the dog. Messages can also be replayed as-is, for the sole purpose to game the author domain's reputation. DKIM can sign To: and Cc:, but not Bcc:, and then these are not tied to the actual recipients list. This wagging is about delimiting message streams, hence it's not necessarily tied to MLMs only. If this is primarily a workaround for perceived limitations of reputation systems, then I humbly suggest that the premise is invalid. Today's reputation systems aren't static; the operators are constantly changing them in reaction to what the spammers do. If the spammers start replaying DKIM-signed messages in order to game reputation systems, the operators WILL adjust. A scheme like this, rather than helping, may make those adjustments more complex and difficult. Are there other use cases? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] RFC4871 5322.From Binding - Proposal to relax it.
On Sep 16, 2010, at 5:58 AM, bill.ox...@cox.com bill.ox...@cox.com wrote: we can discuss it for the very reason you pointed out, people want to use/sell 3rd party signing, so lets discuss a policy and write it up. I know my company wants one and I suspect a few others might as well. I know that some folks fought very hard to keep it out originally but as I pointed out then, its time will come One of the original intentions behind publishing ADSP with only author domains was that we'd try that for a while, and then hopefully understand the ramifications well enough to devise a protocol that can handle non-author (non-From:) domains. Since that hasn't happened yet, is there another approach we could try for gaining this understanding? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-vesely-dkim-joint-sigs
On Sep 17, 2010, at 2:50 PM, Murray S. Kucherawy wrote: If this is primarily a workaround for perceived limitations of reputation systems, then I humbly suggest that the premise is invalid. Today's reputation systems aren't static; the operators are constantly changing them in reaction to what the spammers do. I realize that the answer to this will be largely speculation, but: Will that continue to be true in the IPv6-based and domain-based future of reputation systems? Having to make ongoing adjustments might be a hindrance to such systems. It's always a hinderance, sure, but there's nothing inherent to IPv4 which makes the adjustments necessary. Adjustments to reputation systems are necessary because spammers keep changing tactics, attempting to get around the reputation systems. And, patterns in legitimate mail change over time as well; it wasn't so long ago that Facebook notifications were getting caught by spam filters looking for similarity, which makes sense because they're all extremely similar -- and there's a lot of volume. Any reputation system, or filter, or other anti-spam method which isn't reacting to changes will quickly become either ineffective at catching spam or ineffective at not catching non-spam, and people will stop using it, and pretty soon it'll be forgotten. The same is true of other areas of security...the only constant is change. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] In the spirit of moving forward...
On Sep 15, 2010, at 7:16 AM, McDowell, Brett wrote: It was my understanding that the MLM BCP was intended to inform MLM operators of what they should do with DKIM-signed mail. More of what they COULD do than what they SHOULD do, IIRC. And, that may provide a path to compromise: keep everything as less-than-SHOULD (but still limited to very minimal changes required to MLMs), publish as Experimental, and wait for the Best Current Practices to emerge. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
On Sep 14, 2010, at 9:52 AM, Murray S. Kucherawy wrote: I don't think ADSP discardable means simply throw it away because it leaves out the ifs that are supposed to be in front of it. That simplified interpretation presupposes the message will pretty much always arrive signed but not verifiable, meaning you basically don't believe DKIM can be trusted to work. How about: It is important to us that this arrive at your inbox signed by us and unmodified. You should not keep it if that is not the case. ...which is how I read the RFC. And what the proponents intended when we wrote it. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] DKIM+ADSP = FAIL, and it's our fault
...but not for the reasons the anti-ADSP folks keep bringing up. DKIM is failing because every discussion about actually /using/ DKIM inevitably gets stuck in the same old argument about ADSP. Doesn't even matter what the argument is about anymore; it stops all forward progress every time. And we keep letting it happen -- actively participating, even, including me. Continuing to argue these same points over and over is disrespectful of our colleagues both on and off this list, and of the IETF process. So I'm going to stop, and I beg you all to join me. Stop arguing, and start writing drafts. Let us discuss the drafts instead of attacking each others' intractable positions for the Nth time. If you think ADSP will bring about the end of all human communication, WRITE A DRAFT EXPLAINING WHY. If you think something else, write that instead. Yes, I know it requires more effort, but what we've been doing so far clearly isn't working. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
On Sep 10, 2010, at 7:08 PM, John Levine wrote: Beyond that, you're right, we're at best guessing and at worst pulling stuff out of our whatevers. But if that stuff was signed before entering our whatevers, how can we verify the signature when pulling it out? This question may entirely invalidate assumptions that nobody ever actually made about somebody else's theoretical wiping policy! ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
On Sep 10, 2010, at 12:34 PM, John R. Levine wrote: The problem is that too many people on this WG take the view I believe in solution-X (TPA, PGP-MIME, don't use ADSP because it's broke, don't use mailing list if you advertise 'discardable') and I will vote down any solution other than X. Call me old-fashioned if you will, but I take the view that a purely hypothetical paper design to address a largely hypothetical problem, with unknown security problems, unknown user interface problems, and unknown interoperation problems have no place in a document about actual e-mail practice. +1 It's the difference between Best Current Practices and Things We Thought Of But Haven't Tried Yet. Either could be published as an I-D, but we shouldn't try to fit both approaches into the same BCP. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] misunderstandings about yahoo (was Re: Key rotation)
On Sep 10, 2010, at 6:55 AM, Jeff Macdonald wrote: http://feedbackloop.yahoo.net/ Step 2 doesn't help. (yes, you can put * for all selectors, but asking for one when it isn't really needed leads to FUD). That's a complaint feedback loop. Totally separate system. (Yes, some mailbox providers use complaint feedback loop participation as an input to their whitelisting decisions, but that's not reputation.) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
On Sep 10, 2010, at 2:53 PM, J.D. Falk wrote: On Sep 10, 2010, at 12:34 PM, John R. Levine wrote: The problem is that too many people on this WG take the view I believe in solution-X (TPA, PGP-MIME, don't use ADSP because it's broke, don't use mailing list if you advertise 'discardable') and I will vote down any solution other than X. Call me old-fashioned if you will, but I take the view that a purely hypothetical paper design to address a largely hypothetical problem, with unknown security problems, unknown user interface problems, and unknown interoperation problems have no place in a document about actual e-mail practice. +1 It's the difference between Best Current Practices and Things We Thought Of But Haven't Tried Yet. Either could be published as an I-D, but we shouldn't try to fit both approaches into the same BCP. Forgot to mention: I'd totally support the creation of a separate draft listing Things We Thought Of But Haven't Tried Yet, so long as it's clearly labeled. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Key rotation
On Sep 9, 2010, at 9:57 AM, Mark Martinec wrote: Rumor has is that some large players (such as Yahoo!) are disregarding such ephemeral property of a selector and are trying to associate a reputation scheme based on both the domain *and* the selector. That rumour is based on a presentation I gave in 2006 or so, while working at Yahoo!. Within hours, Dave Crocker had convinced me that tying reputation to the selector was a bad idea. Please help me quash the rumour, there's enough baseless FUD already. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
On Sep 2, 2010, at 11:54 AM, Hector Santos wrote: I think the issue is that we don't know what the assessors do Some of us have a pretty good idea. The people who design reputation systems don't do so in a vacuum; they're constantly reacting to spammers' latest tricks. If massive unauthorized replaying of unmodified DKIM-signed messages ever becomes a real issue, they'll adjust accordingly. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
On Aug 30, 2010, at 11:36 PM, Daniel Black wrote: ANNEX A - MUA Considerations Is a draft about mailing lists the right place to make recommendations to MUA developers? Seems like those should probably be in a separate document. (This is not to say that I disagree with the recommendations themselves, of course.) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposed changes to MLM draft
On Aug 30, 2010, at 11:03 AM, Murray S. Kucherawy wrote: So can I please get some +1s/-1s on each of the following: (1) Split the document into three documents: A DKIM MLM BCP that discusses signing and verifying in the context of MLMs with no value-add items addressed, a DKIM MLM Informational that discusses possible value-add enhancements to MLMs in the DKIM world, and a non-WG BCP about mailing lists irrespective of DKIM (Dave’s proposal); (2) Tear out everything having to do with making author signatures survive list relaying, dropping all that text altogether, and instead pointing people at S/MIME or PGP (John’s proposal); (3) Something else (and specify what that might be). AND… If you support any of the above, please take a few minutes to include some pointers to what text you want changed/exported and in what way. Actual diffs would be ideal, but I’ll take point-form commentary as well. I was about to give a +1 on option 1, but then I started going through draft-ietf-dkim-mailinglists-02 and trying to figure out which sections would go into each of the new documents. I don't think they can; both the BCP and the Informational would be incomplete without each other, and even if we ignored that they'd still have to each say a lot of the same things about what DKIM is, what lists are, et cetera. Where that falls apart is that most of the current document is non-normative, and I'm leaning towards agreeing with the concept of a second document being normative. So then we could have a document based on the current draft which says, in effect, here are some ways MLMs break DKIM, and how to avoid them. One of the how to avoid them is to make the MLM fully DKIM-compliant, as described in the new normative document. So it's still a split, but a different split. If you advocate for a general MLM BCP, this will be a non-WG document (it’s outside of our charter) so I’d love to get some MLM operators and developers involved. (Maybe this should take place on ietf-822 or maybe on a new non-WG list; suggestions welcome.) Expressions of interest in that work would be appreciated. I’ll approach the APPS ADs about a venue. I'll probably participate if it happens, but this feels very likely to get a lot of scope creep from people (perhaps including myself) saying I wish my MLM had this new feature ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Mailing lists and s/mime dkim signatures - mua considerations
On Aug 24, 2010, at 1:07 PM, MH Michael Hammer (5304) wrote: -Original Message- From: Rolf E. Sonneveld [mailto:r.e.sonnev...@sonnection.nl] [ . . . ] We should not change the essentials of DKIM for sake of MLM transparancy; the best we can do is document the status quo of the combination of DKIM and MLMs, its problems and (within the boundaries of the DKIM spec) any hints that can solve or mitigate those problems. I absolutely agree with your last statement. +1 So what we SHOULD be arguing about (those of us interested in forward progress) is whether draft-ietf-dkim-mailinglists-02 meets the documentation goal Rolf described above. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Mailing list reality check
On Aug 4, 2010, at 9:51 AM, John Levine wrote: I'd like to back up a minute and try to understand better what (if any) problem we're trying to solve here. So here is a straw poll. Assuming you do any sorting of inbound mail at all, how do you treat mail from lists to which you have subscribed? A) Use the From: address (or something that identifies the contributor) as the primary sort criterion B) Use the List-ID: (or something that identifies the list) as the primiary sort criterion C) Something else It is my impression that everyone does B, but maybe I'm wrong. B when I can, or occasionally whatever's in procmail's venerable ^TO macro. However, when talking to average user types, they'll most often: 1. wish they knew how to filter 2. /visually/ filter based on subject tags 3. sort alphabetically by subject 4. create MUA filters based on subject 5. create MUA filters based on To/Cc Perhaps if the List-Id header were visible, they'd consider using that instead. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] On changing From: when sending through lists
On Aug 1, 2010, at 3:43 PM, Murray S. Kucherawy wrote: This makes at least the third time this has been suggested by someone. I believe (though I'm willing to be corrected) that the draft should therefore cover this possibility and either advocate it or explain why it's a bad idea. The latter is acceptable; the material is on-topic, and we're trying to relay implementation advice and experience here, so it can be a cookbook of what to do as well as what not to do. Comments? And if you agree, your rationales in either direction? (I'll take Daniel's text at that link into account.) Weighing in a bit late...I think this approach should be included in the document. It's an entirely reasonable approach with some existing implementations, and it may not be as surprising to end users as it is to those of us who read raw email headers daily before breakfast. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
On Jul 29, 2010, at 5:09 PM, Ian Eiloart wrote: --On 26 July 2010 18:24:34 +0200 J.D. Falk jdfalk-li...@cybernothing.org wrote: I think it's because, when you implement most protocols, if your end is broken then you can't even talk to the other end. With ADSP, if your end is broken then you can still talk SMTP and even sign with DKIM, but the other end may silently discard your message. There's no feedback. About 90% of the email sent to my personal email address ends up in a Gmail junk mail folder, that I never check. There's no feedback there, either. As far as SMTP is concerned, that mail was successfully delivered. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
On Jul 26, 2010, at 9:13 PM, Douglas Otis wrote: A vouching service is unlikely to offer a fix either. How would a vouching service know better than the Author Domain? They wouldn't, so a smart vouching service would be working WITH the author domain to get it right. But that's a business decision, not a protocol decision. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
On Jul 27, 2010, at 10:33 AM, Douglas Otis wrote: Companies are good at shooting themselves in the foot in respect to helping bad actors phish. (blush) The other foot injury involves their email being rejected or discarded. Unfortunately, these two goals are in conflict when making ADSP assertions. Unless the targeted organizations or institutions forgo all informal third-party services, such as mailing-lists, it is not possible to get ADSP right. Ironically, following recommendations being proposed for mailing-lists is likely to make phishing worse. Mailing lists are a separate issue. I don't think it's helpful for a 3rd party to vouch that lists are lists, and that's not what John's draft does. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
On Jul 25, 2010, at 11:36 AM, Murray S. Kucherawy wrote: I've engaged some of you off-list trying to understand why ADSP is fundamentally different than the private agreements known to exist between PayPal and some large email service providers. I get the philosophical arguments, but from a standards body perspective I remain stymied. I'm finally beginning to buy that something akin to DBR may be necessary, but it's still weird to me that the point is that the average sysadmin can't be trusted to do ADSP right. But then why, for example, can he/she be trusted to do DNS or SMTP or even TCP/IP right without some sort of vouching or reference service asserting competence? The whole point of standards is to publish a mechanism for accomplishing something so that two parties that have never interacted in that specific way before can do so without some kind of out-of-band prior arrangement. In that sense these statements about ADSP create some cognitive dissonance that I haven't been able to resolve yet. I think it's because, when you implement most protocols, if your end is broken then you can't even talk to the other end. With ADSP, if your end is broken then you can still talk SMTP and even sign with DKIM, but the other end may silently discard your message. There's no feedback. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] open-source IP Address reputation-building engine?
On Jul 14, 2010, at 10:34 AM, Dave CROCKER wrote: Does anyone know of an open-source module that is used to develop a reputation table by watching traffic and correlating spamminess with the original IP Address? All of the reputation systems I'm aware of are custom. The MAAWG paper on reputation gives a fairly good overview of what the parts are, though. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Call for agenda items
On Jul 9, 2010, at 10:56 AM, Barry Leiba wrote: I'd also like a sort of show of hands to let me know who's going to be attending in person, and who will participate remotely, using the audio stream or jabber. I'll be there in person. 8. Any other business. I haven't actually started on a draft yet, but I and some co-workers and colleagues have been thinking a lot about a standard for per-domain DKIM statistics reporting -- aggregate statistics for both successes and failures, without the message content attached. This would obviously build on Murray's DKIM reporting extensions in the MARF WG, but since it's in aggregate it probably wouldn't fit in that WG anymore. Would it fit here? Also: have we beaten the recent ADSP arguments into the ground, or is there something we could accomplish in person that we didn't on the list? -- J.D. Falk jdf...@returnpath.net Return Path Inc ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
On Jun 21, 2010, at 1:00 PM, John R. Levine wrote: As threatened, here's an I-D that says how one would publish a list of domains for which it makes sense to discard unsigned mail. Looks like a good start, and almost shockingly simple. Any MTA/MFA support yet? *grin* -- J.D. Falk jdf...@returnpath.net Return Path Inc ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
On Jun 22, 2010, at 11:28 AM, Michael Thomas wrote: On 06/22/2010 09:46 AM, J.D. Falk wrote: On Jun 21, 2010, at 1:00 PM, John R. Levine wrote: As threatened, here's an I-D that says how one would publish a list of domains for which it makes sense to discard unsigned mail. Looks like a good start, and almost shockingly simple. Any MTA/MFA support yet? *grin* I still don't get why it's ok for John Levine to publish a list which says that it's ok to discard unsigned mail from paypal.com, but st00pid for paypal.com to publish the same thing. That is the essence of his jihad against adsp. Because presumably verifiers will trust John's process for compiling this list more than they'd trust any random schmoe with the ability to create TXT records. (If paypal were representative of all domains, this wouldn't be a concern.) Personally, I think we'll need lists like this for a while in order to gain more experience and determine best practices, and THEN we can decide whether to change (or even scrap) ADSP to reflect those practices. -- J.D. Falk jdf...@returnpath.net Return Path Inc ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] ADSP experience (wasn't Re: Lists BCP draft available)
On Jun 14, 2010, at 8:07 AM, John R. Levine wrote: The sooner we stop wasting time trying to fix ADSP and start getting shared drop lists, the sooner there's some hope of using DKIM to keep simple forgeries out of peoples' inboxes. I'm aware of a handful of beta-ish commercial products which intend to fill that niche. (Full disclosure: my employer developed one of these, contact me off-list if you'd like to know more.) Speaking as an IETF participant: the experiences of the larger email operations community in choosing, implementing, and troubleshooting these products could be very useful in determining what (if anything) needs to be changed in ADSP. Until then, we keep going in circles -- J.D. Falk jdf...@returnpath.net Return Path Inc ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP, was Lists BCP draft available
On Jun 7, 2010, at 11:52 AM, Brett McDowell wrote: But I've seen several posts to this list suggesting life is better if such messages simply never reach the subscribers' inbox. To be honest, I don't recall the motivation for that position. There've been a couple of studies where users were discovered to be going into their spam folder, and falling for bank phishing messages there. -- J.D. Falk jdf...@returnpath.net Return Path Inc ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] ADSP intent vs. usage (was Re: list vs contributor signatures, was Wrong Discussion)
On Jun 2, 2010, at 1:26 PM, John R. Levine wrote: Recent experience suggests that they often don't. Can you name someone with ADSP experience who doesn't understand what it means? Not to pick on you specifically, since there are multiple examples, but I'd say that domains that publish dkim=discardable and who let their users subscribe and send messages to mailing lists don't understand what their ADSP is telling people. Perhaps another way to put it is that they're not using ADSP discardable in the way that ADSP's designers intended. This appears to present two options, both of which have been attempted in this thread: 1. assume that the domain owner is wrong 2. assume that the ADSP design is wrong I think there's also a third option, which I haven't seen explored in depth yet (though I may have missed it): 3. find out why the domain owner thought that their implementation would be okay -- J.D. Falk jdf...@returnpath.net Return Path Inc ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP and Discardable (was Re: Lists BCP draft review)
On Jun 2, 2010, at 10:55 AM, John R. Levine wrote: My guess is that the phrase the domain encourages the recipient(s) to discard it is intended to refer to a silent discard. I don't think any of us expected the recipient to send a notification. I certainly didn't, since the assumption would be that the message was probably from a hostile sender. +1 Also, there's documented precedent within the IETF. RFC 863 has a clear definition: A discard service simply throws away any data it receives. RFC 5321 (and 2821, and 821) applied that definition to email, with specifics for programmers: 2.3.6. Buffer and State Table SMTP sessions are stateful, with both parties carefully maintaining a common view of the current state. In this document, we model this state by a virtual buffer and a state table on the server that may be used by the client to, for example, clear the buffer or reset the state table, causing the information in the buffer to be discarded and the state to be returned to some previous state. 5321 uses discard or discarded in other places, too. -- J.D. Falk jdf...@returnpath.net Return Path Inc ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] the danger of ADSP, was list vs contributor
On Jun 2, 2010, at 4:08 PM, Dave CROCKER wrote: On 6/2/2010 2:58 PM, Murray S. Kucherawy wrote: If we all agree that that's a valid characterization of ADSP, I suggest we move to get it downgraded from Proposed Standard to Experimental. I don't recall seeing anything that looks like we all agree on such a point. That some do is fine,but we also know that many do not. Count me as not agreeing. We always knew ADSP discardable wasn't appropriate for domains with users who send messages to mailing lists, and is equally inappropriate for all sorts of other legitimate uses of email. It's possible that the draft doesn't contain a strong enough warning that discardable = mail could be discarded, but that doesn't mean the whole thing is entirely broken. I'd really like to hear from a domain owner who published a discardable policy even though they knew they had users who send messages to mailing lists. I'd like to know why they thought it was okay. Then, we'll know. -- J.D. Falk jdf...@returnpath.net Return Path Inc ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] more on discardable, was Lists BCP draft
On May 24, 2010, at 7:55 PM, Steve Atkins wrote: On May 24, 2010, at 6:38 PM, John Levine wrote: Refusing signups from those domains is probably a bit extreme, though. What about a warning at signup time if a discardable ADSP record is found for the registrant's domain? That doesn't help. In the IETF's scenario, domain A sent mail which was marked discardable to the list, and recipients at domain B were rejecting it and the people at B got bounced off the list. I'd have to squint awfully hard to come up with an argument that it is wrong to reject unsigned discardable mail at SMTP time. I think that Murray was suggesting that in addition to rejecting all mail from domain A it would be polite to also warn anyone from domain A who subscribes to the list that their mail would be rejected (which seems good UX design to me). Yup, I think this would be an appropriate addition to the BCP document. -- J.D. Falk jdf...@returnpath.net Return Path Inc ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Charter update
On May 20, 2010, at 4:36 AM, Stephen Farrell wrote: Could we plan a regular meeting in Maastricht? Seems appropriate given the big interest in a DKIM And MLMs document. Sure. Assuming there's sufficient interest. Please let Barry and I know (or the list, whatever) what you think is better. Count me as interested in a WG meeting in Maastricht, and I expect to have time available to edit/review/participate/etc between then and Beijing (which I probably won't be able to attend.) -- J.D. Falk jdf...@returnpath.net Return Path Inc ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists BCP draft available
On May 17, 2010, at 11:08 PM, John Levine wrote: I like Murray's draft, and I hope that we can resist the urge to add vast amounts of non-productive complication to it. +1 Likewise, I hope that we can resist the urge to re-argue all the old arguments about ADSP. This BCP won't fix those issues, but it might clarify 'em somewhat. -- J.D. Falk jdf...@returnpath.net Return Path Inc ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists BCP draft available
On May 10, 2010, at 4:24 PM, Steve Atkins wrote: What's described there as an authoring mailing list manager isn't really what I think of as a mailing list, and there's not that much to say about it compared with the other sorts discussed. If it simplified things it could be dropped without affecting the rest of the document, I think. I think it should stay, primarily as a way to prevent confusion from people who think the authoring/one-way-blast MLM is the only important use of email. (I'm sure you know some people like that) -- J.D. Falk jdf...@returnpath.net Return Path Inc ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists BCP draft available
On May 10, 2010, at 2:43 PM, Franck Martin wrote: This looks good. Ok to become a WG document +1 Pity we may need a separate document for forwarding or can this notion be included in the current document? It's complex enough with all the different ways that MLM-style remailing can be implemented. Single-address forwarding is clearly related to /some/ of those methods, but not all, so I think confusion would be even more certain if we included that too. Also can parts be more normative than informational? ie what a MLM MUST do when supporting DKIM. That brings up the strange question of what supporting DKIM is. I think we could write normative language for what MLM software MUST NOT do if it wants to pass DKIM-signed messages through unscathed. We could also write normative language for what MLM software MUST do if it wants to sign the messages itself (that's pretty obvious.) But it's all the places in between that get complicated -- particularly when MLM developers are (in my experience) notoriously slow to add features. -- J.D. Falk jdf...@returnpath.net Return Path Inc ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On May 5, 2010, at 8:44 AM, Alessandro Vesely wrote: Ian Eiloart wrote: --On 30 April 2010 15:33:51 -0600 McDowell, Brett bmcdow...@paypal.com wrote: Talking about the status quo is to talk about how every ISP/MBP (btw, is it common practice to refer to a mailbox provider as a MBP?) I tend to use ESP - Email Service Provider. I used to use ESP, but it may be confused with email marketing services. ISP may mean network provider. Mailbox provider is the less ambiguous term, IMHO. +1 -- J.D. Falk jdf...@returnpath.net Return Path Inc ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] ADSP discardable discussion lists (was Re: Wrong Discussion - was Why mailing lists should strip DKIM signatures)
On Apr 30, 2010, at 3:10 PM, Steve Atkins wrote: If a mailing list were to simply reject all submissions from senders who are publishing ADSP discardable that would ensure that their wishes were not violated. And it seems to comply with the spirit of ADSP discardable more than the riskier suggestions. I believe that is the exact consensus conclusion we came to when discussing ADSP discardable the first time. -- J.D. Falk jdf...@returnpath.net Return Path Inc ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Wrong Discussion - was Why mailing lists should strip DKIM signatures
On Apr 26, 2010, at 8:05 AM, MH Michael Hammer (5304) wrote: I think we are having the wrong discussion. The real question is: What are appropriate practices for mailing lists in handling DKIM signed mail? By focusing on John and his single example we are looking at a tree and not the forest. This may not be the best way to extrapolate recommended best practices. Agreed. Absolutely. Another real question, equally important: who is actually writing this BCP? -- J.D. Falk jdf...@returnpath.net Return Path Inc ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Collecting statistics
On Mar 25, 2010, at 3:41 PM, Franck Martin wrote: May be stupid question: Would these stats help to build a reputation on the domain? These particular statistics would be far less interesting to a reputation system than the recipients' perspective of the mail they're receiving -- same as with IP reputation. (Which pushes it even further out of scope, I believe.) -- J.D. Falk jdf...@returnpath.net Return Path Inc ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposed new charter
On Mar 12, 2010, at 10:39 AM, Barry Leiba wrote: So, as Eliot asks: Do we really have people with time and inclination to push these through? Are these dates reasonable, or should some be pushed out a bit? In any case, who will work on which items? Fairly certain I can provide some relevant aggregated data within that timeframe, and participate in the discussions. Not sure if I'll have the time to lead any of the proposed efforts. -- J.D. Falk jdf...@returnpath.net Return Path Inc ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposed new charter
+1 on the charter. As for milestones On Feb 23, 2010, at 2:36 PM, Murray S. Kucherawy wrote: 1. Advance the base DKIM protocol (RFC 4871) to Draft Standard. This is the first priority for the working group. Unfortunately I don't have any background doing this kind of work, so I'm forced to guess. But what about the July IETF as a done-by date? Is that a crazy idea? Same here, but let's try. 2. Collect data on the deployment, interoperability, and effectiveness of the base DKIM protocol, with consideration toward updating the working group's informational documents. July IETF. Perhaps: 2a. Develop a plan to collect data, to discuss at July IETF. (This plan may include advancing the DKIM reporting drafts.) 2b. Enact plan immediately after July IETF. 2c. Collect lots of data. 2d. Report on results periodically, with final report due by November IETF. 3. Collect data on the deployment, interoperability, and effectiveness of the Author Domain Signing Practices protocol (RFC 5617), and determine if/when it's ready to advance on the standards track. Update it at Proposed Standard, advance it to Draft Standard, deprecate it, or determine another disposition, as appropriate. November IETF. Possible the same three steps, but agreed that it'll mostly happen after July. 4. Taking into account the data collected in (2) and (3), update the overview and deployment/operations documents. These are considered living documents, and should be updated periodically, as we have more real-world experience. February 2011 IETF. +1 5. Consider issues related to mailing lists, beyond what is already documented. This includes considerations for mailing list software that supports or intends to support DKIM, as well as considerations for DKIM/ADSP deployment in the presence of mailing lists that do not have such support. Include recommendations in the informational documents, or produce a new informational document about mailing-list considerations. I think this can be done in parallel, so November IETF. +1 -- J.D. Falk jdf...@returnpath.net Return Path Inc ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Collecting re-chartering questions
YES to 1,3*,5,7,8* NO to 2,4,6*,9,10, and anything about patents 3. Other 3rd-party signing issues (New protocol? Info doc?) Yes to an info doc collecting discussing challenges so that any discussion of a new protocol is based on real-world data rather than wild speculation. #6 has the same requirement. 8. Collect data on deployment and effectiveness of ADSP, and consider future of ADSP Yes to collecting data on deployment, but it's far too early to draw any conclusions about effectiveness. Also, FWIW: yes to meeting in Anaheim. -- J.D. Falk jdf...@returnpath.net Return Path Inc ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] domains with ADSP
J.D. Falk wrote: Franck Martin wrote: Can anyone can point me to one or two domains with published adsp records? My personal domain, cybernothing.org, is surely one of the very few domains to publish ADSP and also participate heavily in discussion lists like this one. _adsp_._domainkey.cybernothing.org text = dkim=all I haven't encountered a single problem with that configuration. ...except my typo (doh!) Fixed now, and I'll let you know how it goes. -- J.D. Falk Return Path Inc http://www.returnpath.net/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] domains with ADSP
Franck Martin wrote: Can anyone can point me to one or two domains with published adsp records? My personal domain, cybernothing.org, is surely one of the very few domains to publish ADSP and also participate heavily in discussion lists like this one. _adsp_._domainkey.cybernothing.org text = dkim=all I haven't encountered a single problem with that configuration. The handful of small Mailman lists I host on this server get a DKIM signature on the way out, no problems there either. (This is purely anecdotal, not intended to replace serious testing by serious people.) -- J.D. Falk Return Path Inc http://www.returnpath.net/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Issue: Deployment Guide Section 6.1/6.5 (ADSP/Forwader) conflict
Ian Eiloart wrote: That seems sensible to me. So lists should not forward email that they're about to render 'discardable' by breaking the signature. Instead, they should reject (5xx) or bounce (DSN) the message. Presumably, a bank wants to know if it has a bad email address for a customer. Yep. Of course, if you aren't going to break the signature, or are rewriting the From: address, then it's OK to forward the email. Probably. Oh, and if the list sees incoming mail already has a broken signature, or none at all, then it should be discarded by the list software (or its MTA). Yep. The treatment of email with authors in a domain with 'dkim=discardable' policy seems absolutely straightforward. What's more complicated is the treatment of email with authors in a domain with 'dkim=all' policy. There's no guidance about handling such mail. Agreed; we need more operational experience here. -- J.D. Falk Return Path Inc http://www.returnpath.net/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] brand protection, was Is anyone using ADSP?
Ian Eiloart wrote: As an admin, I'd like to be able to reject mail for lacking a DKIM signature. Without a supporting ADSP, I risk the ire of my users. With a supporting ADSP, I can point the finger at the publisher of the policy. That's (more or less) the exact receive-side use case we were discussing when developing ADSP. -- J.D. Falk Return Path Inc http://www.returnpath.net/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Issue: Deployment Guide Section 6.1/6.5 (ADSP/Forwader) conflict
Charles Lindsey wrote: All of them are a proper subject of discussion, should this WG decide to embark on such a BCP (and the misunderstandings repeatedly displayed here seem to suggest that something of the sort is needed). Agreed, except for one thing: until there's a larger set of users of ADSP, no practice can be said to be common. A considerations for use document might help, though I'm not sure what it could say that the RFC doesn't already cover. -- J.D. Falk Return Path Inc http://www.returnpath.net/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Is anyone using ADSP? - bit more data from the receiving side
Murray S. Kucherawy wrote: Oh, I can list a pretty large number of mail-related RFCs, some of them standards track, that are not universally implemented and the world hasn't blown up yet. Maybe the world will only blow up after we argue about this for another few years? -- J.D. Falk Return Path Inc http://www.returnpath.net/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Resigner Support of RFC 5617 (ADSP)
hector wrote: IMTO, before any automated concept can work well, the supportive DKIM network must expect protocol consistency to be established among all DKIM nodes. Why are we arguing about it now, then? It'll be years until we reach that point. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] The mystery of third party signatures
Barry Leiba wrote: I'm not in favour of complicating the protocol, when we can do what we want to do with what's there. I'd really need to see significant new use cases to drive any major change here. +1 On the other hand, I'd see nothing wrong if someone should want to write a draft about mailing-list considerations, and propose it as a working group item. But I'd want to see it as a draft that we can review, not just as a few ideas in an email message. +1 Whoever wants to take on this project should feel free to borrow from the article I wrote in June: http://www.circleid.com/posts/dkim_for_discussion_lists/ -- J.D. Falk Return Path Inc http://www.returnpath.net/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM charter update proposal
Steve Atkins wrote: A more interesting question is how domain based authentication helps domain reputation based systems reduce false positives in spam filters, or how domain based feedback loops help ISPs and mailers avoid sending unwanted email. DKIM itself doesn't do either of those, it's just a platform they're based on. I don't think we're at a point, yet, where the answer to that will be particularly enlightening. It may be time to start tracking the data if you're not already, though. Similarly, I don't think we're at a point where any discussion of standardizing domain reputation systems -- any more than we're at a point of standardizing IP reputation systems. There's a lot more experimentation that needs to happen (and is happening) before anything could be considered standard enough for an IETF document. I'd expect to see (and may offer) competing considerations for... drafts before there's anything close to a BCP. So, where does that leave the DKIM WG? I think it leaves us exactly where we were before: reputation assessment is, and should be, out of scope. -- J.D. Falk Return Path Inc http://www.returnpath.net/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM charter update proposal
Franck Martin wrote: Seems to me something is missing: gather data to establish if DKIM specifications have in any way alleviated any misuse of the email system, in particular but not limited to spam, phishing attacks and fraud. What would that prove, or disprove? -- J.D. Falk Return Path Inc http://www.returnpath.net/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM charter update proposal
Barry Leiba wrote: Please comment on it. If you like it, please say so. I like it. -- J.D. Falk Return Path Inc http://www.returnpath.net/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM adoption
Murray S. Kucherawy wrote: In fact, there is an experimental DKIM reputation service out there now that does something of this nature. The implementation I wrote has optional support for it. I don't yet have any information about who's using it or what the results of such are. And, there are others in progress. -- J.D. Falk Return Path Inc http://www.returnpath.net/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM adoption
Franck Martin wrote: Looking at DKIM adoption. I have seen statements that some mailers will do DKIM based reputation if available, but I have yet to see a statement as either: -an email not signed with DKIM will have its reputation lowered (less likely to pass filters) -an email signed with DKIM will have its reputation increased (more likely to pass filters) I think if there were some postmasters making such statement it would boost the adoption of DKIM. Yahoo! broadly hinted, some years ago, that they'd start giving a slight positive bump to messages signed with DomainKeys. Two things happened: 1. serious hardcore spammers (not just misguided marketers) started including DomainKeys signatures 2. lots of people who really should've known better started saying use DomainKeys and your deliverability will improve! We also wrote about the slow emergence of domain reputation recently, trying to avoid piling on to the hyperbolic misrepresentations so common on other email marketing blogs: http://www.returnpath.net/blog/2009/07/domain-reputation-what-it-mean.php -- J.D. Falk Return Path Inc http://www.returnpath.net/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] remote participation info
I'll be waking up early in Denver since I can't join y'all in Stockholm, so I've collected remote participation links from a handful of different tools pages. Please let me know if I've missed anything here: agenda: http://tools.ietf.org/wg/dkim/agenda?item=agenda75.html chair slides: http://www3.ietf.org/proceedings/75/slides/dkim-0.pdf other docs: http://tools.ietf.org/agenda/75/docs/dkim.tar.gz audio: http://feed.verilan.com/ietf/stream06.m3u jabber: xmpp:d...@jabber.ietf.org?join jabber logs: http://jabber.ietf.org/logs/dkim -- J.D. Falk Return Path Inc http://www.returnpath.net/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] General Feedback loop using DKIM
Franck Martin wrote: I'm worried that sending an email when the signature fails could be triggered by forged emails rather than by emails that contains dkim errors. DKIM being clearly defined, a DKIM signed email should be correct/wrong regardless of the destination. Easy to test the DKIM signature pass on a couple of DKIM reflectors. Therefore reports due to a failed signature would indicate only forged emails. I'm not sure what information a sender gains by knowing someone is forging its signature? Financial institutions tend to be very interested in finding out when their domain is used in phishing attempts, or similar forgeries. However, that's the only type of feedback you've mentioned which is related to DKIM. I'm not sure it makes sense to tie the rest to a DKIM key record. -- J.D. Falk Return Path Inc http://www.returnpath.net/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list expanders (was Re: chained signatures, was l= summary)
hector wrote: Whats odd about all this is that it perpetuates the key differences in understanding the purpose of DKIM. If its for a domain to assert a responsibility for the message, then based on these discussions it is only up to a point or the next hop where that responsibility is downgraded or rescinded. As the next hop, be it a relay or list server, could take over the responsibility, the chain of trust is presumed here. Hop to Hop, Point to Point, relay to relay, finally the the MDA and the user. This is an fundamental idea that allowed internet email and the delivery system to work, but there was never a presumption that middle ware will be altering the originality of the mail. Passthru mail was fundamentally sacred and this was covered by US laws to be frank. It's been challenged over the years, but there is still a taboo to mess around with it. List Servers were the exception for the most part and that was covering tagging the subject, adding footers or some HTML framing, etc, all making it much harder for new mail integrity technology. Very good point; thanks for discerning the difference. At its core, I think, this is the all-too-common battle between the Platonic Ideal of Email and the reality. In this reality, intermediaries change messages. Sounds like a few folks on this list don't want messages to undergo drastic changes when passing through intermediaries, and thus are arguing against any attempt to use DKIM to legitimize what they view, Quixotically, as illegitimate behavior. But DKIM /will/ be applied in situations where intermediaries change messages, because that is a reality of email today. I'd agree that it's necessary to tilt at a few windmills from time to time as a reminder of what the collective ideals might once have been, but this particular windmill was rebuilt as a pea soup restaurant decades ago. -- J.D. Falk Return Path Inc http://www.returnpath.net/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Modified Introduction text for rfc4871-errata
Wietse Venema wrote: +0.99 This clarifies what is the primary identifier that signers intend to send to assessors. If it helps to avoid stepping on sensitive toes, you could drop the last sentence, but I can live with it. +1 (rounding up) And, by the way, I'm speaking as operator of a popular reputation assessment service. -- J.D. Falk Return Path Inc http://www.returnpath.net/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list expanders (was Re: chained signatures, was l= summary)
Michael Thomas wrote: There is *NO* *REASON* to strip signatures. NONE. In fact it is HARMFUL. You are clearly *VERY* *PASSIONATE* about this, but would you care to share the logic you used to come to this conclusion? -- J.D. Falk Return Path Inc http://www.returnpath.net/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] list expanders (was Re: chained signatures, was l= summary)
Charles Lindsey wrote: What I think it makes clear that we are in serious need of some document to provide Best Practice for how mailing list expanders should handle DKIM, and I think that is something that this WG needs to take on board. Feel free to use my article on CircleID as a starting point: http://www.circleid.com/posts/dkim_for_discussion_lists/ It's so simple and obvious (once you move from theory to practice) that I'm not sure if it's worth the WG's time. -- J.D. Falk Return Path Inc http://www.returnpath.net/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type
Wietse Venema wrote: Siegel, Ellen: Eliot Lear wrote: The basic question is simply this: is it sufficient to list the key algorithm in the header? I don't see a plausible attack, so I'm okay +1 +1 with that. But let's at least have the debate based on facts. yup. +1 +1 Enlightened by the facts, +1 +1 again, in case the facts overrode my previous. -- J.D. Falk Return Path Inc http://www.returnpath.net/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Urgent: draft-ietf-dkim-ssp-10 and RFC 5451
Murray S. Kucherawy wrote: On Thu, 28 May 2009, Barry Leiba wrote: 3. A few Yes, adding this is groovy, messages would be good and all. Yes, adding this is way groovy. +1 -- J.D. Falk Return Path Inc http://www.returnpath.net/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
