[Mailman-Developers] before next release: disable backscatter in default installation

[Ian Eiloart]

--On 24 March 2008 18:45:22 -0700 Mark Sapiro <mark at msapiro.net> wrote:

> Jo Rhett wrote:
>>
>> If you have an MX that queues mail for someone else and isn't
>> configured to properly deal with DSNs, then yes, you are stuck in the
>> 20th century.
>
>
> I still don't get what you mean by "properly deal with DSNs". Are you
> saying that an MTA should never return a DSN? It should either reject
> the mail during the incoming SMTP transaction or forever hold its
> piece?

Er, "peace". But yes. That should be the way that email sysadmins are 
thinking these days. But, it's a "should" not a "must", in the sense of RFC 
2821 section 2.3 <http://www.apps.ietf.org/rfc/rfc2821.html#sec-2.3>

>
> That's what it seems to me that you are saying. If that's not what you
> are saying, then perhaps you can explain under what circumstances a
> DSN is OK.

There are examples:

(1) Internal DSNs are OK if you don't accept inbound, unauthenticated mail 
from your own domain. (Actually, it's your domain so feel free to do what 
you like internally).

For example, we don't accept mail from our own domain unless it's 
authenticated, or carries a header saying that it's been through our 
server. Therefore we don't get spam with local SMTP return-paths.

So, my mail server can safely bounce email into my domain. In fact, if I'm 
handling an authenticated message submission, I prefer to bounce than to 
reject: some MUAs don't handle rejection properly.

(2) It should also be acceptable to bounce a message that gets an SPF pass 
(perhaps not from a +all entry, though), or if it carries a valid DKIM 
signature.

(2a) Given that SPF is available, this could be extended to domains that 
don't publish SPF records (yes, including us). If they don't care who's 
using their email addresses, then perhaps we should punish them by drowning 
them in backscatter!

(3) It's probably OK to bounce a message to a list member - perhaps if the 
message broke some list policy on message content.

-- 
Ian Eiloart
IT Services, University of Sussex
x3148