ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Lists "BCP" draft review

2010-06-21 16:04:29
-----Original Message-----
From: Daniel Black 
[mailto:daniel(_dot_)subs(_at_)internode(_dot_)on(_dot_)net]
Sent: Saturday, May 29, 2010 2:10 AM
To: ietf-dkim(_at_)mipassoc(_dot_)org; Murray S. Kucherawy
Subject: Re: [ietf-dkim] Lists "BCP" draft review

Hi Daniel, sorry for the less-than-timely reply.

Some specific replies to points you made, and then I'll work the rest into the 
next draft revision.

Actual Review:

Principle Recommendations:

Incorporate ARF/draft-ietf-mark-dkim-reporting as strong
recommendations so
that any incompatibilities anywhere will be obvious the the sender
domain. As
gaining statistics and experience is a dominate objective of this
working
group getting report forwarding done by verifiers so senders have a
full
picture is essential.

I'm not sure that this is the right place to refer people to the MARF work on 
DKIM failure reporting.  Generally it's a concept that would be of use to all 
senders and requires participation of all receivers, and isn't specific to 
mailing lists.

Perhaps it would be appropriate for an appendix.

Another idea based on what Barry said was to introduce a section of why
MLM
break signature and potentially dkim compliant practices that could be
achieved in the medium to longer term. An attempt at this has been
incorporated into the current section 3.3.

Do you have a summary of either set of practices?  (Those being things MLMs do 
that break signatures, and things MLMs could do to provide the list-specific 
information people want without breaking signatures.)  That would be extremely 
helpful here.  You're right, I've tried to do that in 3.3, but I've only got my 
own experience plus feedback from one other person to go on so far.

Specific components of the draft:

section 1.1

add to list of questions:

"What options exist for a recipient verifying a message?"

minor: I tend to think this current list of questions omits the
significance of
the end recipients' options in decision making based on dkim signatures
and
this is discussed in the draft.

Absent any kind of formal definition that binds a DKIM signature's "d=" tag to 
something specific to the list (such as a domain in a List-* header field) I 
don't think there's much advice we can provide here that DKIM itself doesn't 
already say.  Until then, a list signature is just another third-party 
signature.

section 1.2

insert as 1.2 before the current 1.2:

"1.2 DKIM / ADSP failure reporting
[...]

I think this would be useful advice in general, but your specific case depends 
on work being done in a different working group and possibly on a different 
schedule.

Would it be sufficient to make a more general reference to DKIM feedback 
mechanisms?  Or is it safe to make a reference to an I-D as a "work in 
progress" and proceed from there?

section 3.3 Current MLM Effects On Signatures

Append at end of subject tags paragraph.

"The content of MLM modification of the subject tag is effectively
replicating
the List-ID value in a way visible to the recipient. This behavior was
motivated by a lack of MUA support for displaying List-ID tags. It
desirable
for MUA to start supporting List-ID tags in order to deprecate this
behaviour
in MLMs."

Addition to other header fields paragraph:

"The modification of Sender/Reply-to stems from a goal to guide the
recipients
behaviour to continue the conversion or or off list. There could be an
attempt
to create a new header field to describe the desired behaviour and for
MUAs to take note of this header field."

I think I agree with Dave that we shouldn't make a vague reference to future 
work.  The focus here is making DKIM work in the current context.

I'd be happy to help with such an effort if you'd like to start one.  I'm 
skeptical about its success due to MUA development inertia, but then I had the 
same concern about MLMs and it has been allayed somewhat.

significant: explores options in changing MLM behaviour, that while is
not
going to happen in any hurry may end up occurring eventually. I
acknowledge
that the bit on attachment filtering alternatives isn't complete.

While discussing helpful MLM behavior changes is certainly useful, the 
recommendations of this document should probably presume those aren't going to 
happen in the short term and thus only be limited to DKIM-specific things.

new paragraph at the end of 3.3

In essence, the practices of MLM breaking DKIM signature verification
could be
reduced with better MUA support on existing standards and the
introduction of
a few simple standards so that MUA and MLM can operate consistently
rather
then retrofitting desired behavior into existing header fields
potentially in a
incompatible way.

I wonder if collecting all of the sentiments about MLMs and MUAs and their 
respective changes to improve the situation overall should be collected in an 
appendix.  It seems to be a common thread in conversation though.  I'll try it 
from that angle.

Thanks again!

-MSK

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