[ietf-dkim] Delegating responsibility: a make vs. buy
hsantos at santronics.com
Fri Aug 18 11:12:33 PDT 2006
----- Original Message -----
From: "Wietse Venema" <wietse at porcupine.org>
> In case (1), when the trusted signer-domain matches the author-domain,
> I might trust that the mail actually originates from the rfc822.from
> domain. In case (2), when the trusted signer-domain is not related
> to the author-domain, I might trust that mail was distributed by
> the mailing list that I subscribe to, or that it was processed by
> the malware removal service that I subscribe to. Thus, in (2) the
> author-domain (rfc822.from) is relatively unimportant compared to
> the signing-domain; even in (1) its importance is only secondary.
Where is all this TRUST coming from?
This is completely flawed logic subject to major high probability abuse, not
low probability. How can you continue to ignore this?
I highly doubt you can prove otherwise, where I on the other hand I prove it
100% it is flawed. I will have 100% trust, no "might trust" when I check a
2822.From: domain policy and it states a policy about how its mail is
tampered with (signed or not signed). I'm not going to trust a 3rd party
signer for absolutely no reason whatsoever unless the OA domain vouched for
it in some "Allow List." That would be a highly dangerous framework if
done in an uncontrolled manner and there is no way you can not prove it
would be exploitable.
Folks, we are continuing on this movement of allowing anyone to tamper, sign
or do whatever they want with mail, including adding/changing information to
headers that could destroy and change operations. How people expect this to
be tolerated in a wide adoption is surreal!
Hector Santos, Santronics Software, Inc.
More information about the ietf-dkim