Sendercallouts (Sender Address Verify) - What 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, attempt to connect to a remote server and try to send mail to this address to find out if such an address exists.
It looks very handy thing, especially if it is used after all other checks to reduce the load. It works very simply, our server receiving a connection from the server and reaching the RCTP stage TO: <our_user@domain.tld> opens the connection to example.com and tries to send a letter if, after the RCPT TO command: <someone@example.com>, the answer is 250 OK, our server closes the connection to the remote server and allows the transfer of the message body. And it works fine until you meet mailings from robots whose return addresses do not exist. This is resolved by the mandatory whitelisting support. In real life, everyone knows that the sender’s address can be faked. If a DDOS attack is made on your SMTP server, your server will start to check heaps of senders knocking remote servers with a large number of requests in the confusion and most likely you will be banned from them.
Worse when both servers are SAV and they are likely to fall into an infinite loop of checking their addresses. The first will send an email, the second will answer 451 Unverified and will try to connect to the first to which he will also answer 451 Unverified and so on to infinity. Of course, with a certain configuration, this can be avoided, but we don’t know what configuration the remote server has.
Therefore, there is a VRFY command for sender checks, which is described in RFC2821 . Previously, it was turned on almost everywhere, and spammers used it well to search for working emails using the dictionary method. 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 implemented the VRFY command, but it has no protection.
Suppose you can now do a bunch of checks in Postfix before we send a 250 OK to the RCTP TO: <user@example.com> command, but these restrictions cannot be used for the VRFY command, but of course it does not authenticate the sender. To authenticate the sender, you can now use DomainKeys Identified Mail .
It looks very handy thing, especially if it is used after all other checks to reduce the load. It works very simply, our server receiving a connection from the server and reaching the RCTP stage TO: <our_user@domain.tld> opens the connection to example.com and tries to send a letter if, after the RCPT TO command: <someone@example.com>, the answer is 250 OK, our server closes the connection to the remote server and allows the transfer of the message body. And it works fine until you meet mailings from robots whose return addresses do not exist. This is resolved by the mandatory whitelisting support. In real life, everyone knows that the sender’s address can be faked. If a DDOS attack is made on your SMTP server, your server will start to check heaps of senders knocking remote servers with a large number of requests in the confusion and most likely you will be banned from them.
Worse when both servers are SAV and they are likely to fall into an infinite loop of checking their addresses. The first will send an email, the second will answer 451 Unverified and will try to connect to the first to which he will also answer 451 Unverified and so on to infinity. Of course, with a certain configuration, this can be avoided, but we don’t know what configuration the remote server has.
Therefore, there is a VRFY command for sender checks, which is described in RFC2821 . Previously, it was turned on almost everywhere, and spammers used it well to search for working emails using the dictionary method. 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 implemented the VRFY command, but it has no protection.
Suppose you can now do a bunch of checks in Postfix before we send a 250 OK to the RCTP TO: <user@example.com> command, but these restrictions cannot be used for the VRFY command, but of course it does not authenticate the sender. To authenticate the sender, you can now use DomainKeys Identified Mail .
')
Source: https://habr.com/ru/post/45635/
All Articles