The Spamhaus Project

blog

On the dubious merits of email verification services

by The Spamhaus TeamApril 30, 20158 minutes reading time

Jump to

The Spamhaus Project view of these services

The Spamhaus Project view of these services

Over the past several years we have encountered several businesses offering email verification services. We have met them in industry social circles, sometimes they get tangled in our lists, and often we're asked by senders and receivers alike: "what does Spamhaus think of verification services?"

The idea of the verification service is to determine whether an email address exists, before it is used for transactional or bulk email. That helps avoid undeliverable messages which can trigger spam-blocking actions by the receiving system. It does nothing to verify the permission of the recipient to accept a subscription, which is the most important step in avoiding spam when acquiring addresses for bulk emailing lists, nor does it ensure that the email address owner is the same as the person making the transaction. That means that transactional mail like receipts, tickets or vouchers could be sent to the wrong person, yet the address won't bounce because it was verified to exist.

SMTP includes commands called "VRFY" and "EXPN" which do exactly what verification services offer. While those two functions are technically different, they both reveal to a third party whether email addresses exist in the server's userbase. Nearly every Postmaster (mail server administrator) on the Internet has turned off VRFY and EXPN due to abuse by spammers trying to harvest addresses, as well as a general security and privacy measure required by most network's operational policies. In fact, since about 1999 or before, all mail servers are installed with those off by default. That should give a clear indication to email verifiers about the opinion of Postmasters of the service they intend to offer. Doing verification against systems that have disabled those functions, whether successful or not, constitutes an attempted breach of the receiver's security policies and may be considered a hostile act by site administrators. Sending high volumes of verification probes without an attempt to actually send an email will often trigger filters or firewalls, thus invalidating the data and impairing future verification accuracy.

Listwashing and spamtrap washing services help spammers. They do not help list owners who have done proper opt-in acquisition and list maintenance, nor do they help mail receivers (including both Postmasters and mailbox owners) who rely on spamtrap data to keep spam off their servers and out of their mailboxes. These services might be of marginal help for point-of-sale typo'd addresses (but it won't catch many typo traps, despite tricks the verifiers use to detect those) or in the few edge cases of list owners who have not been as diligent as they should in address acquisition and list maintenance, but many of those cases need to take much stronger list hygiene measures than simply verifying the existence of addresses. (They need to remove bounces, non-responders and bad list segments and imports, and then do a permission pass over the remaining addresses, keeping only those whose owners subscribe to that offer.) Email verification services must operate with a strong policy which prohibits listwashing, trap washing and related spam support services, and which avoids clients who seek those services.

Considerations if attempting to offer a verification service

So, let's say that despite all the problems and objections to email verification as a business model, you decide to offer such a service. What are some things you should consider?

You need to properly identify your company, including your domain and your IP addresses. Your reputation is easier to build and stronger when it is based on a single domain and a single IP address, or a small and contiguous range of IP addresses. Using lots of domains and lots of IP addresses - like spammers do! - and not properly identifying your company in whois, PTR, SPF, DMARC and other network records is the mark of someone sneaking around... like spammers do! Poor reputation of your domains and IP addresses will get you blocked at many receivers, and possibly at Spamhaus.

If a Postmaster doesn't want you snooping around their server, possibly blocking or rate-limiting your domain or IP addresses, respect their choice and don't try and sneak around their blocks. Changing IP addresses or domains is sneaky and evasive. Evading such filters is spammy on the sender/verifier's part and will be seen as intentionally so, and larger, higher, stronger barriers put in place. You may wish to contact them, ask what's up and whether there's anything you can do to regain their trust, but do that honestly and forthrightly.

Do not offer listwashing and spamtrap removal services. If a customer asks about those, that should raise a big caution flag with you. Why do they need those things if they collected their mailing list properly and honestly in the first place?

