Sender Policy Framework
The Sender Policy Framework (SPF; formerly Sender Permitted From) is a procedure designed to prevent tampering with the sender's address of an email. It was created as a method to block spam. With SPF, the holder of a domain contributes to the Domain Name System, a which computers are authorized to send e -mails for this domain.
Operation
The administrator of a domain stored in the DNS zone of a resource record of type SPF and ( for compatibility reasons ) TXT. In these resource records the IP addresses of Mail Transfer Agents ( MTA) are included, which are allowed to send for the domain e-mails. The receiver checks whether the sender is authorized to dispatch. To this end, the receiver checks which domain has specified in the SMTP connection to the sender in the fields " MAIL FROM " and " HELO ". For the specified domain, the receiver retrieves the SPF information about the domain name system and compares the IP address of the sending MTA with the allowed addresses. Conforms the IP address, then the sender is authentic, otherwise the email will be rejected.
In the DNS record of a domain have so far been normal MX records exist, the SMTP servers say which host they should send e- mails for this domain. So if a SMTP server to send an e- mail to [email protected], he looks in the MX record of example.org which server it should send the mail. With SPF, now a record is added to the DNS records of a domain in the style of a reverse MX. Receives a mail server an e -mail with a sender of example.org, he looks after the SPF record of example.org, whether the effecting service mail server is allowed according to the SPF record to send emails for this domain.
SPF can thus contribute to the easier traceability of e- mails to combat spam and aggravation of phishing. However, SPF stands only claim to prevent sender address forgery, but not directly to combat spam.
SPF must be supported by the recipient system - the log of the mail transfer (SMTP), nothing changes. The publication of SPF records is voluntary for a domain that mails from domains without SPF records are to be loud SPF specification (RFC 4408) of recipients not classified negative; However, such domains remain naturally as previously unprotected against envelope address counterfeiting.
Building a SPF records
Each SPF record begins with a version number - for the current version of SPF "v = spf1 ". Followed by any number of expressions that are evaluated in the order from front to back. Most expressions are called directives that define the authorization of the sender, and consist of an optional qualifier and a so-called mechanism for a given situation (IP address ) is either a hit or no hit results. The first mechanism, which is a hit, determines the outcome of the entire evaluation of the SPF records.
There are the following qualifiers:
The following table shows some common mechanisms:
An overview of allowed expressions are the bottom of the SPF website.
Example
$ Host -t txt gmx.de gmx.de descriptive text " v = spf1 ip4: 213.165.64.0/23 ip4: 74.208.5.64/26 -all" The company GMX sets so that all hosts must send with the IPv4 address 213.165.64.0 to 213.165.65.255 and 74.208.5.64 74.208.5.127 to e- mails from the gmx.de domain. All other servers are not authorized to use this domain in the envelope sender address according to this SPF record.
Status
SPF is the version 1 since the end of 2003 largely unchanged as an informal specification. On 28 April 2006, SPFv1 published by the IETF as RFC 4408 and is now finally fixed in its form. The RFC has a status of " experimental " since the time set in advance MARID working group of the IETF edited several under discussion process, but could not agree on any of the methods.
Among the most famous supporters of SPF include not only GMX, Microsoft ( Hotmail), Arcor, AOL, and Gmail. GMX SPF is already in April 2004 productively. A number of large providers such as T-Online, Web.de, Yahoo has to date (July 2013) yet published no SPF record. Other companies use vague qualifiers " Softfail " or " neutral ". Gmail uses the most tolerant "Neutral" setting.
Just about all the spam filter (eg AMaViS ) use SPF verification to evaluate incoming e -mails. For this, the qualifiers " Softfail " and " Neutral" usable.
Many mail operators inform you of a SPF verification was carried out in the mail header, for example, by inserting a row
Received - SPF: pass ( gmail.com: domain of designates 127.0.0.1 as permitted sender [email protected] ) or
X -Warning: SPF records of example.org exclude 127.0.0.2 Problems with mail forwarding
The use of SPF can cause problems if the recipient can redirect his e -mails to a mailbox under a different domain: The receiving system sees in this case, the domain of the sender in connection with the IP address of the diverting system. The latter will typically not be covered by the SPF rules so that such mail will be classified as unauthorized at an SPF check.
For this problem there are two solutions:
Problems with web forms
SPF can cause some web forms lead to problems. There are many web forms that get the name and e- mail address. If the web form will be sent to the website operator by e-mail, this mail is often designed as if it came directly from the person who filled out the data. It is therefore used as the sender address, the address indicated on the form. If the domain of this e -mail address is now working with SEN and the website operator himself performs SPF checks, the abgeschickte form may never be received by the website operator. The website operator checks in this case unsuccessfully its own authorized to send on behalf of external domain emails.
This problem can be avoided through use of the Reply-To header. Rather than store the form - sender in the From header, where the regular server e- mail address is specified. In the Reply- To header, however, the address of the Formula designs filler is deposited. The effect is that replies to the e-mail automatically go to the form filler, SPF testing but does not fail.
Criticism
In the address counterfeiting defense mechanisms SPF is a controversial procedure. The following criticisms were:
- End users have no knowledge of the existence of SPF and the need to turn on redirection whitelisting in general. When setting up an e -mail forwarding without SRS users get e-mails from SPF -protected domains more delivered.
- By restricting the allowed MTA addresses of a domain also different usage scenarios are limited. In the local network of the employer, the University and the like outgoing SMTP connections can be prevented by the firewall. This is done to limit spamming from inside the network or to control the outgoing e- mail traffic. Want to use a user in this network, a private e- mail address, so he can not establish SMTP connection to the MTA of the e- mail provider. Sets a private e -mail provider SPF, so the user can not use the intended MTA the local network operator also. SPF proponents argue that exactly this is the real objective of SPF: an e -mail provider should check that can be sent over which MTA on behalf of his domain mail. One possible solution is the use of a Mail Submission Agent, which is not blocked by the local firewall.
- Critics speak in the context of SPF also by a "forced Relay" on the respective provider and fear in this context an advantage for both governmental monitoring bodies as well as private data collection. Especially has SPF in this context the property that no local distribution of the outgoing mail traffic occurs more: it always run eg with a GMX address now both incoming e-mail as well as outgoing traffic through the house GMX server, thus enabling potential supervisors and Data miners - a simple capturing the entire e -mail traffic to a central location.
- Although a separate SPF DNS record type has been assigned now and SPFv1 specification provides for the support of this SPF record type, even the DNS TXT record type will be used. So SPF competes with other TXT records to the limited space in DNS UDP response packets, which can result in a total large TXT records of a DNS name to the fact that the UDP response to a TXT query the existing TXT records not fully contains. The problem will have been solved with increasing transition to the dedicated SPF record.
- The system uses bad from spam and malware, because spammers " disposable domains " and e -mail systems hijacked " zombie computers " with the correct SPF records use. The use of open relays and open proxies fall as spam sources, however, whereby the ways spam can be traced back easily.
- Unclear positioning of SPF: The developers of SPF indicate that SPF is not a spam protection per se, but merely a protection against counterfeiting address. For this alone SPF is only very inadequately suitable, since the granularity of address verification inherently includes only entire domains ( and not individuals ) and also no cryptographic security mechanisms the authenticity of the sending computer ( or even the sender ) ensure itself. SPF is thus not address protection, but only one type of relay protection dar.