RE: Is predictable spam filtering a vulnerability? (silently drop

[David Brodbeck]

> -----Original Message-----
> From: David F. Skoll [mailto:dfs@roaringpenguin.com]

> This is indeed a problem, and it's a loophole that needs to be closed.
> There needs to be a way for an SMTP server to correlate a bounce
> message with a sent message, and reject the bounce message if it
> wasn't caused by a validly-sent message. Proposals like SPF can help
> a little.

SPF helps halfway -- if you check the SPF record and the message comes from
a host that is permitted to send for that domain, bouncing is "safe" -- you
won't cause backscatter spam to an innocent third party.

As for rejecting invalid bounces, some people have been experimenting with
adding a short crypto hash to the envelope sender address of each message.
If a bounce comes in and the hash is wrong, it has to be invalid, so it's
rejected. Google for 'signed envelope sender' for more info. This is an
interesting idea because it doesn't require anyone else to do anything --
you can implement it on your own domain and see immediate benefits.

[Stephen Warren]

David Brodbeck wrote:

>As for rejecting invalid bounces, some people have been experimenting with
>adding a short crypto hash to the envelope sender address of each message.
>If a bounce comes in and the hash is wrong, it has to be invalid, so it's
>rejected. Google for 'signed envelope sender' for more info. This is an
>interesting idea because it doesn't require anyone else to do anything --
>you can implement it on your own domain and see immediate benefits.
>
>
TMDA (http://www.tmda.net/) is a system that'll allow you to do this.

Yes, whilst TMDA is a challenge-response system which some won't like,
you can (trivially) configure it not to ever challenge, and use it for
other means, such as validating crypto-style envelope senders.

--
Stephen Warren, Software Engineer, Parama Networks, San Jose, CA
swarren@wwwdotorg.org http://www.wwwdotorg.org/