--On 24 March 2008 18:45:22 -0700 Mark Sapiro <mark@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