Re: [ietf-dkim] ISSUE: non-ascii header text

[Murray S. Kucherawy]

> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
> On Behalf Of John Levine
> Sent: Tuesday, April 12, 2011 11:32 PM
> To: ietf-dkim@mipassoc.org
> Subject: [ietf-dkim] ISSUE: non-ascii header text
> 
> Oops, this is a separate issue.  But I hope it's also not
> contentious.
> [...]

Since I'm not exactly an EAI/IDNA expert...

> The only thing that's not obvious to me is whether the hash functions
> should hash the bytes of the UTF-8, or convert them to UTF wide
> characters and hash those.  Depending on the way the MTA is written,
> either might seem more "natural", but I'm inclined to say you hash the
> UTF-8 bytes because the SHA-1 and SHA-256 hash functions are defined
> on bytes, not wider things.

Can you suggest the exact change to make here, or confirm there isn't one?

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

Re: [ietf-dkim] ADSP stats

[Murray S. Kucherawy]

> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
> On Behalf Of bill.ox...@cox.com
> Sent: Tuesday, April 19, 2011 1:56 PM
> To: jdfalk-li...@cybernothing.org; ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] ADSP stats
> 
> In my mind the whole adsp degenerated into a use case only for well
> recognized narrowband senders such as banks. Had nothing to do with
> reputation sellers, and judging by a recent exit from the market a
> reputation is only as good as it is maintained.

That's my recollection as well.  I never saw any concerted or even accidental 
attempt to block, prevent, quash, overthrow or otherwise prevent policy work 
from being done.  I believe the original policy work was a victim of the fact 
that it's very hard to get such things right in this operational environment, 
and there was insufficient operational evidence to support some of the original 
proposals.  Ultimately, we simply couldn't reach consensus on the rich 
solutions people wanted.  That's very different from the conspiracy theories 
that have been alleged by a few ever since.

I also can't see the current language as endorsing any particular layer on top 
of DKIM.  Indeed, we've published an RFC that presents a (limited) policy 
solution, but have deliberately avoided doing any work on reputation at all.  
That seems to counter to what's being alleged here.

Finally, I'm a little tired of the notion that if a particular pet solution 
isn't the one that reached rough consensus, then the only possibility is that 
there's malice afoot.  The occasional incivility didn't help, but that's not 
the same thing as impropriety.  There are other possibilities one might 
consider as the reason something didn't make it into the RFCs.


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

Re: [ietf-dkim] ADSP stats

[Bill.Oxley]

In my mind the whole adsp degenerated into a use case only for well recognized 
narrowband senders such as banks. Had nothing to do with reputation sellers, 
and judging by a recent exit from the market a reputation is only as good as it 
is maintained

From: ietf-dkim-boun...@mipassoc.org [ietf-dkim-boun...@mipassoc.org] On Behalf 
Of J.D. Falk [jdfalk-li...@cybernothing.org]
Sent: Tuesday, April 19, 2011 4:08 PM
To: DKIM List
Subject: Re: [ietf-dkim] ADSP stats

On Apr 18, 2011, at 1:23 PM, Michael Thomas wrote:

> Murray S. Kucherawy wrote:
>> If ADSP is too weak or dangerous a protocol, and there are no current viable 
>> alternatives, then failing to beat the streets to get the industry to deploy 
>> it is an act of responsibility, not one of omission or laziness.
>
> My feeling is that it conflicts with too many (would-be) industry third 
> parties' self interest in
> selling reputation/policy, and hence why the FUD bullhorn was on full blast 
> through the entire
> exercise, and remains on to this day.

Could you provide some evidence of reputation/policy vendors spreading FUD 
about ADSP?  Press releases, blog posts, even links to mailing list archives.

It's possible that it happened, but if so I'd really like to know who was doing 
it.

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions


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

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

Re: [ietf-dkim] Working Group Last Call on 4871bis// A-label requirement

[John R. Levine]

> From a security aspect, DKIM should also acknowledge there are no A-Label 
> requirements for selectors and acknowledge the possibility that UTF-8 
> hostnames may resolve SMTP resources as well.

For reasons already discussed, no.  That's simply wrong.  Stop.

Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Working Group Last Call on 4871bis// A-label requirement

[Douglas Otis]

On 4/19/11 3:35 PM, John R. Levine wrote:
> Sorry, this message makes no sense.  The IETF has been working on 
> non-ASCII domain names and e-mail for over a decade, and we are 
> certainly not going to do random things that ignore that effort and 
> the many RFCs that describe the use of IDNs in the DNS.
The suggestion was to remove the MUST requirement to encode DKIM related 
domains within the header fields as A-labels.  This represents the wrong 
approach.

 From a security aspect, DKIM should also acknowledge there are no 
