Charles Lindsey wrote:
So, in the second two cases, the semantics already prescribed by ADSP is:
Assuming there is no second signature by bar.example, LOOK UP the ADSP
record for _bar.example_, and if that says "Discardable" then DISCARD it.
Right.
IOW, if some user at a Discardable domain sends email to a list, it had
better be signed before it reaches the list, and the list expander had
better not break that signature.
Which is a touch issue. But there are some practical considerations.
First, the user with a DKIM=ALL and DKIM=DISCARDABLE policy will be
acting irresponsible if he selected this mode and continue to push
mail into areas historically known to break the integrity of mail.
Second the list server should add ADSP checking into the current
subscription email verification process. It should reject subscribing
domains with DKIM=ALL|DISCARDABLE. This will make it protocol
consistent and will help protect the domain.
Hate to rehash, but it would of helped if ADSP allowed a DKIM=ANY
which allows for any one to signed.
ADSP should not have written with an mutual exclusive ALL or
DISCARDABLE. DISCARDABLE should of been a policy attribute.
DKIM=UNKNOWN | ALL | ANY [, DISCARDABLE ]
with the optional discardable attribute meaning one thing:
No failure tolerated. Please Discard!
With DKIM=ANY (always signed by anyone), it would of allowed domains
who use trusted services to sign on their behalf.
This would make it work better for list servers like this one, and
systems like gmail.com what also signs mail with d=gmail.com.
But if the Discardable domain operates a list expander for a list that
anyone may post to, then it will naturally sign the expanded messages (and
it would be polite to add i=lists(_at_)foo(_dot_)example), but there is no
implication that anything should or should not be Discarded (though
perhaps Assessors might possibly do so if Sender: was not by that domain -
list expanders being supposed to set Sender).
I still don't get the i= thing. I guess if a signer wants to add it,
so what. Its part of the signature and if an accessor wants it, pass
it and let it do what it like with it.
--
Sincerely
Hector Santos
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html