[ietf-dkim] FW: An issue with DKIM reporting extensions
MH Michael Hammer (5304)
MHammer at ag.com
Wed Oct 13 08:05:37 PDT 2010
> -----Original Message-----
> From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim-
> bounces at mipassoc.org] On Behalf Of John Levine
> Sent: Wednesday, October 13, 2010 9:29 AM
> To: ietf-dkim at mipassoc.org
> Subject: Re: [ietf-dkim] FW: An issue with DKIM reporting extensions
> >- In order to make use of ADSP, Y needs to change which MTA
> >using. This is almost certainly an expensive effort.
> >- Y simply can't use ADSP.
> >- The DKIM reporting extensions should have a flag that says
> >should not cause generation of fraud reports.
> I'll take "none of the above", Alex.
> I've seen a enough spam masquerading as DSNs that I really wouldn't
> want to give DSNs a free pass. I also think that history has not been
> kind to people who made permanent changes to standards to work around
> temporary software limitations. If the MTA can't sign its DSNs,
> a bug, no matter how popular it is. (Come to think of it, my MTA has
> the same issue, although since I will never publish dkim=all, it's
> not functionally a bug.)
> If people are serious about signing all their mail, they should sign
> all their mail. Maybe they'll switch MTAs, maybe their popular MTA
> will eventually fix the DSN signing bug, and then they can publish
I have to agree with John. The fact that a particular MTA doesn't sign
DSNs is a problem with that particular MTA. dkim=all means just that.
The implementer is faced with the choice of not publishing "all",
getting their vendor to fix the product, switching vendors or accepting
that their DSNs may end up in /dev/null.
More information about the ietf-dkim