A-Label requirements for selectors and acknowledge the possibility that 
UTF-8 hostnames may resolve SMTP resources as well.

Lets review some of the RFCs then.

http://tools.ietf.org/html/rfc2277 section 2,
,---
Internationalization is for humans. This means that protocols are not
subject to internationalization; text strings are.
'---

http://tools.ietf.org/html/rfc5894#section-4.2
,---
The IDNA protocol does not
necessarily affect the interface between users and applications. An
IDNA-aware application can accept and display internationalized
domain names in two formats: as the internationalized character
set(s) supported by the application (i.e., an appropriate local
representation of a U-label) and as an A-label. Applications may
allow the display of A-labels, but are encouraged not to do so except
as an interface for special purposes, possibly for debugging, or to
cope with display limitations.
'---

http://tools.ietf.org/html/rfc2181#section-11
,---
The DNS itself places only one restriction on the particular
labels that can be used to identify resource records. That one
restriction relates to the length of the label and the full name.
The length of any one label is limited to between 1 and 63 octets.
A full domain name is limited to 255 octets (including the
separators). The zero length full name is defined as representing
the root of the DNS tree, and is typically written and displayed
as ".". Those restrictions aside, any binary string whatever can
be used as the label of any resource record. Similarly, any
binary string can serve as the value of any record that includes a
domain name as some or all of its value (SOA, NS, MX, PTR, CNAME,
and any others that may be added). Implementations of the DNS
protocols must not place any restrictions on the labels that can
be used.
'---

http://tols.ietf.org/html/rfc6055#section-3
,---
Shortly after the DNS Clarifications [RFC2181 
] and IETF character
sets and languages policy [RFC2277 ] 
were published, the need for
internationalized names within private namespaces (i.e., within
enterprises) arose. The current (and past, predating IDNA and the
prefixed ACE conventions) practice within enterprises that support
other languages is to put UTF-8 names in their internal DNS servers
in a private namespace. For example, "Using the UTF-8 Character Set
in the Domain Name System" [UTF8-DNS 
] was first written in 
1997, and
was then widely deployed in Windows. The use of UTF-8 names in DNS
was similarly implemented and deployed in Mac OS, simply by virtue of
the fact that applications blindly passed UTF-8 strings to the name
resolution APIs, the name resolution APIs blindly passed those UTF-8
strings to the DNS servers, and the DNS servers correctly answered
those queries. From the user's point of view, everything worked
properly without any special new code being written, except that
ASCII is matched case-insensitively whereas UTF-8 is not (although
some enterprise DNS servers reportedly attempt to do case-insensitive
matching on UTF-8 within private namespaces, an action that causes
other problems and violates a subsequent prohibition [RFC4343 
]).
Within a private namespace, and especially in light of the IETF UTF-8
policy [RFC2277 ], it was reasonable 
to assume that binary strings
were encoded in UTF-8.
'---

-Doug

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

Re: [ietf-dkim] Issue: Repeated headers

[J.D. Falk]

On Apr 19, 2011, at 3:55 PM, John R. Levine wrote:

>> I don't want to re-hash all the arguments.  What we have is a compromise 
>> between two hard-argued positions, and I think reopening it now will just 
>> drag everything out even longer.
> 
> I agree that the current language addresses the issue about as well as it 
> could be addressed, and see no advantage in rearguing it.

+1

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions


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

Re: [ietf-dkim] Working Group Last Call on 4871bis// A-label requirement

[John Levine]

>> Sorry, this message makes no sense.  The IETF has been working on non-ASCII 
>> domain names and
>e-mail for over a decade, and we are certainly not going to do random things 
>that ignore that
>effort and the many RFCs that describe the use of IDNs in the DNS.
>
>Sounds like what we actually need is some way to point to the relevant work 
>elsewhere in the
>IETF, even though it's apparently a moving target with many strong opinions 
>continuing to
>shove it in multiple directions.  Is it permissible to simply reference the 
>working group's
>tools page?

The current language references RFC 3490, my proposed change
references RFC 5890, which supersedes 3490.  The title of 5890 is
"Internationalized Domain Names for Applications (IDNA): Definitions
and Document Framework."

How much more of a pointer does anyone need?

R's,
John
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Issue: Repeated headers

[John R. Levine]

