-----Original Message-----
From: Rolf E. Sonneveld
[mailto:R(_dot_)E(_dot_)Sonneveld(_at_)sonnection(_dot_)nl]
Sent: Monday, September 13, 2010 5:28 PM
To: Murray S. Kucherawy
Cc: MH Michael Hammer (5304); dkim-ops(_at_)mipassoc(_dot_)org
Subject: Re: [dkim-ops] hammering with a soldering iron, was subdomain
vs.
cousin domain
On 09/13/2010 09:19 PM, Murray S. Kucherawy wrote:
-----Original Message-----
From: MH Michael Hammer (5304) [mailto:MHammer(_at_)ag(_dot_)com]
Sent: Monday, September 13, 2010 12:06 PM
To: Murray S. Kucherawy; dkim-ops(_at_)mipassoc(_dot_)org
Subject: RE: [dkim-ops] hammering with a soldering iron, was
subdomain
vs. cousin domain
I think your last comment is perhaps the most interesting one. As
John
Levine frequently reminds us as he invokes King Canute, we cannot
tell
receivers what to do. I don't know if this association exists, but
if
receivers find an association between failed signatures and
malicious
email I can just about guarantee you that they will take advantage
of
that data point..... Regardless of what the standard says. Bottom
line,
a failed signature will be treated in accordance with those things
that
a failed signature is perceived to be associated with.
Naturally that's true, but I think until there's evidence that a
negative validation should mean something, I'm inclined to believe the
RFC's advice is right.
+1. Please let's not degrade the status of RFC4871 to 'Experimental'.
The RFC is clear about how to treat failed signatures. We don't have
to
accommodate for all possible wrong interpretations of the RFC, do we?
/rolf
Rolf,
There is no intent to degrade the status of RFC4871 to 'Experimental'. I
refer you to section 6.3 and the following:
"However, if the
verifier does opt to reject such messages (for example, when
communicating with a peer who, by prior agreement, agrees to only
send signed messages), and the verifier runs synchronously with the
SMTP session and a signature is missing or does not verify, the MTA
SHOULD use a 550/5.7.x reply code."
There is clearly activity in the prior agreement space - particularly
"trusted 3rd parties" that falls under the above.
Mike
_______________________________________________
dkim-ops mailing list
dkim-ops(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-ops