SMTP-callbacks (aka Sender Verify, Sender callouts, SAV)

[Adam Katz <an...@khopis.com>]

Charles Gregory wrote:
> On my system I also have SMTP-callbacks, so if the envelope sender is
> not deliverable ...

I read recently that that's a Bad Thing (and I'm leaning on agreeing):
http://www.backscatterer.org/?target=sendercallouts

Sure, you can justify it with CAN-SPAM mentality (you're required to
facilitate one transaction for the opt-out, etc), but it's an
interesting point nonetheless.

I had (once upon a time) though about implementing a system where it
uses a series of fail-overs, so e.g. try DKIM, then SPF, then SAV
(Sender Address Verify, a.k.a. Sender callouts, a.k.a.
SMTP-callbacks).  This means that SAV would not be used for any domain
that already has DKIM or SPF.  Since I also have greylisting in front
of all of that, that would make the invasive SAV calls far more rare
and targeted mostly at legit senders rather than forged ones.

Thoughts?

Re: SMTP-callbacks (aka Sender Verify, Sender callouts, SAV)

[John Rudd <jr...@ucsc.edu>]

On Sun, Apr 26, 2009 at 14:01, Adam Katz <an...@khopis.com> wrote:
> Charles Gregory wrote:
>> On Fri, 24 Apr 2009, Adam Katz wrote:

>
> The more pressing point (since fixing the one you mentioned is pretty
> simple) is that when you use a call to a sender's MX record and either
> use SMTP's VRFY command or pretend to begin a message, you're wasting
> their bandwidth and even acting like a spammer yourself.
>
> In extreme cases, this is also an accidental DDoS attack.  A spammer
> aware of such mechanisms can use SAV-enabled servers LIKE YOURS to
> purposefully launch DDoS attacks against whomever they're forging.
>

Yup, SMTP callbacks and challenge-response mechanisms are both major
blights upon the internet.  They're rude, they're prone to abuse,
they're pushing your spam problem onto someone else's servers... and
on and on.  There's no excuse for using them.

(and, frankly, whenever I get a stray challenge-response, I answer it
... and I'm not the only one, so that also means that challenge
response mechanisms aren't reliable, exactly because you're pushing
your spam solution onto someone else, and you have no idea what that
someone else might do about it)

Re: SMTP-callbacks (aka Sender Verify, Sender callouts, SAV)

[Adam Katz <an...@khopis.com>]

Charles Gregory wrote:
> On Fri, 24 Apr 2009, Adam Katz wrote:
>> I read recently that that's a Bad Thing (and I'm leaning on agreeing):
>> http://www.backscatterer.org/?target=sendercallouts
> 
> The most compelling argument on that site is one that almost slips by
> un-noticed. A spammer could very well forge a honeypot as a sender
> address, causing my system to 'send mail' (a verify) to a honeypot, and
> possibly get blacklisted. And this would also open up a way for spammers
> to 'poison' honey pots by having them blacklist so many legitimate
> servers that the blacklists have to be thrown out.... Ouch.

Actually, that's referring to backscatter itself.  You should never send
bounce messages, challenge-response, vacation messages, or other
automated responses to external accounts via email.  It should be done
with SMTP codes during the initial transaction.  See:
http://www.spamcop.net/fom-serve/cache/329.html
http://en.wikipedia.org/wiki/Backscatter_spam
and of course, the rest of the www.backscatterer.org site.

The more pressing point (since fixing the one you mentioned is pretty
simple) is that when you use a call to a sender's MX record and either
use SMTP's VRFY command or pretend to begin a message, you're wasting
their bandwidth and even acting like a spammer yourself.

In extreme cases, this is also an accidental DDoS attack.  A spammer
aware of such mechanisms can use SAV-enabled servers LIKE YOURS to
purposefully launch DDoS attacks against whomever they're forging.

Re: SMTP-callbacks (aka Sender Verify, Sender callouts, SAV)

[Charles Gregory <cg...@hwcn.org>]

On Fri, 24 Apr 2009, Adam Katz wrote:
> I read recently that that's a Bad Thing (and I'm leaning on agreeing):
> http://www.backscatterer.org/?target=sendercallouts

The most compelling argument on that site is one that almost slips by 
un-noticed. A spammer could very well forge a honeypot as a sender 
address, causing my system to 'send mail' (a verify) to a honeypot, and 
possibly get blacklisted. And this would also open up a way for spammers 
to 'poison' honey pots by having them blacklist so many legitimate 
servers that the blacklists have to be thrown out.... Ouch.

Mind you, I receive mail on a different IP address than my outgoing mail.
So even if the incoming server was blacklisted for verifies, this wouldn't 
impede my legitimate outgoing mail. Or would it....? Hmmmm......

- Charles