Jim Fenton wrote:
Barry Leiba wrote:
But I have to consider customer sites patterns with heavy facebook
users seeing tons of fb notifications and see if a simple check can
add to the optimization.
Mike has a point, but I agree that this would be a problem for large
ISPs, where adding 10% more overhead for all Facebook messages would
be something they'd want to avoid. But...
I'd go a little further than this: If you already have a valid signature
from a
given domain, why check any more signatures from that domain? It doesn't
tell
you any more than you already know. It doesn't matter if the signatures are
identical or not.
I pointed that out to Barry myself. It was discuss long ago.
The question is this:
Why is there is failure in the first place and why should
single valid signature trump all failures?
Add to that, why should a 3rd party valid signature trump a broken 1st
party signature?
Is that not the reason the recommendation for the remailer to strip
and resign to avoid conflictive result analysis?
If DKIM is going to become the Broken Signature "Patch" framework,
basically the last signing hop model, then the "chain of trust" is
going to be presumed here.
How can that happen if remailers are exempt from checking if the first
signature was authorized in the first place before it breaks,
strips, resigns, forwards the message?
Here is a scenario:
1st party signs message:
Dkim-signature: x=X days
Non mail altering (simple list expander) 3rd party signs message:
Dkim-signature: x=Greater than X days
Both are valid signatures, what expiration prevails here? What order?
If we use the 1st valid signature idea, then the 1st party prevails.
But there might be logic that ask, is there another signature that
extends the life of the message?
Same idea with reputation.
Both valid signature, one reputation feedback says "Account Suspended
for reason XYZ." The other says "This is a good guy." I don't know.
I don't know what reputation feedback models are being complicated in
the back alleys. But is that possible?
--
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html