Sender Policy Framework

from Wikipedia, the free encyclopedia
Simplified example of address verification with SPF. The mail servers Alice, Bob and Mallory identify themselves using IP addresses; the names are only symbolic. Bob receives spam from Mallory with "info @ alice" as a fake sender address. Bob asks Alice for the SPF entry, which says that legitimate mail from the "alice" domain can only come from the IP address assigned to Alice. Bob finds a mismatched SPF record and discards the spam instead of forwarding it.

The Sender Policy Framework ( SPF ; formerly Sender Permitted From ) is a procedure with which the falsification of the sender address of an email is to be prevented, more precisely prevents the sending of emails via illegitimate Mail Transfer Agents (MTAs). It originated as a method to ward off spam . With SPF, the owner of a domain enters in the Domain Name System which MTA addresses are authorized to send e-mails for this domain.

functionality

The administrator of a domain stores a resource record of the type in the DNS zone (which has been made obsolete by RFC 7208 ). These resource records contain the IP addresses of the Mail Transfer Agents (MTA) that are allowed to send e-mails for the domain. The recipient checks whether the sender is authorized to send. To do this, the recipient checks which domain the sender has specified in the " MAIL FROM " and "HELO" fields in the SMTP connection . The recipient calls up the SPF information for the specified domain via the Domain Name System and compares the IP address of the sending MTA with the permitted addresses. If the IP address matches, the sender is authentic, otherwise the email can be discarded. TXTSPF Resource Record

Please note that this check does not refer to the "From" header, which is normally displayed as the sender by e-mail programs and can also contain a name. SPF cannot protect against fraudsters trying to deceive consumers. However, it can help determine this.

In the DNS entry of a domain there are already normal MXentries that tell SMTP servers to which host they should send e-mails for this domain. So if an SMTP server should send an email to test@example.org , it looks in the MXrecord of example.org to which server it should send the mail. With SPF, a record in the style of a reverse MX is now added to the DNS entries of a domain. If a mail server receives an e-mail from a sender from example.org , it looks in the SPF record of example.org whether the sending mail server is authorized to send mail for this domain according to the SPF record.

By making emails easier to trace, SPF can also help combat spam and make phishing more difficult . However, SPF only claims to prevent sender address forgery, but not to directly combat spam.

SPF only has to be supported by the receiving system - nothing changes in the mail transmission protocol (SMTP). The publication of SPF records is voluntary for a domain; according to the SPF specification ( RFC 4408 ) , emails from domains without SPF records should not be classified as negative by recipients; however, as before, such domains naturally remain unprotected against forged envelope addresses.

Structure of an SPF record

Each SPF record begins with a version number - for the current SPF version "v = spf1". Any number of expressions follow, which are evaluated in the order from front to back. Most of the expressions are so-called directives that define the authorization of the sender and consist of an optional qualifier and a so-called mechanism that either results in a hit or no hit for a given situation (IP address). The first mechanism, which represents a hit, determines the result of the entire evaluation of the SPF record.

There are the following qualifiers:

Q. Result code description
+ Pass the directive defines authorized senders;
this is the standard; H. if no qualifier is given, it is +assumed
- Fail the directive defines unauthorized senders
~ Softfail the directive defines unauthorized senders, but the recipient should treat this failure generously.
? Neutral the directive defines broadcasters whose legitimacy should not be predicted; the sender must be treated as if no qualifier were specified.

The following table shows some common mechanisms:

Mech. Directive applies if ...
all always
a … A A- (or AAAA-) record of the questioned (or explicitly specified) domain contains the IP address of the sender
mx ... a MXrecord of the questioned (or explicitly specified) domain contains the IP address of the sender
ip4 ... the specified IPv4 address is the IP address of the sender or the specified IPv4 subnet contains it
ip6 ... the specified IPv6 address is the IP address of the sender or the specified IPv6 subnet contains it
include ... an additional SPF request for the domain specified in the include statement contains the IP address of the sender

The subpage of the SPF website provides an overview of all permitted expressions.

In addition to the directives, there are attributes ( modifiers ) that can only appear once and provide additional information:

Modifier description
redirect The SPF record of another domain should be obtained and evaluated
exp Refers to a domain whose TXT record contains an explanation for the user if the email was rejected

example

$ host -t TXT gmx.de
gmx.de descriptive text "v=spf1 ip4:213.165.64.0/23 ip4:74.208.5.64/26 ip4:212.227.126.128/25 ip4:212.227.15.0/25 ip4:212.227.17.0/27 ip4:74.208.4.192/26 ip4:82.165.159.0/24 ip4:217.72.207.0/27 -all"

The company GMX specifies that all hosts with the IPv4 address 213.165.64.0 to 213.165.65.255, as well as 74.208.5.64 to 74.208.5.127 and some other address ranges gmx.deare allowed to send e-mails from the domain . According to this SPF record, all other servers are not authorized to use this domain in the envelope sender address.

status

Version 1 of SPF has largely remained unchanged since the end of 2003, initially as an informal specification. On April 28, 2006, SPFv1 was published by the IETF as RFC 4408. The RFC has the status "Experimental" because the IETF working group "marid" (" MTA Authorization Records in DNS ") , which had been set up beforehand , worked on several of the proceedings at issue, but could not agree on one of the proceedings. In April 2014 the IETF published the RFC 7208 "Sender Policy Framework (SPF)" as "Proposed Standard", which was supplemented in September 2014 by RFC 7372 (also as "Proposed Standard") published by the IETF working group "spfbis" .

