Re: Handling mail from mailer daemons

From: Alessandro Vesely <vesely_at_tana.it>
Date: Fri, 08 Oct 2010 07:32:06 +0200

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.

Why? I don't understand the rationale for such design.

At any rate, I can confirm I got, e.g.

  Authentication-Results: wmail.tana.it;
   dkim-adsp=fail header.from=MAILER-DAEMON_at_blackops.org

(BTW, that example was triggered by a missing gpg key. Sorry about
it, I thought I had disabled sending those stats. Nevertheless, gpg
is useless there, since the original message had already

  Authentication-Results: medusa.blackops.org; dkim=pass
   (1024-bit key; insecure key) header.i=_at_tana.it header.b=ZhtcGtrl;
   dkim-adsp=pass)

> 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?

This is yet another failure point for ADSP. However, they could
have set up a sub-domain for sending those bounces "From".

I'd imagine someone could argue that "all" means all, not
all-except-bounces-and-possibly-another-bunch-of-unusual-cases. The
protocol world to describe the latter is "unknown".
Received on Fri Oct 08 2010 - 05:31:54 PST