ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Another take on "all email from us is dkim signed"

2009-03-11 16:52:55

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.

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.

If the threat is not phishing, then we need to be explicit about what
the threat is before judging how different approaches affect it.


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.

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.

Cheers,
   Steve

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html