> I don't want to re-hash all the arguments.  What we have is a compromise 
> between two hard-argued positions, and I think reopening it now will just 
> drag everything out even longer.

I agree that the current language addresses the issue about as well as it 
could be addressed, and see no advantage in rearguing it.

Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Working Group Last Call on 4871bis// A-label requirement

[J.D. Falk]

On Apr 19, 2011, at 3:35 PM, John R. Levine wrote:

> Sorry, this message makes no sense.  The IETF has been working on non-ASCII 
> domain names and e-mail for over a decade, and we are certainly not going to 
> do random things that ignore that effort and the many RFCs that describe the 
> use of IDNs in the DNS.

Sounds like what we actually need is some way to point to the relevant work 
elsewhere in the IETF, even though it's apparently a moving target with many 
strong opinions continuing to shove it in multiple directions.  Is it 
permissible to simply reference the working group's tools page?

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions


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

Re: [ietf-dkim] Working Group Last Call on 4871bis// A-label requirement

[John R. Levine]

Sorry, this message makes no sense.  The IETF has been working on 
non-ASCII domain names and e-mail for over a decade, and we are certainly 
not going to do random things that ignore that effort and the many RFCs 
that describe the use of IDNs in the DNS.


R's,
John

On Tue, 19 Apr 2011, Douglas Otis wrote:


On 4/15/11 7:25 PM, John R. Levine wrote:

Instead, conversion to A-label form, or any other special encoding
required by a particular name-lookup protocol, should be done only by
an entity that knows which protocol will be used (e.g., the DNS
resolver, or getaddrinfo() upon deciding to pass the name to DNS),
rather than by general applications that call protocol-independent
name resolution APIs.


Wow. This change would both be incompatible with 4871, and would put 
non-ASCII 8-bit characters into DKIM-Signature: headers, thereby making 
them invalid under RFC 5322 and getting them smashed by any 7bit MTA.
A and  records serve as a discovery mechanism for SMTP rather than using 
MX records to ensure independence from DNS. For both OS X and Windows local 
name resolution services use UTF-8. Should email be expected to work between 
two hosts having non-ASCII host names resolved using UTF-8?


When SMTP allows the display of non-ASCII local-parts, the domain portion 
should also use UTF-8 as well. The DKIM verification process should therefore 
confirm the proper conversions. No one expects people to visually validate 
signatures, so why expect them to also validate puny-codes?


What does http://tools.ietf.org/html/rfc5321#section-2.3.5 say about FQDN. 
Would http://バスケ指導.meblog.biz/ qualify as a FQDN?___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Issue: Repeated headers

[Douglas Otis]

On 4/19/11 2:37 PM, Murray S. Kucherawy wrote:
>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
>> On Behalf Of Charles Lindsey
>> Sent: Tuesday, April 19, 2011 12:56 PM
>> To: DKIM
>> Subject: [ietf-dkim] Issue: Repeated headers
>>
>> Yes indeed. We discussed lots of wording for all of this, and the one that
>> has got into the document is about the worst.
> Where is your proposed alternate text?  Complaining without it isn't 
> especially helpful during a WGLC.
Here is mine. :^)

http://mipassoc.org/pipermail/ietf-dkim/2011q2/015838.html

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

Re: [ietf-dkim] Working Group Last Call on 4871bis// A-label requirement

[Douglas Otis]

On 4/15/11 7:25 PM, John R. Levine wrote:
>> Instead, conversion to A-label form, or any other special encoding
>> required by a particular name-lookup protocol, should be done only by
>> an entity that knows which protocol will be used (e.g., the DNS
>> resolver, or getaddrinfo() upon deciding to pass the name to DNS),
>> rather than by general applications that call protocol-independent
>> name resolution APIs.
>
> Wow. This change would both be incompatible with 4871, and would put 
> non-ASCII 8-bit characters into DKIM-Signature: headers, thereby 
> making them invalid under RFC 5322 and getting them smashed by any 
> 7bit MTA.
A and  records serve as a discovery mechanism for SMTP rather than 
using MX records to ensure independence from DNS. For both OS X and 
Windows local name resolution services use UTF-8. Should email be 
expected to work between two hosts having non-ASCII host names resolved 
using UTF-8?

When SMTP allows the display of non-ASCII local-parts, the domain 
portion should also use UTF-8 as well. The DKIM verification process 
should therefore confirm the proper conversions. No one expects people 
to visually validate signatures, so why expect them to also validate 
puny-codes?