Offer a true Confirmed Opt In (COI) service so that list owners not only verify that customer addresses exist, but also verify that the sender has each and every mailbox owner's permission to send it bulk email. This could relate to the "permission pass" method of list repair, as mentioned above and referenced below.

"Let me tell you about my business model..."

Some of the things we've heard from verifiers, and our response:

"Our clients must have their own dedicated setup and need separate domains and IP addresses due to their company policy or privacy reasons."

The context of that quote was the verifier's use of many domains and IPs, both poorly identified - nonsense domains, anonymized whois, generic or no rDNS, no IP address netblock SWiPs, etc. It looked like a typical snowshoe spammer setup.

ESP clients are often well-advised to use dedicated IP addresses and their own domains because they have their own branding with well-known domains and established reputations. Those dedicated domains and IP addresses should, of course, have proper network identification of the responsible party, and be static over time.

The branding and reputation factors are different for a verifier than for an ESP. It is simply not true that each verifier client needs its own separate domain and IP address. The verifier's email probe is essentially invisible as far as branding. No end-user ever sees any part of it. Only a Postmaster will notice the domain/IP in log files. The reputation attached to a probe connection is that of the verifier! Only by building their own good reputation will the verifier's probes have value. If they have low reputation, including unknown reputation, they may be blocked or temp-failed, neither of which helps the verifier deliver the product they sell.

There's an old joke in anti-spam circles that simply goes, "Let me tell you about my business model..." Period. It means that every spammer always has a reason that their business is special and doesn't need to follow good practices. Receivers don't care about your business model! They care about their servers, mailboxes and customers. Same here; it's your business and your reputation that you need to care about. Sure, you need to service your client's needs, but it's simply not true that they each need separate domains and IP addresses, and that does not scale in the reputation world. You need to establish your domain/IP address reputation. You need to explain to your customers that this is how it works, this is to their best advantage, this won't change their branding or perception to their customers, and this is how you do business.

"We are helping customers make sure that their end users are putting in the email addresses correctly so if the user accidentally mistypes their email address, they can correct it in real time. I will give you an example about this with one e-commerce customer. They called us and discussed with us the problem of bots creating fake signups and clogging their websites from multiple IP addresses throughout the world, over 20,000 signups a day. As soon as they put verification in place the fake signups stopped."

That is, indeed, an excellent example of why we do not flat-out say that verification is wrong. By stopping the bot attack, it stops the sender's attempts to deliver unwanted or undeliverable mail. Of course, it still does not confer the address owner's permission when their address does verify. That's where the sender needs COI, especially when acquiring addresses for on-going list email. But we do recognize that verification can have a role in a healthy email system. Real-time point-of-sale verification is another example which helps for single transactional email.

"But we don't send mail at all!"

Balderdash! We understand that you don't complete the SMTP dialog with "/r/n./r/n" and "250 OK," or maybe you don't even go to DATA. You do use SMTP, and you even use it to circumvent disabled VRFY or EXPN services. You extract information about a Postmaster's users which may be against their terms of service. You fill up their mail server's ports and logs with your connections. No, you don't put spam messages in end-user or spamtrap boxes (although bad actors doing verification for bad lists may result in increased user-received spam), but it's not honest to say you don't mail.


References and further reading:

https://tools.ietf.org/html/rfc2505 - Anti-Spam Recommendations for SMTP MTAs, February 1999

http://www.spamresource.com/2007/01/whatever-happened-to-vrfy.html - Whatever happened to VRFY?, January 2007

https://www.spamhaus.org/resource-hub/deliverability/permission-pass-what-how-and-when-to-use - Permission Pass

https://www.spamhaus.org/resource-hub/deliverability/confirmed-opt-in-a-rose-by-any-name - Confirmed Opt In: A Rose by Any Name, August 2008

https://www.spamhaus.org/news/article/734?article=734 Subscription Bombing: COI, CAPTCHA, and the Next Generation of Mail Bombs, September 2016 snowshoe spamming