On Tuesday 22 June 2010 06:27:28 Murray S. Kucherawy wrote:
-----Original Message-----
From: Daniel Black
[mailto:daniel(_dot_)subs(_at_)internode(_dot_)on(_dot_)net]
..
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