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

2010-08-01 Thread Murray S. Kucherawy
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"?

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?

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 message."

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


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

2010-08-01 Thread John Levine
>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"?

Yes, since the damage from ADSP can affect other subscribers.

>b) Would it be a good idea to suggest MLM implementers make signing
>of submissions into a user-configurable option? ...

Since we don't have any experience, I don't think we should be telling
list managers how to verify submissions.  The text in 5.2 and 5.3
looks fine to me.

> 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

What a bad idea.  The list's output is one mail stream, as section 5.6
says.  The current language looks correct to me.

R's,
John

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


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

2010-08-01 Thread Daniel Black
On Monday 02 August 2010 08:22:15 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"?

"A warning is adviced" is acceptable. full denial/rejection is going too far. 
Subscriptions could just indicate that they want to receive email. Conflicts 
only occur with sending. Its easy enough to differenciate subscription and 
posting as they are typically to different addresses.

> b) Would it be a good idea to suggest MLM implementers make signing of
> submissions into a user-configurable option? 
Which signing are you talking about?
a) Inserting a policy for a user to stay they always sign email send to the 
list (largely a duplication of adsp=all hence perhaps not that useful. signers 
control the policy more that individual authors).
b) that the MLM will sign the MLM Output for some users and not other users 
(can't see good reason to recommend this complexity)

> 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
the rational for this suggestion will be useful.

> 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?
A MLM Output stream should be universally signed or not to provide the 
verifier a clear indiciation of what behavior to expect from the MLM. 
Providing subscriber options to receive signed email or not will likely create 
a signed and unsigned message steams. If multiple subscribers with different 
signing reception options are behind the same verifier then any differences in 
filtering behaviors will seem anonimilous to the receiver. A single signed (or 
unsigned) MLM Output stream will allow verifiers to see a consistant MLM 
behaviour and make better use of MLM signature trust relationship or stream 
based acceptance criteria.

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


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

2010-08-01 Thread Michael Thomas
On 08/01/2010 03: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”?

Refusing is doing them a big favor, and a big favor to ADSP in general.
Assuming that "highly restrictive == discardable".

> b) Would it be a good idea to suggest MLM implementers make signing of
> submissions into a user-configurable option?

People don't even know how to unsubscribe from lists. No.

> 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?

Commentary: Ick. Lists should always sign their mail, just like anybody
else who (re)originates mail. If you want to start parsing differences
like who's incoming signature verified and whose didn't, use AR or
something else, but always sign the message.

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


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

2010-08-01 Thread Murray S. Kucherawy
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
> boun...@mipassoc.org] On Behalf Of Daniel Black
> Sent: Sunday, August 01, 2010 4:48 PM
> To: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] Feedback on draft-ietf-dkim-mailinglists for
> discussion
> 
> > b) Would it be a good idea to suggest MLM implementers make signing
> of
> > submissions into a user-configurable option?
>
> Which signing are you talking about?

The MLM Output.


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


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

2010-08-01 Thread Steve Atkins

On Aug 1, 2010, at 7:37 PM, Murray S. Kucherawy wrote:

>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
>> boun...@mipassoc.org] On Behalf Of Daniel Black
>> Sent: Sunday, August 01, 2010 4:48 PM
>> To: ietf-dkim@mipassoc.org
>> Subject: Re: [ietf-dkim] Feedback on draft-ietf-dkim-mailinglists for
>> discussion
>> 
>>> b) Would it be a good idea to suggest MLM implementers make signing
>> of
>>> submissions into a user-configurable option?
>> 
>> Which signing are you talking about?
> 
> The MLM Output.

What would the benefit to the recipient of the mail not being
signed by the MLM be?

Cheers,
  Steve
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


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

2010-08-02 Thread Jeff Macdonald
On Sun, Aug 1, 2010 at 6: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”?

+1


> 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
> message.”

I must of missed that point in Daniel's thread. I hadn't realized that
the From would of been conditionally re-written. Today, endpoints (I
take that to mean MUAs), don't seem to have a standard way of dealing
with mailing lists anyway. So I'd say -1 to the reason.




-- 
Jeff Macdonald
Ayer, MA

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


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

2010-08-02 Thread Murray S. Kucherawy
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
> boun...@mipassoc.org] On Behalf Of Jeff Macdonald
> Sent: Monday, August 02, 2010 10:53 AM
> To: DKIM List
> Subject: Re: [ietf-dkim] Feedback on draft-ietf-dkim-mailinglists for
> discussion
> 
> > 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
> > message."
> 
> I must of missed that point in Daniel's thread. I hadn't realized that
> the From would of been conditionally re-written. Today, endpoints (I
> take that to mean MUAs), don't seem to have a standard way of dealing
> with mailing lists anyway. So I'd say -1 to the reason.

I don't think there's anything conditional about it.  The suggestion is to 
rewrite From: when the MLM remails its modified content.

It sounds like you're saying that's a good idea.  By my count that's three in 
favour and two against, and I suspect that's not rough consensus in either 
direction, but is probably enough to add some discussion about it to the draft, 
unless of course there's objection to even mentioning the idea.

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


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

