SMTP Security analyzer explanation and remediation

This page will explain all the issues, warnings, informational and best practice recommendations found in your domains SMTP configuration. 

SPF analyzer:

The following list of issues describe all possible issues found by the SPF analyzer. This analyzer could be run as part of the full suite analyzer or via the individual SPF analyzer. 

Issue 1: Your DNS record contains more than 10 DNS lookups

Explanation in plain words:
To protect from DNS DDOS attacks the SPF protocol has a safeguard in place that states a MTA (Mail transfer Agent) should only honor the first 10 DNS query’s of a SPF record.  If any query is done after the first 10 query`s the MTA should stop processing and return a permerror causing a negative SPF verdict. The EXP modifier does not count towards the SPF query limit.

What can I do to resolve this:
You should reduce the number of DNS query`s by either switching mechanisms (A or MX  to IPV4) or reduce the number of includes. Additionally you can also move sending 3rd parties (that consume a include ) to their own subdomain (preferred) or relay the mail via your own servers.   

Official IETF RFC 7208 text:

Some mechanisms and modifiers (collectively, “terms”) cause DNS queries at the time of evaluation, and some do not.  The following terms cause DNS queries: the “include”, “a”, “mx”, “ptr”, and “exists” mechanisms, and the “redirect” modifier. 

SPF Implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS. If this limit is exceeded, the implementation MUST return “permerror”. The other terms — the “all”, “ip4”, and “ip6” mechanisms, and the “exp” modifier — do not cause DNS queries at the time of SPF evaluation (the “exp” modifier only causes a lookup at a later time), and their use is not subject to this limit.

When evaluating the “mx” mechanism, the number of “MX” resource records queried is included in the overall limit of 10 mechanisms/modifiers that cause DNS lookups as described above.  In addition to that limit, the evaluation of each “MX” record MUST NOT result in querying more than 10 address records — either “A” or “AAAA” resource records.  If this limit is exceeded, the “mx” mechanism MUST produce a “permerror” result.

When evaluating the “ptr” mechanism or the %{p} macro, the number of “PTR” resource records queried is included in the overall limit of 10 mechanisms/modifiers that cause DNS lookups as described above.  In addition to that limit, the evaluation of each “PTR” record MUST NOT result in querying more than 10 address records — either “A” or “AAAA” resource records.  If this limit is exceeded, all records other than the first 10 MUST be ignored.The reason for the disparity is that the set of and contents of the MX record are under control of the publishing ADMD, while the set of and contents of PTR records are under control of the owner of the IP address actually making the connection. These limits are per mechanism or macro in the record, and are in addition to the lookup limits specified above.

MTAs or other processors SHOULD impose a limit on the maximum amount of elapsed time to evaluate check_host().  Such a limit SHOULD allow at least 20 seconds.  If such a limit is exceeded, the result of authorization SHOULD be “temperror”.

Issue 2: Your record contains PTR mechanisms or PTR mechanisms don`t have corresponding A records

Explanation in plain words:
The use of PTR records is discouraged do to the intensive DNS query`s that need to be performed making it more vulnerable to DNS issues. Both forward and backward lookups using the “in-addr.arpa” zone are being used. If PTR is used it is a best practice to have it as the last mechanism before the all mechanism. If there is no A record registered on the result of the reverse address lookup the check still fails. PTR is the only mechanisms that masks (does not expose) your infrastructure to the internet.

What can I do to resolve this:
If there is no business reason to use PTR move to a other mechanism. If the analyzer detected that the A record is not registered you should validate your A host name registrations for missing records. If PTR is not the last mechanism in the line you should move it backwards in your SPF record to the position just before the “all” mechanism.