Among the best-known supporters of SPF among the e-mail service providers are (as of 2020):

Email service provider Qualifier
Arcor Fail
GMX Fail
Web.de Fail
AOL Softfail
Google ( Gmail ) Softfail
Microsoft ( Hotmail and Outlook.com ) Softfail
Yahoo Neutral

GMX has been using SPF productively since April 2004. Other large providers such as T-Online do not publish an SPF record (as of October 2019).

SPF is not only interesting for e-mail service providers, but also in general for companies that send e-mails to their customers and, with SPF, offer recipients the option of receiving e-mails from IP addresses that are not authorized by the company were sent with the sender domain of the company according to the qualifier specified by the company. The top 10 websites in Germany all use SPF (as of 2020):

Website Qualifier
Google.com Softfail
Youtube.com Fail
Google.de Fail
Amazon.de Fail
Ebay.de Softfail
Wikipedia.org Softfail
Ebay-kleinangebote.de Softfail
Reddit.com Softfail
Facebook.com Fail
Livejasmin.com Fail

Spam filters such as AMaViS use SPF verification to evaluate incoming emails.

Many mail operators inform about an SPF verification in the mail header , for example by inserting a line 

Received-SPF: pass (gmail.com: domain of foo@example.org designates 127.0.0.1 as permitted sender)

or 

X-Warning: SPF records of example.org exclude 127.0.0.2

Mail redirection problems

The use of SPF can cause problems if the recipient has their e-mails redirected to a mailbox under another domain: In this case, the receiving system sees the sender's domain in connection with the IP address of the redirecting system. However, the latter is typically not covered by the SPF rules, so that such a mail is classified as unauthorized in an SPF check.

There are three possible solutions to this problem:

  1. The receiving system dispenses with the SPF check of emails from the redirected domains, provided they are known to it - for example through whitelisting . In this case, it makes sense for the forwarding systems to take over the SPF check. A disadvantage of this procedure is that in the event of a delivery error, the error message (bounce) is sent directly to the sender. This could find out from the destination address of the redirection what u. U. is undesirable by the recipient.
  2. This problem can be avoided if the forwarding system rewrites the envelope sender addresses of the redirected mails to its own domain and thus takes responsibility for the validity of the original sender address and for the delivery of any bounces . Such a method is e.g. B. the Sender Rewriting Scheme (SRS). However, it must be ensured that the referring system carries out an effective SPF check, which can e.g. Not always the case at the moment.
  3. The sending server first sends the data to the permitted mail server (relaying). So-called satellite mail servers can be used on the Internet for this purpose, which are then authorized to receive data from the web server and to forward them to your own mail server.

Implementation of web forms

SPF can cause problems with some web forms that are poorly implemented. There are web forms that ask for your name and email address. If the web form is now sent to the website operator by e-mail, this e-mail is incorrectly designed as if it came directly from the person who filled in the data. The address given in the form is used as the sender address. If the domain of this email address is now working with SPF and the website operator carries out SPF checks himself, the submitted form may never reach the website operator. In this case, the website operator unsuccessfully checks his own authorization to send e-mails on behalf of the foreign domain.

This problem can be avoided if the web server identifies itself as the sender of the mail and uses its own authorized domain to send the e-mail. The desired sender can, however , be stored in the From header of the mail. The effect is that replies to the e-mail are automatically sent to the form filler who is also displayed as the sender of the mail content, but the SPF check does not fail because the web server is correctly named as the actual sender. This would also receive the bounce mails.

criticism

In the area of ​​the use of unauthorized mail transfer agents (MTAs) for domains protected with SPF, SPF is a controversial process.

  • End users are generally unaware of the existence of SPF and the need to enable whitelisting when redirected. When setting up e-mail redirection on a system that does not work adequately without the Sender Rewriting Scheme (SRS), users no longer receive e-mails from SPF-protected domains.
  • By restricting the permitted MTA addresses of a domain, various usage scenarios are also restricted which are usually used in the area of ​​sending spam and are therefore prevented. In the local network of the employer, the university and the like, outgoing SMTP connections can be prevented by the firewall . This is done in order to limit the sending of spam from the network or to be able to control the outgoing e-mail traffic. If a user in this network wants to use his private e-mail address, he cannot establish an SMTP connection to the authorized MTA of his private e-mail service. If the private e-mail provider uses SPF and the user uses the unauthorized MTA of the local network operator and the employer, this behavior corresponds to the method that spamers use to send spam messages via open mail relays. One possible solution is to use a mail submission agent whose port is not blocked by the local firewall or a corresponding other access to the authorized MTA.
  • SPF only acts indirectly against spam and malware , as spammers use “throwaway domains” and the e-mail systems of hijacked “zombie computers” with their correct SPF records. SPF is also not an address protection, but rather a protection of the domain owner that only the MTAs authorized for this domain are used to send e-mails with their domain sender address, i.e. a kind of protection against the use of unauthorized SMTP relays for the domain in question .

Web links

criticism

See also

Individual evidence

  1. ↑ RFC 7208, Section 3.1
  2. ↑ SPF Record Syntax
  3. ↑ Alexa. Top sites in Germany. Archived from the original on July 6, 2020 ; accessed on July 7, 2020 (English).