Spamming is an ongoing nuisance for mail server owners. It can mess up your mail servers and tamper with valid mail deliveries.

Server owners try to combat incoming spamming in various ways. Mail server tweaks and anti-spam software are some prominent ways of fighting spam.

As part of our Support Services, we help server owners protect their servers from both incoming and outbound spamming.

Today we’ll see what ‘Sender verification callouts’ mean and how they are relevant in the spamming context. We’ll also discuss the pros and cons of enabling it in mail servers.

What are Sender verification callouts? How do they help?

Sender callouts were introduced as a feature in the mail server to arrest inbound spamming. This technique is used to validate sender’s email addresses for incoming mails.

The logic behind this feature is that, most spammers would use spoofed email addresses to send mails. Looking up the sender address will help to confirm if the sender domain is a valid one or not.

When an email reaches your server, the sender address is obtained from the ‘MAIL FROM’ section. The validation of this address is done by issuing a ‘RCPT TO’ command to the sending mail server with this sender email address.

If the sending mail server acknowledges this command, then the receiver knows that the sending email address is valid. The email from the sender is then accepted by the receiver.

In cPanel/WHM servers, this ‘Sender verification callouts’ feature can be enabled for the Exim mail server from the WHM:

Enable sender verification callouts

But if the sender is unable to verify the email address or if the sender does not respond, the mail delivery will not be completed. Some error messages that you see then are:

"451 Could not complete sender verify callout"

                                        OR

"550 Sender verify failed"

Sender verification callouts – How they backfire!

The logic behind sender verify callouts is good. But in practical implementation, the process wasn’t much useful as it seemed.

In majority cases, this feature totally backfires and adversely affects your server. We’ll see the various issues we’ve noticed when sender verification is enabled.

1. Connectivity issues with sender mail server

Most mail servers have strict security rules in place to avoid unwanted connections. One such measure is blocking the default SMTP port 25 using firewall.

When port 25 is blocked, the recipient server cannot connect to the sender server and the callout process will fail. This leads to 451 email delivery failure errors.

If the sender’s server uses blacklists which delay the responses to Exim’s commands, that would also lead to failure in callout process and email errors.

2. Configuration issues in sending server

If the sender mail server is not compliant with RFC standard, the sender verify can fail. You will then see the error mesage “451 Could not complete sender verify callout”.

Many mail servers accept all addresses at ‘RCPT TO’, which gives an illusion that an invalid address is actually present in it. This fails the actual purpose of callout.

In some other sending servers, certain configuration settings in them can cause the callout request to get timed out. This can cause mails from valid senders to go undelivered.

3. Risk of getting blacklisted

Majority of spamming happens from spoofed email addresses. As a result, the sender verification callouts sent by your mail server reaches a different mail server than the one that actually sent the mails.

When the inbound spamming is high, these callout requests would also increase. This can cause your mail server to end up in blacklists due to too many connection attempts to other mail servers.

The main reason why callouts are no longer considered useful, is this risk of getting blacklisted. Once blacklisted, your server will not be able to send mails to valid email addresses.

4. Delays and overhead in your server

In sender callout process, there is more delay involved than usual mail delivery timing. This is because of the time involved in contacting the sender and verifying the address.

These delays can get further aggravated if the sender server uses slow anti-spam techniques such as ‘greet delays’ or greylisting.

With each callout, the overhead on both the sender and recipient mail servers is increasing. In cases of high inbound spamming, this overhead can turn cumulative and cause the server to crash.

A mail server that sends out too many callout requests can even simulate something like a distributed DOS attack. This will overload the entire network and adversely affect multiple servers.

Conclusion

Spamming can be tackled in various ways. Today we saw why ‘Sender verification callouts’ should be avoided for spam prevention. At Bobcares, our Support Engineers implement tried and tested solutions to effectively fight spam in customer servers.