Official IETF RFC 7208 text:
This mechanism tests whether the DNS reverse-mapping for <ip> exists and correctly points to a domain name within a particular domain. This mechanism SHOULD NOT be published. See the note at the end of this section for more information.ptr = “ptr” [ “:” domain-spec ]The <ip>’s name is looked up using this procedure:

  • Perform a DNS reverse-mapping for <ip>
  • Look up the corresponding PTR record in “in-addr.arpa.” if the address is an IPv4 address and in “ip6.arpa.” if it is an IPv6 address
    For each record returned, validate the domain name by looking up its IP addresses
  • To prevent DoS attacks, the PTR processing limits defined in Section 4.6.4 MUST be applied. If they are exceeded, processing is terminated and the mechanism does not match.
  • If <ip> is among the returned IP addresses, then that domain name is validated.Check all validated domain names to see if they either match the <target-name> domain or are a subdomain of the <target-name> domain.
  • If any do, this mechanism match If no validated domain name can be found, or if none of the validated domain names match or are a subdomain of the <target-name>, this mechanism fails to match. If a DNS error occurs while doing the PTR RR lookup, then this mechanism fails to match. If a DNS error occurs while doing an A RR lookup, then that domain name is skipped and the search continues.
  • This mechanism matches if :
    • the <target-name> is a subdomain of a validated domain name.
    • or the <target-name> and a validated domain name are the same.

For example, “mail.example.com” is within the domain “example.com”, but “mail.bad-example.com” is not. Note: This mechanism is slow, it is not as reliable as other mechanisms in cases of DNS errors, and it places a large burden on the .arpa name servers. If used, proper PTR records have to be in place for the domain’s hosts and the “ptr” mechanism SHOULD be one of the last mechanisms checked. After many years of SPF deployment experience, it has been concluded that it is unnecessary and more reliable alternatives should be used instead. It is, however, still in use as part of the SPF protocol, so compliant check_host() implementations MUST support it.

Issue 3: White space detected in SPF record

Explanation in plain words:
The Analyzer has detected additional white space in the txt record that has no value. As additional white space chews up space in the limited room of a SPF and TXT record it is best practice to remove all the additional white space from your record.

What can I do to resolve this:
The Analyzer adds a “&” sign at the point where it detected the whitespace. Look at the record where the analyzer detected the white space and remove it from your record.

Official IETF RFC 7208 text:
None. This is a best practice.

Issue 4: An incorrect formatted IPv4 address has been detected

Explanation in plain words:
As IPv4 has a IETF standard all IPv4 addresses should be in the form of those standards. Your records contain a IPv4 that is either malformed or out of the range of the IPv4 standard. Most common issue is a typo in the record.

What can I do to resolve this:
Validate all IPv4 records and correct any malformed IPv4 address in your record with the correct address.

Official IETF RFC 791 text:
https://tools.ietf.org/html/rfc791

Wikipedia:
https://en.wikipedia.org/wiki/IPv4

Issue 5: An incorrect formatted IPv6 address has been detected

Explanation in plain words:
As IPv6 has a IETF standard, all IPv6 addresses should be in the form of those standards. Your records contain a IPv6 that is either malformed or out of the range of the IPv6 standard. Most common issue is a typo in the record.

What can I do to resolve this:
Validate all IPv6 records and correct any malformed IPv6 address in your record with the correct address.

Official IETF RFC 2460 text:
https://tools.ietf.org/html/rfc2460
Wikipedia:
https://en.wikipedia.org/wiki/IPv6

Issue 6: The SPF record does not contain a “EXP” Modifier

