User:David MacQuigg/Sender Policy Framework: Difference between revisions
imported>David MacQuigg No edit summary |
imported>David MacQuigg |
||
Line 8: | Line 8: | ||
=== How it works === | === How it works === | ||
Senders that wish to use SPF should publish two identical records under their domain name in DNS. Typical DNS records might look like: | |||
example.com. 1800 IN TXT "v=spf1 ip4:192.168.33.32/28 mx a:colo.example.net ?all" | |||
example.com. 1800 IN SPF "v=spf1 ip4:192.168.33.32/28 mx a:colo.example.net ?all" | |||
These records authorize a number of IP addresses to transmit email for example.ocm. These addresses include a block of 16 starting at 192.168.33.32, plus any addresses found in MX records for that same domain (i.e. the incoming mail servers), plus any addresses found in A records for the domain colo.example.net. The ?all term at the end means to treat all other addresses as "neutral", meaning the same as if no SPF records were published. | |||
1) The sender (typically the Mail Submission Agent) checks the envelope return address to make sure the domain part is "example.com", then relays the message to the Transmitter. | |||
2) The Receiver extracts the domain part of the return address, and does a DNS query (preferably for the SPF record) under that domain. | |||
3) The terms in the SPF record are tested one at a time, left to right, and the first definite result (pass or fail) is accepted. The prefixes (+, -, ?) mean (pass, fail, neutral), with + being the default. | |||
4) The Receiver adds an authentication header to the message: | |||
Received-SPF: Pass (mx1.example.org: domain of | |||
myname@example.com designates 192.168.33.35 as permitted sender) | |||
receiver=mx1.example.org; client-ip=192.168.33.35; | |||
envelope-from=<myname@example.com>; helo=foo.example.com; | |||
==== Explanatory notes ==== | ==== Explanatory notes ==== | ||
TXT is the code for a text record in DNS. Text records can store any text strings the domain owner wants to publish. SPF is a new record type, a TXT record just for SPF data. It will be necessary to publish both records until all DNS software is able to recognize the new type. | |||
1800 seconds is the lifetime of the DNS record after it has left the server on which it was published. This allows frequently used records to be read from a cache, instead of doing a fresh query every time. | |||
Everything between the double quotes is part of the text string, but not the quotes themselves. The string consists of a number of space-delimited terms. "v=spf1" means this is a record for version 1 of SPF. | |||
The TXT record for DKIM consists of a number of key=value pairs. This syntax takes a little more space, but it allows for future growth of DKIM by simply adding new key items. This record specifies an encryption algorithm (k=) a hash algorithm (h=) and a public key value (p=). The public key is 216 [[base64]] characters, so it fits easily within DNS limits (255 characters per string, 512 bytes in a DNS packet). Each base64 character encodes 6 bits, so the total key length is 1296 bits (216 * 6), and this is considered quite secure. | |||
The Authentication-Results header above shows that there were actually two signatures in this message. DomainKeys was the predecessor to DKIM, so this is probably a legacy system in the sender's domain. | |||
=== Bibliography === | === Bibliography === |
Revision as of 18:01, 19 October 2009
Definition: Method for authenticating the return address on an email message.
Sender Policy Framework (SPF) is an email authentication method that seeks to correlate the domain name in the envelope return address with the IP address of an SMTP client currently connected and waiting to send a message. While the client is still connected, and before receiving the message data, the server does a DNS query for an SPF record on the domain name.
If the IP address is listed in the SPF record, the authentication result is PASS, and the message may be processed in accordance with the reputation assigned to the domain. If the authentication result is FAIL, the message may be immediately rejected without any data transfer. Often, however, the result is neither PASS nor FAIL, but unclear. This is a result of the many domains that don't publish SPF records, or that have records giving unclear results.
Limitations
How it works
Senders that wish to use SPF should publish two identical records under their domain name in DNS. Typical DNS records might look like:
example.com. 1800 IN TXT "v=spf1 ip4:192.168.33.32/28 mx a:colo.example.net ?all" example.com. 1800 IN SPF "v=spf1 ip4:192.168.33.32/28 mx a:colo.example.net ?all"
These records authorize a number of IP addresses to transmit email for example.ocm. These addresses include a block of 16 starting at 192.168.33.32, plus any addresses found in MX records for that same domain (i.e. the incoming mail servers), plus any addresses found in A records for the domain colo.example.net. The ?all term at the end means to treat all other addresses as "neutral", meaning the same as if no SPF records were published.
1) The sender (typically the Mail Submission Agent) checks the envelope return address to make sure the domain part is "example.com", then relays the message to the Transmitter.
2) The Receiver extracts the domain part of the return address, and does a DNS query (preferably for the SPF record) under that domain.
3) The terms in the SPF record are tested one at a time, left to right, and the first definite result (pass or fail) is accepted. The prefixes (+, -, ?) mean (pass, fail, neutral), with + being the default.
4) The Receiver adds an authentication header to the message:
Received-SPF: Pass (mx1.example.org: domain of myname@example.com designates 192.168.33.35 as permitted sender) receiver=mx1.example.org; client-ip=192.168.33.35; envelope-from=<myname@example.com>; helo=foo.example.com;
Explanatory notes
TXT is the code for a text record in DNS. Text records can store any text strings the domain owner wants to publish. SPF is a new record type, a TXT record just for SPF data. It will be necessary to publish both records until all DNS software is able to recognize the new type.
1800 seconds is the lifetime of the DNS record after it has left the server on which it was published. This allows frequently used records to be read from a cache, instead of doing a fresh query every time.
Everything between the double quotes is part of the text string, but not the quotes themselves. The string consists of a number of space-delimited terms. "v=spf1" means this is a record for version 1 of SPF.
The TXT record for DKIM consists of a number of key=value pairs. This syntax takes a little more space, but it allows for future growth of DKIM by simply adding new key items. This record specifies an encryption algorithm (k=) a hash algorithm (h=) and a public key value (p=). The public key is 216 base64 characters, so it fits easily within DNS limits (255 characters per string, 512 bytes in a DNS packet). Each base64 character encodes 6 bits, so the total key length is 1296 bits (216 * 6), and this is considered quite secure.
The Authentication-Results header above shows that there were actually two signatures in this message. DomainKeys was the predecessor to DKIM, so this is probably a legacy system in the sender's domain.
Bibliography
- [RFC-4408] [r]: Add brief definition or description - "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", M. Wong, W. Schlitt, 2006.
- [Sender Policy Framework] [r]: Add brief definition or description - project website