On 4/28/2010 8:02 AM, MH Michael Hammer (5304) wrote:
A few thoughts to fuel the discussion:
1) It may be that the BCP document would appropriately have a section
for end users of mail lists. One possible recommendation is that for
domains which have strong security concerns, they may want to have a
policy against posting to lists using the domain in question. (I'm
throwing this out as a straw man).
Are you suggesting a bit of draft text that recipient sites might include in
the
email practices documentation they supply to the (human) users?
2) One possible recommendation to list managers is that if a message to
the list is DKIM signed AND has an ADSP discardable policy AND the
signature cannot be maintained intact then the list should bounce the
message.
What is the particular benefit of doing this, rather than letting the receiving
site do the bouncing? This is extra mechanism for the MLM, and most MLMs won't
be supporting it. I'm trying to get a clear sense of the value proposition for
this.
3) Is there a way for us (perhaps in a future version) to provide for
some sort of "encapsulation" that will allow the original
signature/message to be maintained even as the list does certain (as yet
unspecified) actions which might currently break the signature? Just
blue skying here.
I think you are raising the (much) larger question of constraining the nature
of
changes made by MLMs. Since the are actually posting an entirely new message,
they have the legitimate freedom to do what they want to it. However, some can
choose to participate in that much more constrained role, looking more like a
relaying MTA than a modifying intermediary.
4) I recognize the chorus which says "mail lists have always done things
a certain way and who are you to tell us how or what we have to do".
Having given that recognition, in creating an authentication model it
Strictly speaking, DKIM does not "authenticate" any part of the message, othe
than the d= parameter.
I realize that this is an irritating observation, but it is semantically
precise
and accurate. Absent the presence of ADSP usage, assuming that anything else
is
"authenticated" goes beyond the DKIM specification.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html