|
There are other e-mail authentication protocols besides ''SPF''. They differ in which addresses ''(identities)'' they authenticate and how they do it. In order to understand how the various protocols relate to each other, you need to understand the various parts of which e-mail messages are made. As the figure shows, a message has an ''envelope'' (representing the SMTP transaction, see [[RFC:2821|RFC 2821]]), a ''header'' (see [[RFC:2822|RFC 2822]]), and a ''body'' (which contains the actual text of the message and any attachments).
| | There are other e-mail authentication protocols besides ''SPF''. They differ in which addresses ''(identities)'' they authenticate and how they do it. In order to understand how the various protocols relate to each other, you need to understand the various parts of which e-mail messages are made. As the figure shows, a message has an ''envelope'' (representing the SMTP transaction, see [[RFC:5321|RFC 5321]]), a ''header'' (see [[RFC:5322|RFC 5322]]), and a ''body'' (which contains the actual text of the message and any attachments).
|
|
Although ''Sender ID'' uses DNS records with a nearly identical syntax to ''SPF'', and even uses the letters "SPF" in its version string ("<u><tt>spf2.0/pra</tt></u>"), it is not the same protocol because it authenticates the PRA header identity, whereas ''SPF'' authenticates the envelope <tt>MAIL FROM</tt> identity. ''Sender ID'' is compatible with ''SPF'' as long as there is no confusion as to which DNS records refer to which protocol. Unfortunately, RFC 4406 recommends using ''SPF's'' <tt>v=spf1</tt> records for PRA checks as well as <tt>MAIL FROM</tt> checks. See [[SPF vs Sender ID]] for a detailed explanation on the confusion over ''SPF'' and ''Sender ID''.
| | Although ''Sender ID'' uses DNS records with a nearly identical syntax to ''SPF'', and even uses the letters "SPF" in its version string ("<u><tt>spf2.0/pra</tt></u>"), it is not the same protocol because it authenticates the PRA header identity, whereas ''SPF'' authenticates the envelope <tt>MAIL FROM</tt> identity. ''Sender ID'' is compatible with ''SPF'' as long as there is no confusion as to which DNS records refer to which protocol. Unfortunately, RFC 4406 recommends using ''SPF's'' <tt>v=spf1</tt> records for PRA checks as well as <tt>MAIL FROM</tt> checks. See [[SPF vs Sender ID]] for a detailed explanation on the confusion over ''SPF'' and ''Sender ID''.
|
| | Today it is little used. Even Microsoft has migrated away from using Sender ID.
|
==== [[http://tools.ietf.org/wg/dkim|Author Domain Signing Practices]] (<html><a name=ADSP" id="ADSP">ADSP</a></html>)
| | ==== [[http://tools.ietf.org/wg/dkim|Author Domain Signing Practices]] (<html><a name=ADSP" id="ADSP">ADSP</a></html>)
|
[[Wikipedia:Author Domain Signing Practises|ADSP]] is a protocol created by the IETF DKIM WG, see [[#DKIM|below]]. Roughly it allows to state that '''all''' mails with a given domain in an author address, i.e. the [[RFC:2822|RFC 2822]] ''From'', are signed using DKIM, and additionally that other mails are '''discardable'''. The ''signing practices'' of say domain <tt>example.com</tt> are published in a [[DNS]] TXT record for <tt>_adsp._domainkey.example.com</tt>.
| | [[Wikipedia:Author Domain Signing Practises|ADSP]] was a protocol created by the IETF DKIM WG, see [[#DKIM|below]]. Roughly it allows to state that '''all''' mails with a given domain in an author address, i.e. the [[RFC:2822|RFC 2822]] ''From'', are signed using DKIM, and additionally that other mails are '''discardable'''. The ''signing practices'' of say domain <tt>example.com</tt> are published in a [[DNS]] TXT record for <tt>_adsp._domainkey.example.com</tt>.
|
| |
|
Any wildcard TXT records for <tt>example.com</tt> would belong to the same set of TXT records, and this set might be too big if it contains TXT records for ''SPF'', ''Sender ID'', and ''ADSP''. A workaround could be to '''move''' the rarely supported ''Sender ID'' policy to a wildcard SPF record, '''copy''' the ''SPF'' policy to another wildcard SPF record, and keep only the ''SPF'' policy and ''ADSP'' as wildcard TXT records. The fine print of wildcard records is explained in [[RFC:4592|RFC 4592]].
| | ==== [[http://www.dmarc.org|Domain-based Message Authentication, Reporting & Conformance]] (<html><a name=DMARC" id="DMARC">DMARC</a></html>)
[[Wikipedia:DMARC|DMARC]] is an attempt to address the shortfalls of ADSP and develop a higher level policy protocol that would be more broadly deployable.
In addition to leveraging DKIM results, it uses SPF results to help determine if a mail is from an authorized source. It combines the SPF/DKIM results with an identity alignement test (which requires the Mail From domain for SPF and the signing domain for DKIM to be the same as the body From domain) to impose restrictions related to the From domain. If either SPF or DKIM pass/verify and are aligned, a message is DMARC authorized.
|
| |
|
| | DMARC also adds both aggregated and per message feedback reporting to enable senders to assess the effectiveness of their ongoing email authentication operations.
|
> ''For more related solutions see the [[Wikipedia:Category:E-mail_authentication|E-mail authentication]] category on Wikipedia.''
| | > ''For more related solutions see the [[Wikipedia:Category:E-mail_authentication|E-mail authentication]] category on Wikipedia.''
|