Explanation in plain words:
When ever a 3rd party or your own employees experience issues with sending email on behalf of your domain they might not have any clue about where to raise concerns. Especially for 3rd party`s it can take days to find the proper contact.
To mitigate the time of impact and streamline the process for a email administrative department it is wise to add a explanation with whom to contact in case of a SPF failure. this will speed up remediation. EXP records are only honored on the root SPF record and not in includes. If a redirect is encountered the redirected EXP will be honored.

What can I do to resolve this:
Add the “EXP” modifier to your text record and point it to the “TXT” record containing the correct procedure / contact point. This way any sender that sends mail on your behalf can contact you directly when facing issues.

Official IETF RFC 2460 text: 

If check_host() results in a “fail” due to a mechanism match (such as “-all”), and the “exp” modifier is present, then the explanation string returned is computed as described below. If no “exp” modifier is present, then either a default explanation string or an empty explanation string MUST be returned to the calling application.

The <domain-spec> is macro expanded (see Section 7) and becomes the <target-name>. The DNS TXT RRset for the <target-name> is fetched. If there are any DNS processing errors (any RCODE other than 0), or if no records are returned, or if more than one record is returned, or if there are syntax errors in the explanation string, then proceed as if no “exp” modifier was given.

The fetched TXT record’s strings are concatenated with no spaces, and then treated as an explain-string, which is macro-expanded. This final result is the explanation string. Implementations MAY limit the length of the resulting explanation string to allow for other protocol constraints and/or reasonable processing limits. Since the explanation string is intended for an SMTP response and Section 2.4 of [RFC5321] says that responses are in [US-ASCII], the explanation string MUST be limited to [US-ASCII]. 

Software evaluating check_host() can use this string to communicate information from the publishing domain in the form of a short message or URL. Software SHOULD make it clear that the explanation string comes from a third party. For example, it can prepend the macro string “%{o} explains: ” to the explanation, as shown in the example in Section 8.4.Suppose example.com has this record:v=spf1 mx -all exp=explain._spf.%{d}Here are some examples of possible explanation TXT records at explain._spf.example.com:”Mail from example.com should only be sent by its own servers.”– a simple, constant message”%{i} is not one of %{d}’s designated mail servers.”– a message with a little more information, including the IP address that failed the check”See http://%{d}/why.html?s=%{S}&i=%{I}”– a complicated example that constructs a URL with the arguments to check_host() so that a web page can be generated with detailed, custom instructions.

Note: During recursion into an “include” mechanism, an “exp” modifier from the <target-name> MUST NOT be used. In contrast, when executing a “redirect” modifier, an “exp” modifier from the original domain MUST NOT be used. This is because “include” is meant to cross administrative boundaries and the explanation provided should be the one from the receiving ADMD, while “redirect” is meant to operate as a tool to consolidate policy records within an ADMD so the redirected explanation is the one that ought to have priority.

Issue 7a: Incorrect use of the “+all” mechanism

Explanation in plain words:
The most powerful mechanism that can be used in SPF is the “+all” as it has the option to validate multiple statements. “+all” should only be used  when you want to validate multiple mechanisms. Your record is currently using less than 2 mechanisms.

What can I do to resolve this:
Switch your mechanism to “-all” if this is a empty domain with no MTA`s sending email. 
Switch to “-all” and revert your current mechanism to produce a “+” verdict on a positive match instead of on a negative match.

Official IETF RFC 7208 text:
Say that your sender policy requires both that the IP address is within a certain range and that the reverse DNS for the IP matches. This can be done several ways, including the following:

  • example.com.  SPF 
    • (“v=spf1 “
    • “-include:ip4._spf.%{d}”
    • “-include:ptr._spf.%{d} “
    • “+all” )
  • ip4._spf.example.com.  SPF  “v=spf1 -ip4:192.0.2.0/24 +all”
  • ptr._spf.example.com.  SPF  “v=spf1 -ptr +all”

This example shows how the “-include” mechanism can be useful, how an
SPF record that ends in “+all” can be very restrictive, and the use
of De Morgan’s Law.

Issue 7b: The “all” mechanism does not have a “-” quantifier

Explanation in plain words:
The “all” mechanism does not have a qualifier of “-“. This means that your SPF record is not set to advise a drop of all non authorized servers. This is ok if you are still testing your systems but you should work towards a “-all” implementation.

What can I do to resolve this:
Work on a DMARC project using tools from either this site or a 3rd party to test your domains mail flow. DMARC can help you gain insight in who sends on your behalf. Slowly work towards a SPF record where you only authorize servers you trust.

Official IETF RFC 7208 text:
None, This is a best practice.

Issue 8: Office 365 or a high volume server are not at the start of your SPF record

Explanation in plain words:
As a SPF record is being evaluated from left to right you can optimize it by defining your highest volume server first. In doing so you save the hole world some CPU power and DNS lookups due to the most mail is directly gaining a SPF verdict without having to process the entire record.

What can I do to resolve this:
Reorder your SPF record in sequence from highest volume to lowest volume.

