Re: Handling mail from mailer daemons

From: Rolf E. Sonneveld <>
Date: Tue, 12 Oct 2010 11:57:16 +0200

  On 10/10/10 3:07 AM, Daniel Black wrote:
> On Friday 08 October 2010 09:14:55 Murray S. Kucherawy wrote:
>> What do people think opendkim should do when it gets mail from a mailer
>> daemon (i.e. one with an empty envelope sender)? Right now such mail gets
>> no special treatment. However I've observed this behavior:
>> - owner of MTA 2 posts an ADSP policy of "all"
>> - MTA 1 (running opendkim) sends DKIM-signed mail to MTA 2
>> - MTA 2 feeds that mail to a program, which doesn't like it so it exits
>> with an error - MTA 2 generates a DSN to MTA 1; DSN is not signed
>> - MTA 1 receives DSN
>> - MTA 1 has "SendADSPReports" set
>> - MTA 1 observes DSN is unsigned, contradicting MTA 2's ADSP policy
>> - MTA 1 generates an ADSP report back to MTA 2
>> In fact MTA 2 would have signed the DSN, except that DSNs are not passed
>> through signing filters by MTA 2 by design, so its DSNs will never be
>> signed.
>> Is the owner of MTA 2 limited by his own architecture never to use ADSP, or
>> should opendkim simply ignore incoming bounces by default (with, of
>> course, a switch to override the default) so that ADSP can be used to
>> protect non-DSN mail?
>> -MSK
> 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.
> Were it not an error condition could it be possible for the MTA2 owner to put
> bounce messages on a different domain to the ADSP policy? Alternately the MTA2
> owner could setup a report interval to prevent a overload of ADSP reports.

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.

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.

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.

Received on Tue Oct 12 2010 - 09:57:30 PST

This archive was generated by hypermail 2.3.0 : Mon Oct 29 2012 - 23:19:49 PST