Re: Handling mail from *fake* mailer daemons

From: Daniel Black <daniel.subs_at_internode.on.net>
Date: Wed, 13 Oct 2010 08:51:12 +1100

On Wednesday 13 October 2010 05:53:07 Murray S. Kucherawy wrote:
> 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.

or (c) filter the adsp failure reports related to a DSN message that
originated from their domain.
 
> 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
I think documenting this is a good idea.

> 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.
as this is under the MTA2 control this is certianly an idea.

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

I agree with this sentiment however lets take for instance the option exists
and is used.

Does that mean a third party can send a spoofed email to MTA1's domain with no
envelope sender address and
a) it gets accepted and delivered because the ADSP policy is ignored?
b) it gets rejected and no ADSP report is sent?

So with option a) the adsp policy is ignored and with option b) the adsp
reporting wishes of MTA2's doamin is ignored. As both of these are explicty
against the wishes of MTA2 and I don't think it should be done.

Also were the use of DSN's becoming a little discouraged in email
architecture?
Received on Tue Oct 12 2010 - 21:47:11 PST