Official IETF RFC 7208 text:
Each mechanism is considered in turn from left to right. If there are no more mechanisms, the result is the default result as described in Section 4.7. 
When a mechanism is evaluated, one of three things can happen: it can match, not match, or return an exception. If it matches, processing ends and the qualifier value is returned as the result of that record. If it does not match, processing continues with the next mechanism. If it returns an exception, mechanism processing ends and the exception value is returned.

Issue 9: No EXP modifier exists in your SPF record

Explanation in plain words:
Whenever you are masking your allowed recipients or servers using SPF “exist” mechanism query`s your are stressing out DNS and MTA compute capacity. Exist should only be used if you have very special multiple verification needs or want to utilize macro capabilities to allow specific users / servers to have a SPF override. Using exist is usually less secure than the other mechanisms available.

What can I do to resolve this:
If you are not aware of all risks of using “exist” mechanism it is better to switch to the other mechanisms als “IP4” and remove the exists out of your SPF record or move users and servers that need this functionality to a sub domain.

See part 2 of the antispam counter measures explained of my blogpost series for more information.

Official IETF RFC 7208 text:
This mechanism is used to construct an arbitrary domain name that is used for a DNS A record query.  It allows for complicated schemes involving arbitrary parts of the mail envelope to determine what is permitted. The <domain-spec> is expanded as per Section 7.  The resulting domain name is used for a DNS A RR lookup (even when the connection type is IPv6).  If any A record is returned, this mechanism matches. Domains can use this mechanism to specify arbitrarily complex queries.  For example, suppose example.com publishes the record:

      v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all

The <target-name> might expand to “1.2.0.192.someuser._spf.example.com”. This makes fine-grained decisions possible at the level of the user and client IP address.

Issue 10: The Query size of the TXT record exceeds the recommend size 

Explanation in plain words:
In the original RFC`s for DNS the limitation was to have a 512 bit UDP network packed. Although there have been extensions and transfers to Tcp this is not supported by all DNS servers. If your TXT record ( All records in the zone of type TXT, not only SPF ) is longer than 450 octets it might start causing issues in DNS servers that don`t support any of the extensions. in this case the SPF verdict might result in a perm error causing MTA`s to drop your mail.

What can I do to resolve this:
There are multiple things you can do to reduce the size of the TXT records in your domain. Start by removing any unnecessary TXT record.
If you use a lot of mechanisms in your record you could consider to use includes and move some of the mechanisms to a other domain.
If you space is really limited due to other verification records you can create a redirect modifier redirecting your SPF record to a dedicated sub domain for example:
yourdomain.nl ->
         V=spf1 redirect=_SPF.yourdomain.nl
_SPF.yourdomain.nl ->
         V=spf1 ipv4:123.123.123.123 -all EXP=exp.yourdomain.nl
exp.yourdomain.nl ->
         Please contact +1234567 for assistance with failing SPF records.

Official IETF RFC 7208 text:
The published SPF record for a given domain name SHOULD remain small enough that the results of a query for it will fit within 512 octets. Otherwise, there is a possibility of exceeding a DNS protocol limit. This UDP limit is defined in [RFC1035], Section 2.3.4, although it was raised by [RFC2671]. Staying below 512 octets ought to prevent older DNS implementations from failing over to TCP and will work with UDP in the absence of EDNS0 [RFC6891] support.

Since the answer size is dependent on many things outside the scope of this document, it is only possible to give this guideline: If the size of the DNS message, the combined length of the DNS name and the text of all the records of a given type is under 450 octets, then DNS answers ought to fit in UDP packets.

Records that are too long to fit in a single UDP packet could be silently ignored by SPF verifiers due to firewall and other issues that interfere with the operation of DNS over TCP or using ENDS0.Note that when computing the sizes for replies to queries of the TXT format, one has to take into account any other TXT records published at the domain name. Similarly, the sizes for replies to all queries related to SPF have to be evaluated to fit in a single 512-octet UDP packet (i.e., DNS message size limited to 450 octets).

Issue 11: Subdomains are not protected from spoofing

Explanation in plain words:
Sub domain spoofing is becoming rapidly more popular than ever before. While most company`s are now starting to protect their domains with SPF and DMARC, they forget or don`t bother to register the record for their subdomains. This way a spoofer can easily abuse the subdomain to still gain trust with the targeted victim. Although originally it was not a best practice to register these wildcard domains do to the high overhead workload, this is now your only way to protect your sub domains effectively.

