Re: [ietf-dkim] marketing dkim
Daniel, DKIM signing clearly defines who takes responsibility for signing an email ADSP is only useful if it is implemented by draconian senders like financial emailers who really really want all malformed dkim signatures to be dropped regardless of consequences There is NO filtering usefulness using DKIM as it is not reputation based. It does give one the ability to slow down spoofing. If the signature matches then indeed the sending ISP did in fact send it Now why would anyone make time to evangelize against a protocol at a conference is beyond me unless it was SPF :-) thanks, Bill On Aug 18, 2010, at 9:59 PM, Daniel Black wrote: I've got a presentation slot for DKIM at APNIC next week to a bunch of ISPs. My current plan for a talk is: * DKIM is a really well developed standard for signing email * Combined with ADSP=discardable it can filter email at ISP gateways without too much fear of unduely lost email * BUT otherwise its useless in its current state. As a consultant this isn't going to get me lots of work but as an engineer sticking to ethics it more important. My rational is what cost / benefit can I give to a domain that wants to sign: Costs: * Product deployment and DKIM training and documentation for staff * Trying to work out why some outbound streams of email get lost (when there is no IETF guidance for the receiver) * Fixing/changing mailstreams by destination (draft-ietf-dkim-mailinglists-02 4.1) Benefits: * A recipient may through good design manage to pass good signatures and drop bad signatues while allowing mailing list mail through. Given likelyhood of benefits are signficantly lower that costs I'm not seeing a benefit for a signer. Cost/benefit to verifier: Costs: * software deployment training and documentation * increases concurrancy of email processing waiting for DKIM keys OR post processing where rejection could result in backscatter. * implement some filtering scheme based on RFC5863 Benefits: * rejecting ADSP=discardable messages with missing or broken signatures * Adding AR headers (that a user or their MUA may never work out how to use effectively) Again, the likelyhood of benefits are signficantly is lower than costs. So DKIM is at a state where there is no offering of filtering advice beyond the theoretical discussion in RFC5863. The current mailing list approach: MLM behaviors are well-established and standards compliant. Thus, the best approach is to provide these best practices to all parties involved, imposing the minimum requirements possible to MLMs themselves. is rather defeatist and limits the encouragement for DKIM-Friendly lists. So for DKIM, filtering is painful as it requires end user specific knowledge of what lists they subscribed to. This is hard enough at small end user organisation let alone an ISP. The end user is left with an AR header field, invisibly hidden by the MUA, to try to filtering out forged mail. For reputation service providers the assumption that mail serivce providers are going to deploy DKIM for the benefit of reputation service providers seems a little hopeful considering their costs. Don't misunderstand me, domain reputation has a role in spam reduction and DKIM contributes to this, there just needs to be more benefit to the sender/receiver without it. At the end of the day the future I currently see for DKIM is the same as SPF. Some will deploy it but at the end of the day there will be no-one filtering on its results because of its deficiencies (MLM). The progress of deployment will stagnate in the same way as spf because there is no filtering: (compare http://web.archive.org/web/20080130150257/http://spf-all.com/ and http://spf-all.com) The solutions (and acknowledged limitations) that may enable an intertial mass of dkim are in many of the following: * DKIM-Friendly lists (realising change can be slow based no number and incompatible behaviour is driven by MUA) * MLM that add a dkim signature in a predicatable way (draft-ietf-dkim- mailinglists-02 4.7) - realizing change is slow for the number of MLM * MUA that describe verification clearly realising design requires effort * TPA-Labels realising intergration beween users and DNS needs to occur in the sender ADMD * ADSP=discardable for non-MLM participating domains * ADSP=all for those that really do sign all mail * Third party signature having meaning on MLM domains though this needs to be whitelisting approach is needed on the verifier/receiver ADMD to prevent a phishing/spam loophole. * LDSP for third party signatures Please tell me where I'm wrong. I don't see nice thing to say to these regional ISPs except that DKIM is useless until a clearer policy framework for filtering is available to everyone. ___ NOTE WELL: This list operates according to
Re: [ietf-dkim] marketing dkim
* DKIM is a really well developed standard for signing email Right, but emphasize that the granularity is a signing domain -- it is not and cannot be a way to attribute mail to individual people. * Combined with ADSP=discardable it can filter email at ISP gateways without too much fear of unduely lost email * BUT otherwise its useless in its current state. I wouldn't say that. It's quite useful as is to recognize signed mail from people you know. Paypal is the obvious example, their legit volume is high enough to most places that it's worth whitelisting their signed mail, which then lets you crank up the phish filters to catch the unsigned fakes. Be sure to tell them that ADSP is not useful, according to one of the authors of the ADSP RFC. Rather than fooling around with with the near zero S/N ratio of ADSP, whitelist people you know, perhaps put in a few special cases to drop unsigned mail from phish targets like Paypal and Amazon who sign all their mail. (Amazon still signs with DK, but most filters can deal with that.) If you're an ISP, signing your own mail is of limited value unless you exchange a lot of mail with Yahoo and Google, which you probably do. In that case it helps them to recognize your mail stream, and in Yahoo's case send back FBL reports when people hit the spam button. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] marketing dkim
bill.ox...@cox.com wrote: Daniel, DKIM signing clearly defines who takes responsibility for signing an email Responsible for what? Can I get sued when something goes wrong? ADSP is only useful if it is implemented by draconian senders like financial emailers who really really want all malformed dkim signatures to be dropped regardless of consequences Draconian? Maybe they don't to get sued when the new signer ignorantly ignores policy and resigns the mail thus passing the responsibility buck. You know the You break, you own pottery principle. PAYPAL was pretty smart to put a official RFC sanctioned technological disclaimer out there. There is NO filtering usefulness using DKIM as it is not reputation based. It does give one the ability to slow down spoofing. If the signature matches then indeed the sending ISP did in fact send it But what if it didn't match? Do you continue sending potentially spoofed mail? Now why would anyone make time to evangelize against a protocol at a conference is beyond me unless it was SPF :-) Maybe because for so long everyone heard about how great DKIM is, with years of no real proof or payoff shown, and now the conference sponsors decided to add an opposing viewpoint or a viewpoint that might suggest where there might be a payoff with DKIM. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] marketing dkim
On 08/19/2010 10:23 AM, Stephen Farrell wrote: On 19/08/10 18:06, Michael Thomas wrote: On 08/19/2010 09:20 AM, John Levine wrote: Be sure to tell them that ADSP is not useful, according to one of the authors of the ADSP RFC. Chairs -- Can I ask for a revision of ADSP where John is stripped out of the document? You can ask. The answer is that we don't currently have a revision of ASDP on our charter and RFCs do not change. It's ridiculous that he presumes to speak for it, John was an editor of ADSP, which is a WG product. I think its a fine thing to do editing work even if you don't agree with the content. Well, I don't. Would you hire somebody to build a bridge that they think would be fine and dandy if it collapsed? I personally wouldn't then deride the WG output, but the RFC is what gets read, so I treat remarks like John's as the background noise that they are, but I do understand why some WG participants find it annoying. That's because you have scruples. and it was a huge mistake to give him this undue credibility. Especially when he has none. That last is out of order on a list such as this. Please desist. I'd say I'm sorry, but I'm not. You guys made a huge mistake, and John's continuing baseless jihad is a disservice to the community. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] marketing dkim
On Aug 18, 2010, at 6:59 PM, Daniel Black wrote: I've got a presentation slot for DKIM at APNIC next week to a bunch of ISPs. My current plan for a talk is: * DKIM is a really well developed standard for signing email It's not really for signing mail. It's for attaching a persistent non-IP based identifier to the mail. The signing is just an implementation detail. * Combined with ADSP=discardable it can filter email at ISP gateways without too much fear of unduely lost email I wouldn't claim that too strongly, as it's something that's likely to turn out to be false. * BUT otherwise its useless in its current state. That's not really so, for ISPs who are already doing mail filtering based on sender reputation. It provides an identifier to plug into their existing reputation engines that's a lot better than an IP address. As a consultant this isn't going to get me lots of work but as an engineer sticking to ethics it more important. My rational is what cost / benefit can I give to a domain that wants to sign: Costs: * Product deployment and DKIM training and documentation for staff Yup. Though in many cases that'll be just checking the use DKIM box on one configuration screen and deploying some DNS records. * Trying to work out why some outbound streams of email get lost (when there is no IETF guidance for the receiver) * Fixing/changing mailstreams by destination (draft-ietf-dkim-mailinglists-02 4.1) I don't believe either of those are actual costs if you're talking about DKIM. DKIM will not cause outbound streams of email to get lost, nor will you need to fix or change any mailstreams. I'm not sure why you think either is true - can you explain? Benefits: * A recipient may through good design manage to pass good signatures and drop bad signatues while allowing mailing list mail through. No smart recipient will either pass good signatures nor drop bad signatures. They'll ignore bad signatures and use good signatures as part of a reputation decisions. Given likelyhood of benefits are signficantly lower that costs I'm not seeing a benefit for a signer. Cost/benefit to verifier: Costs: * software deployment training and documentation * increases concurrancy of email processing waiting for DKIM keys OR post processing where rejection could result in backscatter. * implement some filtering scheme based on RFC5863 Benefits: * rejecting ADSP=discardable messages with missing or broken signatures That's a cost, more than a benefit. * Adding AR headers (that a user or their MUA may never work out how to use effectively) Yup. There's no sign that that'll be useful in the near future. Again, the likelyhood of benefits are signficantly is lower than costs. If they're spam filtering based on sender reputation then the dkim token is a much more reliable, and cheaper to maintain, token than peer IP address. It'll make their existing reputation-based filtering more effective, and reduce the maintenance overheads. It'll also make them ready for IPv6, where IP based reputation is going to get somewhat more difficult to manage. So DKIM is at a state where there is no offering of filtering advice beyond the theoretical discussion in RFC5863. The current mailing list approach: MLM behaviors are well-established and standards compliant. Thus, the best approach is to provide these best practices to all parties involved, imposing the minimum requirements possible to MLMs themselves. is rather defeatist and limits the encouragement for DKIM-Friendly lists. DKIM places no requirements on MLMs. So for DKIM, filtering is painful as it requires end user specific knowledge of what lists they subscribed to. This is hard enough at small end user organisation let alone an ISP. The end user is left with an AR header field, invisibly hidden by the MUA, to try to filtering out forged mail. For reputation service providers the assumption that mail serivce providers are going to deploy DKIM for the benefit of reputation service providers seems a little hopeful considering their costs. Don't misunderstand me, domain reputation has a role in spam reduction and DKIM contributes to this, there just needs to be more benefit to the sender/receiver without it. At the end of the day the future I currently see for DKIM is the same as SPF. Absolutely not. ADSP is much the same as SPF, and I agree with everything else you say, if you're talking about ADSP. But ADSP is not the same as DKIM. DKIM is a nice, solid way of attaching identifiers to mail, while ADSP is an SPF-esque bag on the side. Some will deploy it but at the end of the day there will be no-one filtering on its results because of its deficiencies (MLM). The progress of deployment will stagnate in the same way as spf because there is no filtering: (compare http://web.archive.org/web/20080130150257/http://spf-all.com/ and http://spf-all.com) The
Re: [ietf-dkim] marketing dkim
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Daniel Black Sent: Wednesday, August 18, 2010 7:00 PM To: ietf-dkim@mipassoc.org Subject: [ietf-dkim] marketing dkim I've got a presentation slot for DKIM at APNIC next week to a bunch of ISPs. My current plan for a talk is: * DKIM is a really well developed standard for signing email * Combined with ADSP=discardable it can filter email at ISP gateways without too much fear of unduely lost email * BUT otherwise its useless in its current state. That doesn't sound much like marketing to me... I would focus on the fact that it, in addition to being a mechanism to thwart forgeries, is a framework for providing things like domain reputation. It's an important layer enabling other very valuable things. Lots of enabling technologies are by themselves not especially useful, but that doesn't mean they aren't critical. So DKIM is at a state where there is no offering of filtering advice beyond the theoretical discussion in RFC5863. The current mailing list approach: MLM behaviors are well-established and standards compliant. Thus, the best approach is to provide these best practices to all parties involved, imposing the minimum requirements possible to MLMs themselves. is rather defeatist and limits the encouragement for DKIM-Friendly lists. Accepting the realities of a situation seems to be more practical than defeatist. The email world is loaded with software inertia. Working with that as a guideline is the best way to get something accomplished. If we're surprised by the absence of that inertia, things can only get better. For reputation service providers the assumption that mail serivce providers are going to deploy DKIM for the benefit of reputation service providers seems a little hopeful considering their costs. Don't misunderstand me, domain reputation has a role in spam reduction and DKIM contributes to this, there just needs to be more benefit to the sender/receiver without it. I read this as saying We need reputation for really effective filtering, which is completely true. I think a positive spin here would be much more likely to draw support; using words like useless without will do more to discourage your audience than encourage it. At the end of the day the future I currently see for DKIM is the same as SPF. Some will deploy it but at the end of the day there will be no-one filtering on its results because of its deficiencies (MLM). The progress of deployment will stagnate in the same way as spf because there is no filtering: (compare http://web.archive.org/web/20080130150257/http://spf-all.com/ and http://spf-all.com) Jeez, what's the intent here? Are you trying to get people excited about DKIM or convince them not to bother? Please tell me where I'm wrong. I don't see nice thing to say to these regional ISPs except that DKIM is useless until a clearer policy framework for filtering is available to everyone. If I, as someone excited about DKIM and what it can enable, were invited to speak someplace while this was my general disposition, I would politely decline to present anything at all. -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] marketing dkim
On 19/08/10 18:06, Michael Thomas wrote: On 08/19/2010 09:20 AM, John Levine wrote: Be sure to tell them that ADSP is not useful, according to one of the authors of the ADSP RFC. Chairs -- Can I ask for a revision of ADSP where John is stripped out of the document? You can ask. The answer is that we don't currently have a revision of ASDP on our charter and RFCs do not change. It's ridiculous that he presumes to speak for it, John was an editor of ADSP, which is a WG product. I think its a fine thing to do editing work even if you don't agree with the content. I personally wouldn't then deride the WG output, but the RFC is what gets read, so I treat remarks like John's as the background noise that they are, but I do understand why some WG participants find it annoying. and it was a huge mistake to give him this undue credibility. Especially when he has none. That last is out of order on a list such as this. Please desist. And everyone else: please don't take up this thread. Let's get the work we have on our plate done and not get sidetracked again. Generic praise or criticism of ADSP is currently out of scope. Stephen. (As chair) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] marketing dkim
On 8/19/2010 10:50 AM, Murray S. Kucherawy wrote: I would focus on the fact that it, in addition to being a mechanism to thwart forgeries, is a framework for providing things like domain reputation. Sorry, but you have these priorities and foci confused. dkim's primary use is the attachment of a verifiable label, to be used for assessment. The nature of the design of the mechanism makes its ability to be used for this purpose uncontroversial and very low risk. The risk, now, is all market preference, rather than functional. That is, there is no technical risk to DKIM's ability to satisfy this requirement. The extent to which the market finds it useful for that purpose is still being established. The extent to which dkim can also be used to protect against forgeries is, so far, completely theoretical AND controversial. We've debated this topic many times and I'm not trying to claim a certain outcome for that debate. Merely noting that it has credible people on both sides and no track record. Steve Atkins' summary and the Intro to 4871bis have the focus accurate, IMO. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] marketing dkim
On 08/19/2010 10:29 AM, J.D. Falk wrote: On Aug 18, 2010, at 6:59 PM, Daniel Black wrote: * BUT otherwise its useless in its current state. Useless for which purpose? From the rest of the message it sounds like you're primarily thinking about discussion-type mailing lists, which -- while a popular topic here recently -- are not the only kind of mail DKIM can be applied to. http://www.maawg.org/sites/maawg/files/news/MAAWG_Email_Authentication_Paper_2008-07.pdf is a very good overview of the theory and applicability of message sender authentication, though some of the terms may be a couple years out of date. I'd suggest starting there. If mailing lists were put out of business by DKIM/ADSP would anybody even notice? Or care? Mailing lists are from a bygone era, even if we are its fossilized remains. Mike, not that DKIM would be able to do that, of course ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] marketing dkim
On 8/19/10 9:59 AM, Steve Atkins wrote: If they're spam filtering based on sender reputation then the dkim token is a much more reliable, and cheaper to maintain, token than peer IP address. It'll make their existing reputation-based filtering more effective, and reduce the maintenance overheads. It'll also make them ready for IPv6, where IP based reputation is going to get somewhat more difficult to manage. IMHO, cryptographic authentication of the SMTP host is needed instead to immediately curtail any subsequent traffic. In addition, DKIM does not confirm where the domain sent the message, which makes using DKIM to negatively impact a domain for unsolicited email something easily poisoned. Perhaps we should put together an I-D that uses a DKIM key with SMTP Auth instead to be ready for IPv6. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] marketing dkim
Dan, In my view, just as the responses so far as shown, you are going to get a mix bag of opinions. What is particularly interesting is the how the definition of DKIM seems to keep changing. In any case, if it was me, what I would do is approach this from what has been deployed using various non-standard approaches, including proprietary which I lump together as DKIM-SSA (Special Signing Arrangements), with what are proposed standards. I would cite any stats, provide some theory with empirical observations. In short - INFORM. DKIM- RFC 4971 raw DKIM signing protocol My personal definition (don't use it. g) A free for all, message DNA stamping technology with an obscure responsibility clause allowing any MTA to absolve all previous single or collective responsibility. The main point here would be that it isn't quite useful with helper technology and you can site how its being used now and what are the standard proposals: Non-Standard Augmented technology: DKIM+SSA- DKIM + Special Signing Arrangements (i.e. YAHOO) DKIM+REP- DKIM + Reputation Scoring (SpamAssassin), Certification methods Proposed standard (IETF DKIM WG documents) Augmented technology: DKIM+ADSP - DKIM + Author Domain Signing Policy/Practices DKIM+MLM- DKIM + Mailing List Management Guidelines There might be some I-D proposals or non WG RFCs out there that are related to DKIM, so I would look for those as well. I personally would touch base with two employment aspects: DKIM-SENDER-POLICY (or AUTHOR POLICY) DKIM-RECEIVER-POLICY (or LOCAL POLICY) The two seem to be one basis for the conflicts here. But I would not discuss it from the conflicts POV, but how the two are being considered by different implementations. The DKIM-SENDER-POLICY is about what the AUTHOR DOMAIN is trying to get others to do about his mail, including filtering the unexpected. The DKIM-RECEIVER-POLICY is about what how the receiver is going to handle the verification and final disposition of DKIM signed mail. This has less regard for DKIM-SENDER-POLICY considerations (the conflict). Anyway, good luck. :) -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Daniel Black wrote: I've got a presentation slot for DKIM at APNIC next week to a bunch of ISPs. My current plan for a talk is: * DKIM is a really well developed standard for signing email * Combined with ADSP=discardable it can filter email at ISP gateways without too much fear of unduely lost email * BUT otherwise its useless in its current state. As a consultant this isn't going to get me lots of work but as an engineer sticking to ethics it more important. My rational is what cost / benefit can I give to a domain that wants to sign: Costs: * Product deployment and DKIM training and documentation for staff * Trying to work out why some outbound streams of email get lost (when there is no IETF guidance for the receiver) * Fixing/changing mailstreams by destination (draft-ietf-dkim-mailinglists-02 4.1) Benefits: * A recipient may through good design manage to pass good signatures and drop bad signatues while allowing mailing list mail through. Given likelyhood of benefits are signficantly lower that costs I'm not seeing a benefit for a signer. Cost/benefit to verifier: Costs: * software deployment training and documentation * increases concurrancy of email processing waiting for DKIM keys OR post processing where rejection could result in backscatter. * implement some filtering scheme based on RFC5863 Benefits: * rejecting ADSP=discardable messages with missing or broken signatures * Adding AR headers (that a user or their MUA may never work out how to use effectively) Again, the likelyhood of benefits are signficantly is lower than costs. So DKIM is at a state where there is no offering of filtering advice beyond the theoretical discussion in RFC5863. The current mailing list approach: MLM behaviors are well-established and standards compliant. Thus, the best approach is to provide these best practices to all parties involved, imposing the minimum requirements possible to MLMs themselves. is rather defeatist and limits the encouragement for DKIM-Friendly lists. So for DKIM, filtering is painful as it requires end user specific knowledge of what lists they subscribed to. This is hard enough at small end user organisation let alone an ISP. The end user is left with an AR header field, invisibly hidden by the MUA, to try to filtering out forged mail. For reputation service providers the assumption that mail serivce providers are going to deploy DKIM for the benefit of reputation service providers seems a little hopeful considering their costs. Don't misunderstand me, domain reputation has a role in spam reduction and DKIM contributes to this, there just needs to be more benefit to the
Re: [ietf-dkim] marketing dkim
Folks, Please. Let's get back to the work at hand and not spend time on this, Stephen. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists annex MUA considerations
Ian Eiloart wrote: I guess it would be nice if list servers could use OAuth to authenticate my subscription requests against my mail infrastructure, and then my servers would recognise and record the request. Then it could treat messages from the list with a higher trust level, and -for example- file them accordingly. Interesting. Would this be similar or nearly have the same functionally by using an alias email address? for example: iane-d...@sussex.ac.uk Once you have that targeted address, you can apply all sorts of rules at your receiver. But I can see your derivative of your idea work as a way to automate the process. Use a redirection method by wrapping all the subscription parameters (for any list system) and send it to a (web) service on your system which activates a backend process to add the list info or new alias into your system records and finishes with the actual subscription email request. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] marketing dkim
On Aug 19, 2010, at 12:56 PM, Stephen Farrell wrote: Folks, Please. Let's get back to the work at hand and not spend time on this, Encouraging use of DKIM, and avoiding confusion between ADSP flaws and DKIM flaws is a big part of the work at hand, I think. If it's not, it should be. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] marketing dkim
Encouraging use of DKIM, and avoiding confusion between ADSP flaws and DKIM flaws is a big part of the work at hand, I think. If it's not, it should be. Agreed. It would be nice to collect enough data about ADSP so we can figure out whether my take on it or Mike's is closer to reality. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
