> -----Original Message----- > From: [email protected] [mailto:ietf-dkim- > [email protected]] On Behalf Of Steve Atkins > Sent: Wednesday, March 11, 2009 3:34 PM > To: ietf-dkim WG > Subject: [ietf-dkim] Another take on "all email from us is dkim signed" > > 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. Which other ways would you assert "we send no mail" to protect the RFC2822 From email address? > 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 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). > Did we already look at this idea and discard it before we settled on > using a DNS query for every email received? > It was discussed at one point. Mike _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
