ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Feedback on draft-ietf-dkim-mailinglists for discussion

2010-08-02 17:02:03
On 8/1/10 3:22 PM, Murray S. Kucherawy wrote:

Some offlist feedback I wanted to bounce to the list to gauge consensus:

a) Section 5.1 currently advocates a warning to new subscribers to an 
MLM with a highly restrictive ADSP policy. Should this be stronger, 
such as “a warning is advised, and full denial should be considered”.

For ADSP "dkim=discardable", when the mailing lists alters the message, 
the list might warn against submitting messages of this type to the 
list. I don't think full denial would be appropriate.

b) Would it be a good idea to suggest MLM implementers make signing of 
submissions into a user-configurable option? I think there was some 
text in there already about the idea of bifurcating the list’s output 
into a signed stream and an unsigned stream, but since I’m getting the 
opposite suggestion now it probably means the draft doesn’t indicate 
in enough detail why this might be a bad (or good) idea. Can anyone 
provide some additional commentary?

-1

How would this be a good idea? What advantage is there in not signing 
the message? Not signing would seem a determent.

c) A “-1” to the idea of altering From: to cope with ADSP; the reason 
given: “This presumes endpoints will understand a DKIM-related 
From:-altered


-1 to the general idea.

Altering the From, for most lists, would reduce the list's utility. Many 
feel the lists create a type of public record, where the From is an 
important element. Also people also tend to behave less appropriately 
when anonymous.

Some have suggested a pseudo From would be reduced spam exposure, as 
sending credentials into the list would be less obvious. But if the list 
were to act as a forwarding agent for a pseudo From, forwarding would 
reintroduce spam exposures in a form difficult to filter.

-Doug




_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html