Sender callout - RFC

[sparek-3]

Lately we have been receiving some complaints regarding the use of sender callouts to verify mail senders for incoming mail. This has gotten me to wonder, does the envelope sender (i.e. the address specified in the MAIL FROM stage) have to be a valid e-mail address on that host? This is the address that is checked when doing a sender callout, correct? I'm just curious as to whether this address has to be valid. Is there any RFC standard that says that [email protected] must be a valid e-mail address on the bob.com mail server?

I did try to search through the RFCs, but could not find anything that answers this (albeit, I may not have been looking in the right place). I'm just wondering if anyone knows this for sure. If the envelope sender does not have to be valid, then it would seem that doing sender callouts would be going against RFC standards.

Thanks

 

[AndyReed]

If the envelope sender does not have to be valid, then it would seem that doing sender callouts would be going against RFC standards.

Even though the practice of using callouts is RFC compliant, in the real world you will run into issues with undelivered email from legitimate users.

This article gives a good overview of potential problems you may run into while using "callouts to verify the existence of email senders":

http://www.tldp.org/HOWTO/Spam-Filtering-for-MX/smtpchecks.html#callback

When our clients enable callouts, the Mail server had rejected messages from several major Web sites, including a domain of a well known business - their mail server was sending messages with an invalid return address. Clearly, it is their fault for being RFC ignorant, but unfortunately this is not uncommon these days.

Also keep in mind that some administrators (whom think they know it all) have setup their email servers to reject "RCPT TO:" requests if the envelope sender address is blank. This will result in your callouts being rejected if you are using exim's default configuration. (In any case, rejecting blank sender is a violation of RFC). Technically speaking, unlike the old argument about RBL usage, the sender's "RFC ignorance" gives you a clear moral right to reject email messages from them.

It is up to you to decide whether you want to noticeably decrease the amount of incoming spam, or to save yourself from otherwise unavoidable and time-consuming problems. It is a catch 22

 

[mctDarren]

Shame on Bank of America for being one of the big firms not in line to accept this. We had a client who gets sale confirmations from them regarding electronic money transfers. The emails are sent from a non-existent address on a server that simply drops any call back attempts. Emails to their IT department have gone unanswered.

Ignorance regarding email like this only contributes to the spam problem. Unfortunately, admins can sometimes be "Bob, the guy who one day fixed the printer and found himself promoted." :|

 

[sparek-3]

Shame on Bank of America for being one of the big firms not in line to accept this. We had a client who gets sale confirmations from them regarding electronic money transfers. The emails are sent from a non-existent address on a server that simply drops any call back attempts. Emails to their IT department have gone unanswered.

Ignorance regarding email like this only contributes to the spam problem. Unfortunately, admins can sometimes be "Bob, the guy who one day fixed the printer and found himself promoted." :|

The non-existent address problem is what I am referring to. I'm not sure if what Bank of America is doing is actually illegal per say in terms of RFC compliance in regards to this (if they are dropping call back attempts then that is another story).

If the mail transaction sent from Bank of America uses an envelope sender of:

MAIL FROM: <[email protected]>

If [email protected] is not a valid e-mail address, then I'm still not sure if this is invalid. The sender callout will fail if it is not a valid e-mail address, but does the MAIL FROM have to be a valid e-mail address?

The link that AndyReed posted may answer some of that, I haven't checked the link yet.

As far as standards compliance goes, I like to think that I keep our servers as close to a standards compliance as possible. I won't say that they are following all standards. However, if I'm not following a standard then in my opinion it makes it difficult for me to demand that other mail servers follow standards. For example, if the MAIL FROM does not have to be a valid e-mail address, but because of the sender callouts that are set up on our servers the message is rejected anyway, this makes it difficult to point the finger at some other server for rejecting mail from the null sender (violating RFC 1123) when I myself am not following standards. Of course, this still doesn't mean that a server that rejects the null sender should be given a free pass either.

 

[mctDarren]

If [email protected] is not a valid e-mail address, then I'm still not sure if this is invalid. The sender callout will fail if it is not a valid e-mail address, but does the MAIL FROM have to be a valid e-mail address? The link that AndyReed posted may answer some of that, I haven't checked the link yet.

I haven't either but will when I get a chance. In our case, the email was in fact sent from an invalid address, the mail-from and the envelope-from are the same. We worked around it, so no biggie- just a pain.

 

[sebby]

I had to disable callouts to receive email notifications from this very Forum!

 

[mickalo]

I had to disable callouts to receive email notifications from this very Forum!

yes, we also had to disable it. We found that almost every support forum I visit and use, I couldn't receive any email unless I disabled the sender/callout in Exim. I found that to be quiet interesting

Mickalo