On 6/28/2014 9:41 AM, Wei Chuang wrote:
Note this isn't a full proposal as we would like the concept to be
considered first. If this discussion is successful, we would like to also
discuss a related improvement to SPF and DMARC, as well as the binary
encoding change. At the conclusion we can have a longer discussion about
the details of CONTENT-TYPE: multipart/dkim-forwarding-history or write a
draft that tightly specifies how this works.
Wei,
Any "chain of trust" idea will work with a honored client/server
negotiated protocol steps and ideals.
The problem has always been in dealing with the deviation from the
ideal protocol steps and compliancy expectations.
So if you have a protocol ABC, what are the benefits of this ABC
processing? What is the payoff for the compliant mail receiver? What
is the payoff for the originating/author domain? What happens when
there is deviation, something broke in the chain of MIME diffs? What
do you want receivers to do?
You must think of the massive volume of wasteful mail processing. Not
everyone is going to do this just for nothing. It has to have a
meaningful payoff, and today that payoff comes in the form of mail
filtering policies with rejection/quarantine/discard author domain
policy concepts.
So if your proposal says:
"If you follow these steps, the author domain
is OK with you (because you asked him) honoring
rejection, if you see a problem, then there is
something wrong with it and its better (trust the
author policy) if you just reject it."
then we you got something to consider.
But I think in this case, your proposal is a higher processing
complexity factor when all you need to do is ask the author if the
final/last signature in the chain is an trusted and/or authorized
signer domain. If you are not asking the author (directly or
indirectly) if any of this forwarding stuff is ok, then I think you
have a security conflict (loophole) to consider.
--
HLS
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
