damn MUAs for not being consistent for threading - see my other
message in the other thread as it is related to this one:
On Mon, Apr 26, 2010 at 1:36 PM, McDowell, Brett
<bmcdowell(_at_)paypal(_dot_)com> wrote:
On Apr 23, 2010, at 6:28 PM, Murray S. Kucherawy wrote:
Something like: X sends to a list at Y that then relays to Z; Z trusts Y to
implement DKIM and Authentication-Results and all that properly, so Z
believes Y when it says "X had a signature on here that verified" even if
X's signature on arrival at Z is either invalid or absent.
That's interesting. Let's make this concrete... I'll use myself as an
example.
X = me/PayPal.com
Y = this list/ietf-dkim(_at_)mipassoc(_dot_)org
Z = Google's Gmail service [1]
It is my assumption that someone subscribed to this list has a gmail.com
account (or a Yahoo.com account [2]). Therefore, my use case is simple. I
would hope that those of you reading this from your Gmail or Yahoo! accounts
actually receive this message. If Z breaks the signature, you won't see this.
how about Y breaking the signature? I see your message only because I
told gmail's filtering system to not put messages into the spam folder
for this list. Otherwise it would of gone into the spam folder.
Looking at the source of the message, I only see the list's DKIM
signature.
So if it simply isn't practical to expect lists to maintain the signature,
then offering the option for the list to validate the signature coming from X
and send a new signature to Z that Z *can* (but doesn't have to) "trust", is
something immediately useful.
Should the policy statements be ignored at that point?
--
Jeff Macdonald
Ayer, MA
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html