Sendercallouts (Sender Address Verify) - Why This Is Bad
Most current MTAs have the ability to use Sendercallouts - this is when they connect to your SMTP server, and you check the sender address specified during the SMTP session by trying to connect to a remote server and try to send mail to this address to find out if such an address exists.
It looks like a very convenient thing, especially if you apply it after all other checks to reduce the load. It works very simply our server receiving a connection from the server and reaching the RCTP TO stage: opens a connection to example.com and tries to send an email if after the RCPT TO command:the answer is 250 OK, our server closes the connection to the remote server and allows the transmission of the message body. And this works fine until you see mailings from robots that do not have return addresses. This is solved by the obligatory support of whitelisting. In real life, everyone knows that the sender address can be faked. If a DDOS attack is made on your SMTP server, your server will begin to check the heaps of knock senders on remote servers with a large number of requests in the turmoil and most likely you will be banned for them.
It’s worse when both servers have SAVs and they are likely to fall into an endless loop of checking their addresses. The first one will send an email, the second one will respond 451 Unverified and try to connect to the first one to which it will also respond 451 Unverified to it and so on ad infinitum. Of course, with a certain configuration this can be avoided, but we don’t know what configuration the remote server has.
Therefore, for sender checks, there is a VRFY command, which is described in RFC2821. Previously, it was turned on almost everywhere and spammers used it well to search for working emails by brute force using a dictionary. Then they began to turn it off everywhere in order to reduce the flow of spam to existing addresses, and as a result, after 10k years, they again tried to return to it using SAV. Almost all MTAs have a VRFY team, but it has no protection.
Let's say now in Postfix you can do a bunch of checks before we send 250 OK to the RCTP TO command:, but these restrictions cannot be used for a VRFY command, but of course it does not authenticate the sender. You can now use DomainKeys Identified Mail to authenticate the sender .
It looks like a very convenient thing, especially if you apply it after all other checks to reduce the load. It works very simply our server receiving a connection from the server and reaching the RCTP TO stage:
It’s worse when both servers have SAVs and they are likely to fall into an endless loop of checking their addresses. The first one will send an email, the second one will respond 451 Unverified and try to connect to the first one to which it will also respond 451 Unverified to it and so on ad infinitum. Of course, with a certain configuration this can be avoided, but we don’t know what configuration the remote server has.
Therefore, for sender checks, there is a VRFY command, which is described in RFC2821. Previously, it was turned on almost everywhere and spammers used it well to search for working emails by brute force using a dictionary. Then they began to turn it off everywhere in order to reduce the flow of spam to existing addresses, and as a result, after 10k years, they again tried to return to it using SAV. Almost all MTAs have a VRFY team, but it has no protection.
Let's say now in Postfix you can do a bunch of checks before we send 250 OK to the RCTP TO command: