[ietf-dkim] Lists "BCP" draft review
Murray S. Kucherawy
msk at cloudmark.com
Mon Jun 21 13:27:28 PDT 2010
> -----Original Message-----
> From: Daniel Black [mailto:daniel.subs at internode.on.net]
> Sent: Saturday, May 29, 2010 2:10 AM
> To: ietf-dkim at mipassoc.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
> group getting report forwarding done by verifiers so senders have a
> 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
> 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
> 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
> 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
> for MUA to start supporting List-ID tags in order to deprecate this
> in MLMs."
> Addition to other header fields paragraph:
> "The modification of Sender/Reply-to stems from a goal to guide the
> behaviour to continue the conversion or or off list. There could be an
> 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
> going to happen in any hurry may end up occurring eventually. I
> 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
> 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.
More information about the ietf-dkim