RE: Handling mail from mailer daemons

From: Murray S. Kucherawy <msk_at_cloudmark.com>
Date: Tue, 12 Oct 2010 11:53:07 -0700

I didn't get Daniel's message to the list, oddly.

> -----Original Message-----
> From: opendkim-users-bounce_at_lists.opendkim.org [mailto:opendkim-users-bounce_at_lists.opendkim.org] On Behalf Of Rolf E. Sonneveld
> Sent: Tuesday, October 12, 2010 2:57 AM
> To: opendkim-users_at_lists.opendkim.org
> Cc: Daniel Black; msk_at_blackops.org
> Subject: Re: Handling mail from mailer daemons
>
> > I think no special treatment should be done.
>
> +1 (or if possible: +10!).
>
> > In the case here it is an error
> > condition that generates a few more emails than usual. This is
> probably useful
> > to identify the problem or to encourage the MTA2 owner to do error
> handling
> > better.

The MTA 2 owner (in this case, me) has no option to either (a) cause DSNs to be signed, or (b) change the From: field in DSNs. The only option is not to use ADSP at all, or change to an MTA that does offer one of those two solutions above.

The MTA in question (in this case, sendmail) is sufficiently widely deployed that we need to face the reality that this is going to begin to happen everywhere, and we will get the reports about it.

> Please let us not invent all sorts of exceptions and exceptions on
> exceptions, to support all stupid corner cases that ADSP can cause. If a
> site chooses to use ADSP discardable, that's fine: but then they should
> take the full burden of signing every piece of mail they send. If they
> don't, the problem is theirs, not yours.

I think we need to add something about this to our READMEs if we don't plan to deal with this in software. This is only the first time this is going to come up.

Perhaps another option is to amend the DKIM reporting extensions to have a flag that indicates DSNs should be exempted from the reporting.

> The more complexity we introduce, the harder it will be to maintain all
> of this. As OpenDKIM is widely used and IMHO is more or less the
> reference platform for DKIM validation and signing these days,
> introducing these sorts of exceptions in OpenDKIM can have negative
> impact on the deployment of DKIM in general.

Why would it impact DKIM deployment, and not ADSP deployment specifically?

> This does not mean there is no problem, but the problem needs to be
> addressed in the context of ADSP. As such it fits into the IETF DKIM
> charter, item 3 (deployment and interoperability):
>
> > 3. Collect data on the deployment, interoperability, and
> > effectiveness of the Author Domain Signing Practices protocol
> > (RFC 5617), and determine if/when it's ready to advance on the
> > standards track. Update it at Proposed Standard, advance it to
> > Draft Standard, deprecate it, or determine another disposition,
> > as appropriate.
>
> and probably should be discussed on the ietf-dkim list, not here. After
> all, it's not an OpenDKIM specific problem, but a side-effect of using
> ADSP discardable by some 3rd party.

I don't think I agree. This is a question of implementation. It should be discussed on ietf-dkim (and I'll mention it over there now), but I think it's also in context here since our software is unintentionally part of the problem.
Received on Tue Oct 12 2010 - 18:53:16 PST