> -----Original Message----- > From: [email protected] [mailto:ietf-dkim- > [email protected]] On Behalf Of Steve Atkins > Sent: Wednesday, March 11, 2009 4:36 PM > To: ietf-dkim WG > Subject: Re: [ietf-dkim] Another take on "all email from us is dkim > signed" > > > On Mar 11, 2009, at 1:20 PM, MH Michael Hammer (5304) wrote: > > >> > >> It seems to me that the domains likely to benefit from the ability to > >> state "All email we send is DKIM signed" share a few things in > >> common. > >> > >> 1. They're concerned about other people sending email claiming to > >> be "from" the domain. > >> > >> 2. They send email using the domain to, typically, a large number > >> of B2C recipients (excluding the null assertion "we send no email", > >> which can be handled in other ways) > >> > > > > I would not exclude B2B out of hand. Many financial institutions > > communicate with business customers. I would also point to this > > example > > http://www.webpronews.com/topnews/2007/10/31/grocery-store-falls-for-10- > > million-phishing-scam as to why businesses might want to assert that > > all > > their B2B mail is signed. > > The same reasoning applies to B2B email. > > > Which other ways would you assert "we send no mail" to protect the > > RFC2822 From email address? > > SPF is the obvious solution. MX 0 . is another. >
There are a number of issues in using SPF in the manner you suggest. The first is that SPF is path based. It basically says "here are the hosts authorized to send mail for this domain" (transport layer). The RFC2822 >From is data, not transport layer. This is exactly the complaint against Microsoft/Sender-ID when they decided to misuse SPFv1 records for PRA evaluation. SPF protects the transport layer Mail From and EHLO. For most implementations I'm aware of the intent and practice is to reject at EHLO or reject on Mail From. At this point the RFC2822 From is not available for checking. If a receiver has already checked > However, given the supposed threat is phishing, "we send no email" > is mostly a red herring. > > > > > >> 3. All the email they send is DKIM signed. > >> > >> 4. They primarily care about mail appearing to be "from" their > >> domain being sent to users who also legitimately receive real email > >> from them. > >> > >> It also seems that the number of domains who want this will likely be > >> a small fraction of the total number of domains, and likely a small > >> fraction of the number of emails sent. > >> > > > > That may be true today but may not be true tomorrow. > > > >> The combination of 2, 3 and 4 means that any receiving ISP that > >> receives "forged" email that the domain cares about will also receive > >> legitimate email from that domain. > >> > > > > Perhaps, perhaps not. There is also the case of an ISP receiving > > fraudulent email prior to receiving legitimate email (race condition). > > If the threat is phishing, this is very unlikely. Phishing is pretending > to be an existing brand. If the existing brand is already in use then > it's very likely that there's going to be at least one existing user at > an ISP. It would also be very easy to setup your business model > such that you can ensure that every user has received at least > one legitimate email from you before they are in the situation > where they are at any risk of phishing. Sending them an email > with their username in it, for example. > A brand can have brand recognition without an individual (or receiving domain) having received an email from that domain before. Take the domain ibm.com. How many people are familiar with IBM as a company/brand? How many people know that IBM never sends email from the primary domain ibm.com? So how many receivers have received an email from ibm.com? (the correct answer is none). Consider the cases of Facebook, MySpace, and LinkedIn. Many people/receivers were aware of the brands long before they received an email from those brands. So, how would individuals/receivers know a priori what the characteristics of a legitimate email from those brands are or what a legitimate email from those brands should look like? > If the threat is not phishing, then we need to be explicit about what > the threat is before judging how different approaches affect it. > I've been talking about phishing. What other threats would you like to throw into the fire? > > > >> If there were another field in the DKIM-Signature header, or an > >> entirely separate email header covered by the DKIM signature, that > >> stated "all email sent using this domain in the From field will be > >> DKIM signed" then any receiving MTA or MTA cluster could keep track > >> of > >> that state (probably using their existing reputation tracking system > >> in the case of large receivers, and using a fairly trivial extension > >> to their DKIM plugins in the case of smaller ones). > >> > >> That would provide all the benefit of ADSP to senders who want it, > >> without adding a per-email latency overhead for receivers who want to > >> support it, at the cost of a keeping a fairly small amount of state > >> at > >> the receiving MTA. > >> > >> (Other information could be communicated in-band in the same way - > >> including "we're no longer dkim signing every email sent"). > >> > > > > Why not include both options (trying to be flexible here)? If one > > looks > > at Daves affilias proposal, some receivers might choose to check for > > ADSP records against some arbitrary list of domains (all registered > > financial institutions for example). > > If there's a third party list then this, and ADSP, are entirely > irrelevant. > Not at all. Before DKIM signing becomes universal (Mike starts singing "that'll be the day"), receivers may choose to use various approaches to authenticating domains and validating the nature of those domains. For example, BITS has stated (and indicated specific time frames) for members (financial institutions) to implement SPF and DKIM signing. Therefore, a receiver may choose to look at a list of members provided by BITS after the compliance date as a means of knowing that mail purporting to be from these member institutions should have an ADSP record. In this case ADSP is NOT irrelevant. Determining that a domain SHOULD have an ADSP record does not tell us what that ADSP record contains. > This, and ADSP, address the specific use case where senders > believe there should be no such third party list and that they should > be able to self-publish the information. > > That doesn't mean that they couldn't both be used, just that they > shouldn't be conflated. > No conflation here. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