What can I do to resolve this:
Create a wildcard SPF record for every domain that you own stating only the SPF “-all” mechanism. If you have subdomain you will also need to create a wildcard record for each of those sub domains and their child domains.

Example for domain tech-savvy.nl:
Registerd domains A records:

tech-savvy.nl -> TXT -> V=spf1 IP4:156.78.99.10 -all exp=exp.tech-savvy.nl
www.tech-savvy.nl-> TXT -> V=spf1 IP4:156.78.99.10 -all exp=exp.tech-savvy.nl
analyser.tech-savvy.nl-> TXT -> V=spf1 IP4:156.78.99.10 -all exp=exp.tech-savvy.nl
test.analyzer.tech-savvy.nl -> TXT -> V=spf1 IP4:156.78.99.10 -all exp=exp.tech-savvy.nl

To protect the domain and all sub domains in this zone we need the following records:

*.tech-savvy.nl  -> TXT ->  V=spf1 -all exp=exp.tech-savvy.nl
*.www.tech-savvy.nl  -> TXT ->  V=spf1 -all exp=exp.tech-savvy.nl
*.analyzer.tech-savvy.nl  ->  TXT -> V=spf1 -all exp=exp.tech-savvy.nl
*.test.analyzer.tech-savvy.nl  ->  TXT -> V=spf1 -all exp=exp.tech-savvy.nl

It is in the best practice to have a procedure in place at the DNS registration team to create a wildcard SPF drop for each domain they register. This way sub domain spoofing is no longer possible.

Official IETF RFC 7208 text: (Note this text is written from before subdomain abuse was a hot item)

Use of wildcard records for publishing is discouraged, and care has to be taken if they are used.  If a zone includes wildcard MX records, it might want to publish wildcard declarations, subject to the same requirements and problems.  In particular, the declaration MUST be repeated for any host that has any RR records at all, and for subdomains thereof.  Consider the example in [RFC1034], Section 4.3.3.  Based on that, we can do the  following:

EXAMPLE.COM. MX10A.EXAMPLE.COM
EXAMPLE.COM. TXT  “v=spf1 a:A.EXAMPLE.COM -all”*.EXAMPLE.COM.  MX10A.EXAMPLE.COM
*.EXAMPLE.COM.  TXT  “v=spf1 a:A.EXAMPLE.COM -all”A.EXAMPLE.COM.  A 203.0.113.1
A.EXAMPLE.COM.  MX10A.EXAMPLE.COM
A.EXAMPLE.COM.  TXT  “v=spf1 a:A.EXAMPLE.COM -all”*.A.EXAMPLE.COM.MX10A.EXAMPLE.COM
*.A.EXAMPLE.COM.TXT  “v=spf1 a:A.EXAMPLE.COM -all”

SPF records have to be listed twice for every name within the zone: once for the name, and once with a wildcard to cover the tree under the name, in order to cover all domains in use in outgoing mail.

TLS Analyzer:

The following list of issues describe all possible issues found by the TLS analyzer. This analyzer could be run as part of the full suite analyzer or via the individual TLS analyzer.

Issue 1: TLS Fallback SCSV is not supported

Risk assessment:
Low if SSL3.0 is disabled 
High if SSL3.0 is not disabled

Explanation in plain words:
Whenever a client ( sending MTA ) connects to a server (receiving MTA) and uses a TLS protocol to secure the connection, the client either directly connects at it`s set protocol version ( old client ) or tries to negotiate the highest possible security protocol ( new client). In all modern clients RFC 7507 should have been implemented. This means that whenever the client is advertising its capability`s or it Is forced on a lower than capable connection protocol it will send the TLS Fallback SCSV flag in the hello message. Whenever a server detects this flag and the client protocol is lower the servers highest security protocol the server will disconnect the session because a higher protocol level is available and should be used bij the client.

