Some weeks ago I read a good blog on callback verification. I totally agree with the author on this topic – it is a pathetic technique for preventing spam.

Old-timers will remember the SMTP VRFY command. For those that are not aware of this let me quote from the RFC¹.

This command asks the receiver to confirm that the argument identifies a user or mailbox. If it is a user name, information is returned as specified in section 3.5.

Due to security issues – mostly spam related – this command is no longer fully support in any self-respecting mail configuration. Instead a strictly RFC-compliant MTAs will typically respond with

252 Cannot VRFY user, but will accept message and attempt delivery

Callback verification is just VRFY in different clothing. An attempt is made to verify the sender by connecting back to one of the MX hosts of the sending domain. Instead of a VRFY, a RCPT TO is sent with the senders email address to see how the MTA responds. For the same reasons as the VRFY command, RCPT TO will default to returning a 250 response more often than not. The end result is wasted bandwidth, increased SMTP response times, and the potential to be blacklisted, as too many callbacks may appear as a directory harvest attempt. In a worst case if this verification is used on a continual basis your MTA might even be blacklisted, because it could be deemed directory harvesting. We threw VRFY away a long time ago, let’s not fake it up under another schema.

All is not in vain; continuing on my theme of simple and practical techniques to keeping spam out of the network, let’s analyse the sender domain:

(1) Do a deliverability check: Does it have an MX record? If not, can it resolve back to an A-record or an AAAA-record?². Unless you have some local routing routes that will handle the domain delivery don’t accept it. If a SERVFAIL is encountered, return a 418 code. This is not a foolproof method. Even if proper DNS records exist none of the listed servers might actually host a SMTP server. Whatever you do, DO NOT connect back in an attempt to check this!

(2) Do the SPF-check: Yes, yes, I keep hammering on about SPF, but it is a vital, even though potentially temporary, link in fighting spammers. If more people set SPF records³, we can temporarily defeat spammers at MAIL FROM. SPF is a community effort not a vendor security effort. Everyone in the community has to take part for this to work.
Now before all you anti-SPF’ers come thundering down on me, have a look at this random subset of badly-reputed domains from our Domain Reputation Database. Some of us at Avert Labs monitor the reputations of domains closely and keep quantitive data to repute behaviour of domains at any point in time. I took this sample and performed some simple DNS analysis on them, specifically looking for the following data:

• Promiscuous SPF are SPF records that contain +all in the record. That is in total contradiction to the intent of SPF is and is a nearly carte blanche indication that this domain is purely intended to be used for spam.
• Suspect softfail SPF records are those containing ~all. This is typically used for a transition period, but in many cases this is just to fake MTAs into believing that the sending IP is good. Although not as bad as +all, these kind of records should always be treated as suspect. Unless you have very good reason for still using ~all at this point in your own domains, it is time you switch to -all.
• Netblocks in SPF: A number of SPF records do not fall in the above two categories, but they do contain large netblocks. I consider this to be suspicious in many cases. A /24 block indicates that a domain allows email to originate from 253 different IPv4 addresses! I have noticed that some people do this because they are on dynamic IPs and would like to send email from their own servers. But why do this and not route through the ISP? A little include section in the SPF record will solve that issue. More worrying is that this might be a botnet owner / spammer who might use a specific subnet to send spam originating from a specific domain. There are those people who put /8 in the SPF records. Humour me! How much different is that from +all?
• Mail records: Some domains list MX records, but none of those resolve to a A/AAAA record. Others have no MX or A/AAAA records at all. These domains are not allowed to send email and an inbound MTA should not accept email from such domains.

Sample of Bad Domains Tested    42181
Promiscuous SPF                 3.24%
Suspect softfail SPF           10.55%
SPF records no +all or ~all    23.68%
SPF records netblocks /24+     13.42%
SPF records netblocks /8        0.42%
SPF good                        9.83%
Bad DNS records                11.74%
No MX resolves                  0.68%
No MX, no fallback A/AAAA      22.29%

I then took a 1h sample from just one of our traps looking for the bad domains in the MAIL FROM command⁵:

Sample of Bad Domains Tested       367 (0.87%)
Promiscuous SPF                   2.18%
Suspect softfail SPF             36.24%
SPF records no +all or ~all      26.70%
SPF records netblocks /24+       13.62%
SPF records netblocks /8          0.27%
SPF good                         12.81%
Bad DNS records                   0.27%
No MX resolves                    1.63%
No MX, no fallback A/AAAA         3.54%

There are two main conclusions that we may draw from this:

• A large number of badly reputed domains – ~33.5% – had faulty mail records.⁶ In our mail sample we saw only 5.5% actually being used.
• Roughly 16% of SPF records could be detected as promiscuous (if netblocks are checked as well). This means it is possible to stop a spammer that registers promiscuous SPF records and allow real, decent, SPF-qualified domains.

As a last test I checked the 1h sample again, but this time only looked at a sample of domains used in the MAIL FROM command that could be considered to be good domains and domains of unknown reputation:

Sample of Domains Tested         58930
Promiscuous SPF                   0.17%
Suspect softfail SPF              4.18%
SPF records no +all or ~all      12.46%
SPF records netblocks /24+        5.28%
SPF records netblocks /8          0.003%
SPF good                          7.18%
Bad DNS records                   0.28%
No MX resolves                    0.50%
No MX, no fallback A/AAAA         1.58%

In this case only ~7.81% had bad mail records or SPF records of a dubious nature. This could mean that these domains were badly configured or that we, at Avert Labs, simply have not analysed those domains at the time that I took my sample. Eliminating these from the sample we end up with 7.18% having good SPF records and the rest ~85% not having any SPF records. As sad as it may be, I can deduce from this that 85% of domains are getting joe-jobbed, because they have not SPF records!

The case of the null-sender

Obviously when MAIL FROM: is used, DNS queries cannot be used. This is a favourite technique with some spammers to work around the DNS checking problem. This has led to some customers even asking whether the null-sender can be balnket banned. A knee-jerk approach to such a problem is not going to solve anything. RFC4408⁷ recommends that for such cases the EHLO/HELO string is used. A conforming MTA will send the name of the mail server (or IP address in square brackets) as part of this SMTP command string. Using EHLO strings is not a foolproof technique, but it has its merits.

Conclusion:

There are a couple of important points that can be taken away from this analysis

• There is a small benefit top be gained in validating the sender domain.
• Validating delivery is the first check-point at MAIL FROM.
• SPF-checking is a second check at MAIL FROM
• More people should create SPF-records.
• Spammers do not create that many SPF-records for their domains. For those that do patterns are emerging which can be used as means of detection

In the future a way to get around the SPF problem for spammers is to create SPF records for their own spamming domains. Since we can easilty detect this, tyhey might to resort to more clever techniques like fast morphing DNS techniques where the ip4 entries in the SPF record changes the whole time. We can already detect that kind of behaviour as well. At this level it gets very hard for poor admin to just use off-the-shelve techniques and requires the use of a security service provider. This really brings us to the concept of applying full Domain Reputation at the point of MAIL FROM. Instead of an MTA doing all of the appropriate DNS queries for every connection, maybe it should just ask McAfee for the reputation of that domain …

---

¹ RFC2821 Section 4.1.1.6² RFC2821 Section 5 only refers to A-records as fallbacks, but I think we can infer IPv6 support here as well.³ I cannot stress enough, that if enough people do not take up SPF, then using it as a more effective means to prevent spam entering the network will not work. A good place to start understanding SPF is reading the OpenSPF site. Be sure to read the section on common mistakes.⁴ Any decent examples to the contrary most welcome.⁵ The 0.87% might seem small, but in my analysis I did not check for any correlation between the age of the domain and the time of my 1h sample. Neither did I use the full reputation database. There is a good chance that a number of domains were not picked up in my 1h sample, due to this. That is my exercise for another day. It is more important to look at the relative percentages within 1h sample and compare them the overall percentages of the greater sample.

⁶ The figure applies to percentage of domains not the percentage of email. It cannot be inferred that 33.5% of email can be blocked in this way.

⁷ RFC4408 is experimental.