Disable 'sender verify callout' or not?

[babakb]

I've had more than one complaint from customers who are missing e-mails from senders with invalid reply-to addresses. I know we can create a white list but I wish there was a way we could give the users control over the white list. Or maybe even disable this security measure for a specific customer account altogether if they request this. If anyone knows of a way to implement either solution please let me know.

Otherwise I have to make a decision as to whether to disable this feature altogether. I'm curious as to how much SPAM increase one can expect after turning off 'sender verify callout'? Also will disabling it have a significantly positive effect on the server load? That would be a good thing at least.

Thanks.

[lloyd_tennison]

Since the standard is to use sender verify, rest assured that your clients are not the only ones not getting the person's emails. Since it is very difficult to accidentally mis-configure and email client to have it not work, education is more the answer.

I "lose" as many as 5 million messages a week with bad addresses. Just by looking at then sender can tell they are spam...

[sparek-3]

I have been a big advocate of using sender callouts. Using sender callouts will stop a lot of spam before it gets processed by your server. This will just stop a lot of unnecessary exim processing as well as any SpamAssassin processing on those messages (I don't have an exact figure, but I would say a vast majority of all messages that fail a sender callout are spam messages, so why should you even bother checking them with SpamAssassin?)

Usually legitimate cases where sender callouts cause a valid message to be rejected happen because of one of two reasons.

The first reason being that a mail server that is handling mail for a failed callout domain is not properly accepting mail from the null sender. This is actually pretty cut and try. The folks at RFC-Ignorant.org have highlighted:

http://rfc-ignorant.com/rfcs/rfc1123.php#section5.2.9

Basically this RFC says that if you are running a mail server then that mail server has to accept mail from the null sender. The null sender is what exim will use in its callout routine to verify the existence of a recipient. I actually had a client claim that a server that was trying to send mail to them could not accept mail from the null sender. If you are following RFCs then RFC1123 says that you have to accept mail from the null sender, there's no case for can't, couldn't, or shouldn't. If mail servers are allowed to be run throughout the Internet and just ignore any standard that they see fit, then really what's the point of having standards? Standards are created so that servers can communicate with one another.

The second reason being that some mail senders believe in sending out e-mail from an address that does not actually exist or does not accept mail back. Unfortunately in this case, I'm not aware of anything that says this is wrong from a standards point of view. However, in my opinion it lacks common sense. I know a lot of larger companies may want to send out newsletters and commonly they will add a line of text "Don't reply to this message your message will go nowhere". They accomplish this by using an e-mail address like noreply@largecompany.com and then they don't have noreply@largecompany.com set up as a mail account on their servers (this would be analogous to largecompany.com having their default box set to :fail: and not having noreply@largecompany.com set up). While technically, there's nothing wrong with this set up, to me its just bad judgment. I understand that companies don't want to read the mail that is sent to noreply@largecompany.com, but you need to at least accept mail for that address, just to prove that it is a real address. What you do with the message after you receive it is completely up the administrator. If they want to automatically delete messages sent to noreply@largecompany.com after they are accepted, that is fine by me.

I outlined this in a little bit more detail at:

http://spareknet.org/articles/callouts.php

So basically it is up to you. Again, I don't have any figures, I'm just making some guestimations, but I would guess that 9 out of every 10 messages your mail server receives that fail a sender callout are spam messages. This may actually be a lot higher. But if 90% of failed sender callout messages are spam, is it really worth the extra utilization and extra spamassassin load and all of your users receiving more spam, just to satisfy that 10%? If those 10% would follow the above, one of which is an RFC standard and the other just makes sense, then this entire problem could be alleviated.

Again, this is just my views on the subject. If you agree with that 90/10 estimation, then that 10% may be worth it for you. It just depends on your opinions on the subject. I'm just trying to give you information as to why I have the views that I do, and maybe it will help you come to a conclusion.

[Website Rob]

Personal experience taught me it was better to have 'Sender verify callout' disabled. There is no noticable difference on Server load, one way or the other.

Using 'Verify the existence of email senders.' works very well and should always be used.


It was from Client compliants that made our decision to not use 'verify callout'. Too many Companies are providing Hosting accounts on one Server and eMail sendout on another. That causes most eMail addresses to fail for 'verify callout'.

[simonpearce]

Personal experience taught me it was better to have 'Sender verify callout' disabled. There is no noticable difference on Server load, one way or the other.

Using 'Verify the existence of email senders.' works very well and should always be used.

What's the technical difference between these two?

It was from Client compliants that made our decision to not use 'verify callout'. Too many Companies are providing Hosting accounts on one Server and eMail sendout on another. That causes most eMail addresses to fail for 'verify callout'.

Ditto - even mail from Google is being rejected

[Website Rob]

Sender verify callout
- Server the eMail was sent from is checked

Verify the existence of email senders
- eMail is checked for validity regardless of where it is sent from

[rvskin]

Sender verify callout
- Server the eMail was sent from is checked

Verify the existence of email senders
- eMail is checked for validity regardless of where it is sent from

I think this statement is incorrect. I am not 100% sure but from my knowledge. By both means it is no matter where is the email come from. It is not necessary to send from the same server as MX record.

'Verify the existence of email senders' is a validation by lookup if there is a valid MX record for the sender email address. That's it.

'Sender verify callout' is the validation by sending SMTP request to the MX record of the sender email. SMTP request sent by NULL address <> (sparek-3 already explain it above post) which some of the server out there block it. This is the real pain as the sender verification will be failed. I have posted several times the EXIM ACL to use Sender verify callout with the lowest problem. I will post here again.

First in create the whiletist files at the first box of EXIM advanced editor.

domainlist rv_callout_sender_domain_whitelist = lsearch;/usr/local/cpanel/base/eximacl/rv_callout_sender_domain_whitelist
domainlist rv_callout_receiver_domain_whitelist = lsearch;/usr/local/cpanel/base/eximacl/rv_callout_receiver_domain_whitelist

Then for the verify = sender/callout amd change it to.

##
# Callout (create SMTP connection to test the sender address
# Deny unless the sender address can be verified.
# Testing only the sender that not listed in the callout whitelist and dsn.rfc-ignorant.org
##
deny message = From email address must be valid
      # do not check address for lists or bounces
      # or people in our company contact database
      !senders = ^.*-request@.*:\
                ^bounce-.*@.*:\
                ^.*-bounce@.*:\
                ^owner-.*@.*:\
                ^listmaster@.*:\
                ^root@.*:\
                ^anonymous@.*:\
                ^nobody@.*
      !domains = +rv_callout_receiver_domain_whitelist
      !sender_domains = +rv_callout_sender_domain_whitelist
      # Do not check for DSN-ignorant domains
      # those that don't accept MAIL FROM:<>
      !dnslists = dsn.rfc-ignorant.org/$sender_address_domain
      !verify  = sender/callout=10s,defer_ok

[simonpearce]

Thanks rvskin

I've tried whitelisting before but managing so many servers for so many people we found it impractical.

We've now decided to enable "Verify the existence of email senders", disable "Sender verify callout" and enable the RBL check for spamcop.

Let's see what happens now

Cheers for your input.

Simon