Issue
I'm currently trying to write a simple Spring email verification microservice. I'm using Apache SMTPClient API to connect to an SMTP server and verify the email address existence (connect -> login -> setSender -> setRecipient -> logout -> disconnect). When connecting to most big email providers (gmail, yahoo, etc.) there are no issues, but for others there's a bizarre 5-20s delay when connecting. For example, with protonmail I sometimes wait for what looks like a fixed 5s delay, sometimes I connect normally after ~150ms. With some other, smaller services it's a fixed delay every time I try to connect. Since I'm doing my best to reduce the time required for such verification, this is a pretty massive issue, given it generally takes <2s when no such issues are encountered.
I was trying to find a reason for this delay, and I encountered 2 potential explanations:
- tarpitting - while the delay it causes fits the issue, I am sending a singular connection request, while the mechanism is supposed to prevent spam/bulk emails,
- being blacklisted - that also could be the cause, but in general that information is put into a (negative) reply to one of the SMTP commands I send.
I would appreciate any suggestions on what could be causing the delay and how to avoid it (if it's even possible).
Solution
I made a couple of SMTP connections to mail.protonmail.ch, and it is definitely doing some things that are unusual. I think they're implementing a variation of tarpitting.
For instance, sometimes after the connecting, mail.protonmail.ch immediately responds with an SMTP banner (that looks very much like a 220 response):
220-mailin008.protonmail.ch ESMTP Postfix
then, after a seemingly random delay, an actual 220 response:
220 mailin008.protonmail.ch ESMTP Postfix
Other times, after a seemingly random delay, it responds with a 220 response without sending a banner first:
220 mailin025.protonmail.ch ESMTP Postfix
Many client SMTP programs that are used to send spam do not implement SMTP properly. A shoddy program might 'get fooled' by the unusual way that mail.protonmail.ch responds, and send EHLO before it should. Then, mail.protonmail.ch can drop the connection, on the assumption that the client is not a 'real' SMTP MTA. A real MTA, however, would wait for the 'real' 220 response, before sending EHLO.
Answered By - mti2935
