Re: [nznog] SMTP Server Callbacks, the Devil or a Godsend?
In message <040c01c6af00$812193c0$de0dea3c(a)office.orcon.net.nz>, "Craig Whitmore" writes:
I have been looking into callbacks lately for SMTP (to reduce spam) and have noticed a few things with a number of large nz sites who send out email.
This is the scheme where upon receiving an inbound MAIL FROM:/RCPT TO: the mail server then connects back to the MX for the claimed domain and issues a MAIL FROM:/RCPT TO: as if it were going to send a reply? I'm pretty wary of such schemes because of the potential for looping (eg, A connects to B, B connects to A to verify, A connects to B to verify, ...), and because the "callback" action looks pretty much like an address verification probe for, eg, a spam list. (Once upon a time SMTP had a VRFY action which could be used to confirm addresses, but pretty much everyone turns that off due to abuse.) Aside from that some way of being sure the originator is a "real" address, preferably without requiring a separate connection, is a nice idea. One scheme I've seen a fairly large mail source (Yahoo? AOL? I forget) was to test for postmaster(a)domain instead, on the basis that the address should exist and at least they'd have somewhere to send reports of problems. That seems marginally less bad than trying the originator of the message.
A number of sites send from email addresses which don't exist.
Including some newsletter mailouts that I'm aware of. Your (Craig's) list is by no means complete. Personally I'd be reasonable keen to see such mail refused as a general industry policy. Because they inevitably seem to send out (regularly) to large numbers of addresses which ceased to exist a long time ago, or never existed (hotmale.com, anyone?). The ones with valid sender addresses which have, eg, full mailboxse are only marginally less annoying. Especially given that automatic bounce processing systems have existed for a long time. I think using some sort of sender address verification scheme and then papering over it with a whitelist to allow those that fail to still send mail rather misses the point. But then I also think that email is virtually a lost cause these days, at least in the "anyone can forge anything" SMTP form. Ewen
This is the scheme where upon receiving an inbound MAIL FROM:/RCPT TO: the mail server then connects back to the MX for the claimed domain and issues a MAIL FROM:/RCPT TO: as if it were going to send a reply?
Nearly there, it fakes a bounce (a DSN) not a reply. from an external mail server: MAIL FROM: user(a)example.com CALLBACK from the answering mail Server to the MX of the example.com's mail server MAIL FROM: <> RCPT TO: user(a)example.com See result .... QUIT
I'm pretty wary of such schemes because of the potential for looping (eg, A connects to B, B connects to A to verify, A connects to B to verify, ...), and because the "callback" action looks pretty much like an address verification probe for, eg, a spam list. (Once upon a time SMTP had a VRFY action which could be used to confirm addresses, but pretty much everyone turns that off due to abuse.)
Using the proper <> as the MAIL FROM: will not cause loops at all.
Aside from that some way of being sure the originator is a "real" address, preferably without requiring a separate connection, is a nice idea. One scheme I've seen a fairly large mail source (Yahoo? AOL? I forget) was to test for postmaster(a)domain instead, on the basis that the address should exist and at least they'd have somewhere to send reports of problems. That seems marginally less bad than trying the originator of the message.
Using Postmaster(a)domain for a callback is very wrong thing to do and will cause loops but I don't know of any callback systems recently which do this.
I think using some sort of sender address verification scheme and then papering over it with a whitelist to allow those that fail to still send mail rather misses the point.
Yes.. there are quite a number of sites which send out stuff and having to whitelist www-data@*, noreply@*, donotreply@* have to be whitelisted as well. Worse is people who don't accept <> at all (Quite a number of Mail Marshall mail servers) so having to whitelist them as well.
But then I also think that email is virtually a lost cause these days, at least in the "anyone can forge anything" SMTP form.
Yes they can forge it, but if people use SPF records (and test for them), then you have part of the problem fixed (NEARLY) Using Domain-Keys will also help you verify the contents of the message.
Ewen
participants (2)
-
Craig Whitmore -
Ewen McNeill