[Mailman-Developers] before next release: disable backscatter in default installation
iane at sussex.ac.uk
Wed Mar 26 11:54:57 CET 2008
--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
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
(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.
IT Services, University of Sussex
More information about the Mailman-Developers