Assurance

["Joe St Sauver" <>]

David Langenberg 
<>
 commented:

#Brief searching seems to indicate you can provide limited signing support
#by using DKIM and DomainKeys for Google, and Sender-ID for MSFT properties.
#However, the side-effects of setting those up definitely takes it out of
#the short and probably even medium term for us.

It may help to provide some backfill on those efforts, since I work with 
some of the people who are deploying those protocols as a result of my 
work with MAAWG (the Messaging Anti-Abuse Working Group)

-- DKIM is really designed just to allow a sender to "take responsibility"
for a message in transit that was cryptographically signed with its key. 
It is meant to ensure that receiving entities can make reputation-based 
decisions about whether or not they want to trust and accept a given 
message for delivery.

For those who'd like to read more than they ever wanted to know about
DKIM, see some of the resources at http://www.dkim.org/

(DKIM has largely surplanted/replaced DomainKeys, see 
"What are the differences between DomainKeys (DK) and DKIM" in
http://www.dkim.org/info/dkim-faq.html )

-- SPF is related, but takes a somewhat different spin on the problem.

In a nutshell, imagine that you're a bank, or some other major target
of phishing. Without SPF, anyone can send mail purporting to be you 
from any location in the world -- a cybercafe in Argentina or a botted
host in Zambia will work equally well. With SPF, you can specify that
mail from your your domain should *only* originate from particular network
ranges, and that if you see mail pretending to be from your bank from
somewhere else, SPF explains how you should treat that (potentially to
include discarding it outright).

OpenSPF focuses on the envelope sender domains (as seen by mail transfer
agents such as Sendmail or Postfix or Exim), while Sender-ID focuses on
the message body sender domains (as seen by the users), but both are
really types of SPF.

For more than you ever wanted to know about SPF, see http://www.openspf.org/

-- While there's a perception that DKIM is strongly aligned with one
provider while SPF or Sender-ID may be aligned with others, many providers
use *both*, e.g., if you check Gmail, for example, which was mentioned as
being aligned with DKIM, you'll see that they also use SPF:

% host -t txt gmail.com
gmail.com text "v=spf1 redirect=_spf.google.com"
% host -t txt _spf.google.com
_spf.google.com text "v=spf1 include:_netblocks.google.com ?all"
% host -t txt _netblocks.google.com
_netblocks.google.com text "v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 
ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 
ip4:74.125.0.0/16 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ip4:173.194.0.0/16 
?all"

-- I should also mention DMARC (see www.dmarc.org). Dmarc leverages DKIM
and SPF so that you can get a sense of how your DKIM and SPF records are
working for you, most importantly providing a mechanism that allows an 
email receiver to report back to the sender about messages that pass or fail
DMARC evaluation. 

Bottom line, SPF and DKIM are not a replacement for S/MIME or PGP/GnuPrivacy
Guard-signing of messages. SPF and DKIM are useful and important tools, but
they work in a different problem space than S/MIME and PGP/GPG.

Regards,

Joe