Currently most servers have disabled SSL3.0 due to weakness in the protocol, but TLS version 1.0 is still very common. As TLS 1.0 has a few known security vulnerability`s this means that TLS Faalback SCSV support can prevent a attacker from forcing the connection from TLS 1.2 ( with no currently known security breaches ) back to a TLS 1.0 version and abusing the current known breaches.

What can I do to resolve this:
Investigate if your edge MTA has support to enable  TLS fallback scsv support. If it is supported you could enable this functionality. Contact your vendor of your edge MTA to see if this can be enabled as this is not supported in al OS systems.

Additional reading:
IETF RFC 7507

Issue 2: Use Secure renegotiation

Risk assessment:
High

Explanation in plain words:
Secure renegotiation is a TLS renegotiation extension that prevents a data injection vulnerability. A hacker can perform a Man in the middle on a connection between 2 servers. He will than first inject his own data onto the conversation and than proxy the sending servers handshake to the target server. The target server believes that the data send by the hacker is actually coming from the original sender and accepts the data and the TLS handshake from the original sender and processes both client and hacker data as if it was send from the client. 

What can I do to resolve this:
When using OpenSSL you should upgrade to a version higher than 0.98l and enable secure renegotiation. For Microsoft products see MS10-049. any other OS or TLS implementation see CVE 2009 3555 that mentions fixes for a lot of OS and vendor based products.

Additional reading:
IETF RFC 5746
MS10-049
CVE 2009 3555

Issue 3: TLS compression is supported

Risk assessment:
Very low

Explanation in plain words:

At the moment of this writing there is no known exploit in use that abuses TLS compression support on the SMTP protocol. General discussions among security specialists agree that disabling compression is a good thing to do even for SMTP. Note that before the “CRIME” attack became know there was also no known exploit in use that abused TLS compression for TLS. Just because someone did not yet use it or found a case for it doesn`t mean someone else might. The scenario here is that a attacker could repeat multiple mails that where send and make minor adjustments to compare the differences in compression size to guess the content of a mail. A Possible secret that could be extracted or targeted would be a unauthenticated http link secret. These links are often used in unsubscribe links, Password reset links, fileshare links or calendar links , etc.  Although hopefully most of them are additionally secured with strong authentication, but if not this could be the entrance into a network especially if the secret is a password reset link that can be broken with social enginering. As the targeted user will see all attack mails the risk of this is assessed at very low.

What can I do to resolve this:
Investigate if your edge MTA has support to disable TLS compression. If it is supported you could disable this functionality. Contact your vendor of your edge MTA to see if this can be disabled as this is not supported in al OS systems.

Additional reading:
IETF RFC 3749
About the CRIME attack used in HTTP

Issue 4: No protection from TLS Heartbleed 

Risk assessment:
High

Explanation in plain words:
Whenever a malicious person sends a specially crafted command to a server accepting a TLS session it will exposes a small set of system memory in the response. This leaked data can contain anything from private keys to usernames and passwords. This is due to a faulty implementation of IETF RFC 6520 in OpenSSL version 1.0.1 / 1.0.1F. (versions 1.0.0 and lower are not affected)

What can I do to resolve this:
When you MTA or application uses OpenSSL you should upgrade it to a version higher than 1.0.1f or contact the manufacture for a updated version of the MTA or appliance. 

Additional reading:
CVE 2014 0160
IETF RFC 6520

Issue 5: Use of SSL protocols allowed for start TLS

Risk assessment:
Medium

Explanation in plain words:
Even though the biggest issues with SSL are based on web site hosted servers the security for use of the SSL protocol to encrypt short lived SMTP sessions is debatable. It is still a fact that there a number of issues found and still not fixed with the protocol. Due to these issues multiple vulnerability’s impact the security of the protocol that make use of the protocol inadvisable. This was already before the “POODLE” attack finally killed of the protocol as a safe protocol.

What can I do to resolve this:
If you MTA is windows based you can use the “IIS crypto” tool created by Nartac to change your protocol and cipher suites.
If you MTA is any other brand/OS contact your vendor to validate how to change the protocols used for TLS sessions. 

Additional reading:
OWASP Advisory
CVE 2014 3566
POODLE whitepaper by openssl


Leave a Reply

Your email address will not be published. Required fields are marked *