On Tuesday 22 June 2010 06:27:28 Murray S. Kucherawy wrote: > > -----Original Message----- > > From: Daniel Black [mailto:[email protected]] .. > > Incorporate ARF/draft-ietf-mark-dkim-reporting as strong > > recommendations... > > 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. ok - it seems like a particularly useful for MLM that will incur failure as people try to generate filtering rules taking DKIM into account.
> > 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? I think the list you had with the small additions pretty much covers it. > > 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. If there is nothing we can offer the recipient is there a usefulness? > > 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? I'd like the explicit reference. Its a useful spec to say this is what a feedback mechanism is rather than people missing it or relying on their own. > > 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. ok > > 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. that could be useful. > Thanks again! Thank you. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