What does http://tools.ietf.org/html/rfc5321#section-2.3.5 say about 
FQDN. Would http://バスケ指導.meblog.biz/ qualify as a FQDN?

-Doug


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

Re: [ietf-dkim] Issue: Repeated headers

[Murray S. Kucherawy]

> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
> On Behalf Of Charles Lindsey
> Sent: Tuesday, April 19, 2011 12:56 PM
> To: DKIM
> Subject: [ietf-dkim] Issue: Repeated headers
> 
> Yes indeed. We discussed lots of wording for all of this, and the one that
> has got into the document is about the worst.

Where is your proposed alternate text?  Complaining without it isn't especially 
helpful during a WGLC.

> It is Absolutely Pointless to check for minor infringements of 5233 et al,
> and so to say that implementors SHOULD check for some "reasonable" subset
> of infringements is ridiculous, unless you spell out what "reasonable"
> really implies. Now AFAICS, minor infringements in the format of
> particular headers etc, "naughty" as they might be, have no impact on
> DKIM. The "naughtiness" will be signed, so you can see whether it was
> present at signature time, if you happen to care about it.

I believe the added text adequately addresses this problem, especially the new 
Section 8.15.  I also believe that the chair has said we have rough consensus 
on this point.

> So if we are going to have normative language (such as SHOULD or MUST),
> then let us address it to the known problem, rather than to some vague
> "reasonable" test that might lead people to waste time on things that are
> not broken, and omit the one case that is broken.

We do have normative language, in 3.8.  And the text in 8.15 makes it clear 
what the attack is, and therefore what the "reasonable" defenses are.

> 1. What exactly do we really REALLY want implementors to do in this
> matter.?

I believe Sections 3.8 and 8.15 make this clear to anyone that's designing and 
implementing software in this area.

> 2. Is it to be a SHOULD or a MUST?

Given the RFC2119 definition, I think we've appropriately settled on SHOULD.

I don't want to re-hash all the arguments.  What we have is a compromise 
between two hard-argued positions, and I think reopening it now will just drag 
everything out even longer.

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

Re: [ietf-dkim] ADSP stats

[J.D. Falk]

On Apr 18, 2011, at 1:23 PM, Michael Thomas wrote:

> Murray S. Kucherawy wrote:
>> If ADSP is too weak or dangerous a protocol, and there are no current viable 
>> alternatives, then failing to beat the streets to get the industry to deploy 
>> it is an act of responsibility, not one of omission or laziness.
> 
> My feeling is that it conflicts with too many (would-be) industry third 
> parties' self interest in
> selling reputation/policy, and hence why the FUD bullhorn was on full blast 
> through the entire
> exercise, and remains on to this day.

Could you provide some evidence of reputation/policy vendors spreading FUD 
about ADSP?  Press releases, blog posts, even links to mailing list archives.

It's possible that it happened, but if so I'd really like to know who was doing 
it.

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions


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

Re: [ietf-dkim] I-D Action:draft-ietf-dkim-rfc4871bis-06.txt // Input requirements

[Charles Lindsey]

On Sun, 17 Apr 2011 16:23:31 +0100, Barry Leiba   
wrote:

>> additional discussion and references.  In addition, verifiers MUST
>> ensure the presence of multiple singleton originating header fields
>> do not provide a valid signature result.
>> ---
>>
>> Not including this additional requirement removes recipient assurances a
>> sender may have expected to be offered by DKIM.
>
> Yes; we discussed this to death and consensus was against saying that.
>  Your objection to the consensus is noted; nevertheless, we do have
> rough consensus.

Not really. There was so much misunderstanding of the problem, and so many  
texts proposed, that it is entirely unclear as to exactly what the final  
consensus was. For sure, the wording that finally arrived is about as  
unhelpful to the implementor as it could be.

-- 
Charles H. Lindsey -At Home, doing my own thing
Tel: +44 161 436 6131   
   Web: http://www.cs.man.ac.uk/~chl
Email: c...@clerew.man.ac.uk  Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9  Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

[ietf-dkim] Issue: Repeated headers

[Charles Lindsey]

On Sat, 16 Apr 2011 01:05:02 +0100, Douglas Otis   
wrote:

