-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of John Levine
Sent: Wednesday, October 13, 2010 9:29 AM
To: ietf-dkim(_at_)mipassoc(_dot_)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
it's
using. This is almost certainly an expensive effort.
- Y simply can't use ADSP.
- The DKIM reporting extensions should have a flag that says
DSNs
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,
that's
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
dkim=all.
R's,
John
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.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html