The actual definition of SMTP mail protocol allows explicitly for any entity to identify itself with any domain in both the HELO/EHLO and MAIL commands, it also allows any entity to identify itself with any mailbox in the From Header as long the syntax of RFC 2821 and 2822 is respected. This gives an attacker an opportunity to send mail pretending to be someone else, injecting thousands and even millions of unwanted mail into a normal mail flow. To minimize this risk and to make sure that the MTA server sending the mail is actually authorized to use the that domain, a new protocol was generated called Sender Policy Framework (SPF) which is one of the many tools that exist to fight against mail usage abuse.
Its definition began in 2003 and since, it has been implemented in many organization, it has not received the expected acceptance for many reasons though. RFC 4408 is an experimental standard that includes all efforts made to define this protocol and mitigate all security holes and attacks that the protocol itself adds when implemented. Because it is experimental, there is no organization, including IETF, that can give any official support, so any implementation should be treated as a test and its objective should be the detection of vulnerabilities that might be mitigated in the future.
The actual definition of the standard as stated by IETF is:
This document defines a protocol by which domain owners may authorize
hosts to use their domain name in the “MAIL FROM” or “HELO” identity.
Compliant domain holders publish Sender Policy Framework (SPF)
records specifying which hosts are permitted to use their names, and
compliant mail receivers use the published SPF records to test the
authorization of sending Mail Transfer Agents (MTAs) using a given
“HELO” or “MAIL FROM” identity during a mail transaction.
According to this definition, SPF pretends to help mail systems by identifying, before receiving any mail, that the domain specified by the SMTP Client in the HELO (in this context HELO includes both EHLO and HELO commands) or / and the MAIL command is actually authorizing the sending IP to use its name. To accomplish this goal, mail systems that intend to make this kind of validation should perform a DNS query for the TXT record in the domain root. The information of this record should include the list of IP addresses authorized by this domain to use its name in the Envelope of the mail.
It is assumed by this definition that by actually performing this verification in one or both HELO and MAIL commands, SPF is rejecting mails based on the public available information. This means that SPF doesn’t reject mail based on its contents. By rejecting connections, SPF gives an additional functionality, since this rejection operation prevents from receiving mails from IP addresses that are not authorized to use a specific domain name and therefore the SPF mail servers compliant may see a performance improvement by not wasting resources in fake mails.
It is, therefore, not valid to ask about the contents of rejected mails, or to look for those mails in the mail server, for these mails where never received. You can only verify the list of IP addresses whose connections have been closed by the SPF engine.
For more information about the rules to create, transmit and process an email you can check out our publication on The SMTP Protocol Fundamentals.
Remember to send us your questions and comments to our Twitter account:@redinskala where you can find more information and security tips.
Thanks for your visit!