The problem with SMTP callbacks, is there is no way for a server to
confirm if this is an SMTP callback, or a malicious script attempting to
harvest email addresses.
And looking at our logs, there are a LOT more connections from email
validator services, list washing services, and malicious users, than
there are from valid SMTP callbacks.
We do not recommend using SMTP callbacks, there are a lot of other
methods to identify forged senders, and SMTP callbacks probably WILL get
you blacklisted.. eg I can send a bot to your server, using fake email
addresses or from honeypot email addresses, and get you to generate
enough traffic that the server you are performing your SMTP callbacks
against put you on a blacklist.
Be interesting to hear how the big operators (Gmail/o365) respond to
SMTP callbacks.
And love to hear about any proposed mechanisms, that could justify SMTP
callbacks, as tempting as the idea sounds, it isn't viable.
Of course, all email servers should ensure that the address in the MAIL
FROM exists on their server, before sending it out.. so as long as you
only accept mail from sources that are responsible for that domain (SPF
checking COULD be a way to determine that) you should NOT get an invalid
email address ..
But the idea of confirming that you can deliver email to the address
described in the MAIL FOM is attractive at the SMTP acceptance level.
Just try to use a different method ;)
(Imagine you hit a rate limiter during SMTP callbacks, does this mean
you don't accept email from that server any more?)
On 2021-09-20 2:10 p.m., Jaroslaw Rafa via mailop wrote:
Dnia 20.09.2021 o godz. 19:40:24 Peter N. M. Hansteen via mailop pisze:
if you do reach a human there, could you do us all a favor and ask
them whether they still believe in the tooth
fairy^H^H^H^H^H^H^H^H^H^H^H^HSMTP callbacks and show them
https://bsdly.blogspot.com/2017/08/twenty-plus-years-on-smtp-callbacks-are.html?
I think you're wrong claiming in that article that SMTP callbacks are "only
verifying in a very limited sense that the domain's mail exchanger was
indeed equipped with a functional SMTP service." They verify much more than
that, they verify whether the target address actually exists. If you
perform the SMTP dialogue you quoted:
HELO <verifier host name>
MAIL FROM:<>
RCPT TO:<the address to be tested>
QUIT
then, for a non-existent address, you should get a 5xx response to RCPT and
you know that the address is invalid. I hope you are not trying to say that
you accept any recipient address at SMTP stage and then in case of
non-existent addresses generate backscatter afterwards?
The host doing SMTP callback does not have to check whether the mail comes
from a "valid" sender host. It doesn't matter for the purpose of the
callback - to check whether the specified sender address actually exists. If
host A is doing SMTP callback and ANYBODY (from any host) will send mail as
[email protected] to host A, in any case host A has to contact a MX for
example.org, because only that MX can verify whether [email protected]
actually exists or not. This can be used by host A as one of the signals to
accept or reject a message (I guess it's pretty reasonable to reject
messages from senders that don't exist; even if some automated sending
mechanism sends messages from a "no-reply@" type address, that address
should actually exist; it will probably discard all incoming mail, but it
should exist).
Of course, because SMTP callback is a heavy operation, consuming quite a lot
of resources, proper implementation should previously use "lighter" tests
to possibly reject or accept a message before proceeding to SMTP callback.
But that's a different story.
Of course, there are issues related to running SMTP callbacks, for example
if host A performs too many callbacks with non-existent addresses to host B,
host B may put host A on a blacklist - but this is exactly opposite
situation than in your article. In your case it was not host A that got
blacklisted by host B (which one might expect), but host B blacklisted by
host A, which makes completely no sense. The code running on host A was
stupid - it did not blacklist the actual sending host, but the host it was
performing callbacks to. This is wrong, but it has nothing to do with
callbacks themselves. Callbacks are not a problem; the problem was in your
case how the data obtained from callbacks was used.
In my opinion callbacks *can* be useful and your request (expressed in your
article) to abandon them altogether is too far-fetched. However of course,
they have to be used correctly.
--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada
This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop
