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
MAIL FROM: <>
RCPT TO: user(a)example.com
See result ....
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@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@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
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
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.