2010-08-02 Thread Scott Kitterman
On Monday, August 02, 2010 02:13:39 pm Murray S. Kucherawy wrote:
> > -Original Message-
> > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
> > boun...@mipassoc.org] On Behalf Of Jeff Macdonald
> > Sent: Monday, August 02, 2010 10:53 AM
> > To: DKIM List
> > Subject: Re: [ietf-dkim] Feedback on draft-ietf-dkim-mailinglists for
> > discussion
> > 
> > > 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
> > > message."
> > 
> > I must of missed that point in Daniel's thread. I hadn't realized that
> > the From would of been conditionally re-written. Today, endpoints (I
> > take that to mean MUAs), don't seem to have a standard way of dealing
> > with mailing lists anyway. So I'd say -1 to the reason.
> 
> I don't think there's anything conditional about it.  The suggestion is to
> rewrite From: when the MLM remails its modified content.
> 
> It sounds like you're saying that's a good idea.  By my count that's three
> in favour and two against, and I suspect that's not rough consensus in
> either direction, but is probably enough to add some discussion about it
> to the draft, unless of course there's objection to even mentioning the
> idea.

I think this is worth considering.  In discussions with one of the developers 
of a major open source MLM, he mentioned to me that they've had feature 
requests over the years to alter From due to privacy/spambot harvesting 
reasons, so this isn't something that would only serve to mitigate damage due 
to ADSP.

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


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

2010-08-02 Thread Steve Atkins

On Aug 2, 2010, at 11:13 AM, Murray S. Kucherawy wrote:

>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
>> boun...@mipassoc.org] On Behalf Of Jeff Macdonald
>> Sent: Monday, August 02, 2010 10:53 AM
>> To: DKIM List
>> Subject: Re: [ietf-dkim] Feedback on draft-ietf-dkim-mailinglists for
>> discussion
>> 
>>> 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
>>> message."
>> 
>> I must of missed that point in Daniel's thread. I hadn't realized that
>> the From would of been conditionally re-written. Today, endpoints (I
>> take that to mean MUAs), don't seem to have a standard way of dealing
>> with mailing lists anyway. So I'd say -1 to the reason.
> 
> I don't think there's anything conditional about it.  The suggestion is to 
> rewrite From: when the MLM remails its modified content.
> 
> It sounds like you're saying that's a good idea.  By my count that's three in 
> favour and two against, and I suspect that's not rough consensus in either 
> direction, but is probably enough to add some discussion about it to the 
> draft, unless of course there's objection to even mentioning the idea.

Altering the From: address is the behaviour of an anonymous remailer.

That's a valid use case, certainly, but a tiny, tiny niche compared with the 
usual use of a mailing list manager, where the point of the MLM is to enable 
people to communicate with each other. In almost all cases the From: field 
should identify the person who wrote the email, not some intermediate 
implementation detail.

A "-1" on ever altering the From: field for any reason other than special 
requirements of the people running a specific mailing list.

Cheers,
  Steve


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


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

2010-08-02 Thread Michael Thomas
On 08/02/2010 11:21 AM, Scott Kitterman wrote:
  I think this is worth considering.  In discussions with one of the developers
> of a major open source MLM, he mentioned to me that they've had feature
> requests over the years to alter From due to privacy/spambot harvesting
> reasons, so this isn't something that would only serve to mitigate damage due
> to ADSP.

Yeahbut... given the inertia how much could we possibly expect? There's going
to be breakage and hence resistance to this were it a good idea (which I'm not
sure of). Suppose only 10% by volume of lists did this, would it still be a net
benefit?

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


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

2010-08-02 Thread Douglas Otis
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


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

2010-08-10 Thread Dave CROCKER


On 8/2/2010 11:34 AM, Steve Atkins wrote:
> A "-1" on ever altering the From: field for any reason other than special
> requirements of the people running a specific mailing list.


A +1 in support of that -1.

The view that modifying the From: is helpful has no empirical basis.  I'll 
claim 
that there is a pretty good theoretical basis for believing it makes things 
worse, not better.

As always, the instant the IETF gets into user interface design, it steps out 
of 
its group competence.  As a group, we do not have the training in cognitive 
models, UXE, or the rest of what's needed to work in this space.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


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

2010-08-10 Thread Scott Kitterman


"Dave CROCKER"  wrote:

>
>
>On 8/2/2010 11:34 AM, Steve Atkins wrote:
>> A "-1" on ever altering the From: field for any reason other than special
>> requirements of the people running a specific mailing list.
>
>
>A +1 in support of that -1.
>
>The view that modifying the From: is helpful has no empirical basis.  I'll 
>claim 
>that there is a pretty good theoretical basis for believing it makes things 
>worse, not better.
>
>As always, the instant the IETF gets into user interface design, it steps out 
>of 
>its group competence.  As a group, we do not have the training in cognitive 
>models, UXE, or the rest of what's needed to work in this space.
>
That seems pretty orthogonal to the discussion so far.  Declaring discussion of 
From off limits because it is also displayed makes me wonder why you thought it 
was alright for the IETF to take on the work codified in RFC 822 and its 
descendants? 

Just because it's displayed doesn't mean any change is driven by UX 
considerations.  I get that you're intent on avoiding anything that might make 
ADSP deployment less difficult, but please stick to the arguments that make 
some sense. 

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