> http://tools.ietf.org/html/draft-ietf-dkim-rfc4871bis-06#section-3.8
> ,---
> DKIM's design is predicated on valid input. Therefore, signers and
> verifiers SHOULD take reasonable steps to ensure that the messages
> they are processing are valid according to [RFC5322
> ], [RFC2045
> ], and
> any other relevant message format standards. See Section 8.15
>   
> for
> additional discussion and references.
> '---
>
> Should change to:
> ---
> DKIM's design is predicated on valid input. Therefore, signers and
> verifiers SHOULD take reasonable steps to ensure that the messages
> they are processing are valid according to [RFC5322
> ], [RFC2045
> ], and
> any other relevant message format standards. See Section 8.15
>   
> for
> additional discussion and references.  In addition, verifiers MUST
> ensure the presence of multiple singleton originating header fields
> do not provide a valid signature result.

Yes indeed. We discussed lots of wording for all of this, and the one that  
has got into the document is about the worst.

It is Absolutely Pointless to check for minor infringements of 5233 et al,  
and so to say that implementors SHOULD check for some "reasonable" subset  
of infringements is ridiculous, unless you spell out what "reasonable"  
really implies. Now AFAICS, minor infringements in the format of  
particular headers etc, "naughty" as they might be, have no impact on  
DKIM. The "naughtiness" will be signed, so you can see whether it was  
present at signature time, if you happen to care about it.

But there is just ONE breach of 5322 (so far as we know) that is serious  
enough to break DKIM completely. And that is repeated headers that should  
not be repeated. A number of scams involving repeated From headers have  
been described, and one can well imagine there may be scams with repeating  
Subject, Content-Type, Message-ID and whatever else (and if you are going  
to catch one, then catching the others with the same code has negligible  
additional cost).

So if we are going to have normative language (such as SHOULD or MUST),  
then let us address it to the known problem, rather than to some vague  
"reasonable" test that might lead people to waste time on things that are  
not broken, and omit the one case that is broken.

Moreover, when it comes to a choice between SHOULD and MUST, the narrower  
the test you are asking for, the easier it is to justify a MUST wording.

So there are just two questions to ask:

1. What exactly do we really REALLY want implementors to do in this  
matter.?

2. Is it to be a SHOULD or a MUST?

Note that I have escalated this to as Issue. DKIM is broken if we do not  
get this right.

-- 
Charles H. Lindsey -At Home, doing my own thing
Tel: +44 161 436 6131   
   Web: http://www.cs.man.ac.uk/~chl
Email: c...@clerew.man.ac.uk  Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9  Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Review of: draft-ietf-dkim-mailinglists-06

[John R. Levine]

> How about "DKIM-Cooperative"?

I'd suggest DKIM aware, unless you think there are list operators who are 
actively DKIM hostile.

>> {{ I'd have thought that citing the l= capability here would be appropriate, 
>> for
>> completeness. }}
>
> I think it was there in earlier versions but was removed because the WG 
> generally dislikes use of "l=" for the reasons specified in the base 
> document.  It also only handles appended text, but not prepended text, 
> for example.

Please leave it out -- the cases it covers are such a small fraction of 
the ways that a list will break a signature that it just confuses the 
issue.

>> >If an author knows that the MLM to which a message is being sent is a
>> >non-participating resending MLM, the author SHOULD be cautious when
>> >deciding whether or not to send to the list when that mail would be

I'd prefer taking entire section out, unless we want to make a deep dive 
into the swamp of offering advice to work around the ways we think that 
other people's software is broken.  Just sign your fripping mail.

>> >arrives via a list to a verifier that applies ADSP checks which fail,
>> >the message SHOULD either be discarded (i.e. accept the message at
>> >the [SMTP] level but discard it without delivery) or rejected by
>>
>> {{ Is this describing anything different than would/should take place for 
>> mail
>> that did NOT go througha list?  The text seems to be describing a special 
>> case
>> but in fact it isn't.  It's just an ADSP failure. }}

The alternative suggestion is that if it has a sufficiently credible 
signature, accept it and forget about ADSP.  See above-mentioned swamp.

