Dave CROCKER wrote:
On 5/9/2011 7:40 AM, MH Michael Hammer (5304) wrote:
I'd like to request that we specifically test for consensus on
deprecating "l=" through the usual +1/-1 approach. No miring, just a
vote.
This isn't my vote, but a comment:
Oddly, I'm finding myself coming to believe that its use within
a coordinated template for mediators might actually being helpful.
+1
This assumes, of course, that the template can be specified and
gain consensus, and that signers, verifiers and mediators all are
willing to implement it. Hence, this path involves significant effort.
One could argue that it's cleaner to drop it now and explore
re-introducing it in the effort to develop that template.
It is really just a matter of defining the current practical use cases
today, highlighting it is only useful under limited cases.
From a functional standpoint, the only purpose for the body length
tag (LTAG) is when the author domain has a desire and intent to
maintain the author's organization branding presence and originating
message integrity by allowing for additional text to be added and with
a no failure expectation, targeted at an intermediary with known
behaviors.
However, the problem with LTAG is that it is not the only
consideration and without target information, insufficient to maintain
an expectation for survival.
In other words, from a technical standpoint, a consideration to use
LTAG must come with other DKIM related factors:
- Knowing the intermediary behavior,
- Knowing what headers to sign, and
- Knowing what content to avoid.
For example, in our MLM, the default options for creating a new list are:
[X] Add Footer [...]
[_] Add Header, if defined [...]
[X] Use [list-name] tag in Subject: line
[X] Add/Alter Reply-To set to list address
[X] Keep Original To:
[_] Strip Attachments. Exceptions [...]
[X] Strip HTML
[X] Add List-* Headers
[_] Strip Dangerous HTML, Javascript code
[_] DKIM Options
[_] List only accepted valid DKIM submissions
[X] Reject Restrictive ADSP Domains
[X] Verify
[X] Report
[X] Sign
[X] Strip original signatures
If a member knew how the targeted list distribution behaved, he would
then know how to 100% survive sending DKIM signed mail with signing
options:
- Enable "l=" tag
- Do not sign headers: Subject and Reply-to
- Create only text/plain text
He can also survive it with DKIM options set:
[X] DKIM Options
[_] List only accepted valid DKIM submissions
[X] Reject Restrictive ADSP Domains
[X] Verify
[X] Report
[X] Sign
[_] Strip original signatures
thus ending up with two valid signatures.
But if he also knew the message signature will be stripped and message
resigned and was was ok with the the 3rd party signature, they
probably may see they don't need sign mail unless the list required it.
So much of this has to do with the business use cases for the author
domaina the DKIM signing service providers and how they are able to
expose that information in general or contractual.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html