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