>> {{all messages are from the author.  what distinctive condition is this 
>> trying
>> to describe?  messages signed with the author domain?  I don't understand the
>> point of the "As such" sentence.  The rest of the paragraph is also 
>> confusing to
>> me.  I'm not sure what to suggest to make it clearer. }}
>
> This came from a use case John submitted.
>
> A and C are subscribed to B.  A sends to B, which goes to C.  But C 
> doesn't want to be on the list anymore and can't seem to unsubscribe. 
> In frustration, C begins reporting B traffic as spam, which begins to 
> negatively affect the reputation of A's signed mail.

I definitely get FBL reports from Yahoo for mail I've sent to lists.  It's 
really not an author issue as much as an original ADMD vs. list's ADMD 
issue.

Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Review of: draft-ietf-dkim-mailinglists-06

[Murray S. Kucherawy]

Thanks for the thorough review.  I've only replied below to stuff that warrants 
more than an "OK" or other indication of agreement.

>  > 2.3.  'DKIM-Friendly'
>  >
>  >The term "DKIM-Friendly" is used to describe an email
> intermediary
>  >that, when handling a message, makes no changes to that message
> which
>  >cause valid [DKIM] signatures present on the message on input to
> fail
>  >to verify on output.
>  >
>  >Various features of MTAs and MLMs seen as helpful to users often
> have
>  >side effects that do render DKIM signatures unverifiable.  These
>  >would not qualify for this label.
>
> {{ stray thought:  since the real concern is breakage, wouldn't it make
> sense to
> focus on DKIM-Hostile, rather than DKIM-Friendly?  Friendly largely
> means being
> passive. }}

How about "DKIM-Cooperative"?

(Largely because flipping the logic throughout the work might be a lot of 
work...)

>  > 3.  Mailing Lists and DKIM
>  >
>  >It is important to make some distinctions among different MLM- like
>  >agents, their typical implementations, and the impacts they have in a
>
> MLM-like agents -> intermediaries.
>
> {{ what does 'MLM-like' mean? }}

Specifically, intermediaries that mess with the envelope, typically changing 
one recipient to many, and possibly altering the content.

>  >DKIM-aware environment.
>  >
>  > 3.1.  Roles and Realities
>  >
>  >In DKIM parlance, there are several key roles in the transit of a
>
> In DKIM parlance, -> Across DKIM activities,
>
> {{ generic flag is raised:  having this document repeat definitions from other
> documents invites divergence. }}
>
>
>  >message.  Most of these are defined in [EMAIL-ARCH].
>  >
>  >author:  The agent that provided the content of the message being
>  >   sent through the system, and performed the initial submission.
>
> {{ And indeed, here's an example of divergence.  In email-arch, the author 
> does
> not (necessarily) perform submission.  Submission is performed by the
> Originator, in email-arch... }}

How does content get from an author to an originator?  Or are they typically 
the same agent?

Is it sufficient to change "performed" to "handed it to the originator to begin 
its travel to its destination(s)"?

>  >   This can be a human using an MUA or a common system utility such
>  >   as "cron", etc.
>  >
>  >originator:  The agent that accepts a message from the author,
>  >   ensures it conforms to the relevant standards such as [MAIL], and
>  >   then relays it toward its destination(s).  This is often referred
>  >   to as the Mail Submission Agent (MSA).
>
> {{ "relays it towards its destinations" is more like the definition of a...
> relay. }}

So change "relays" to "sends" or "routes"?

>  >receiver:  The agent that is the final transit relay for the message
>  >   prior to being delivered to the recipient(s) of the message.
>  >   Filtering decisions based on results made by the verifier could be
>  >   applied by the receiver.  The verifier and the receiver could be
>  >   the same agent.
>
> {{ email-arch: "2.2.4. Receiver  The Receiver performs final delivery" }}

Those read the same to me.  Are you proposing a change here?

>  >Minor body changes:  Some lists prepend or append a few lines to each
>  >   message to remind subscribers of an administrative URL for
>  >   subscription issues, or of list policy, etc.  Changes to the body
>  >   will alter the body hash computed at the DKIM verifier, so these
>  >   will render any existing signatures that cover those portions of
>  >   the message body unverifiable.
>
> {{ I'd have thought that citing the l= capability here would be appropriate, 
> for
> completeness. }}

I think it was there in earlier versions but was removed because the WG 
generally dislikes use of "l=" for the reasons specified in the base document.  
It also only handles appended text, but not prepended text, for example.

>  > 4.1.  Author-Related Signing
>  >
>  >If an author knows that the MLM to which a message is being sent is a
>  >non-participating resending MLM, the author SHOULD be cautious when
>  >deciding whether or not to send to the list when that mail would be
>
> {{ I don't know what to suggest, but this section presumes that we can
> reasonably expect authors to know about DKIM issues and in particular to know
> that some MLMs screw up signatures.  But we already know that virtually no
> author is aware of any of these issues, nevermind know what it means to be
> 'cautious'.  Mumble. }}

Later on in Section 4.1, there's this:

   However, all of this presupposes a level of infrastructure
   understanding that is not expected to be common.  Thus, it will be
   incumbent upon site administrators to consider how support of users
   wishing to participate in mailing lists might be accomplished as DKIM
   achieves wider adoption.

>  > 4.4.  Wrapping A Non-