Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)
> specification. For this reason, I am formally proposing that the i= tag > and supporting text be removed from 4871bis. Gosh Jim, you're probably not surprised when I say +1 to that :-) While the i=/g= were attempting to solve problems, I agree that the spec has moved on and simplifying to just d= has considerable crispness. As for the other follow-up, I am not aware of Yahoo using i= as a discriminator. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)
I had the feeling that Y! was using the local part of i= to do differentiation in reputation. ie various streams within the same domain. I know the spec intent recommends, different domains for different streams, but then Intuition would tell me, that few people are willing (or understand) to have different domains for different streams. - Original Message - From: "Jim Fenton" To: "IETF DKIM WG" Sent: Friday, 1 April, 2011 9:33:51 AM Subject: [ietf-dkim] Proposal: Removal of AUID (i= tag/value) The direction of the DKIM specifications since RFC 4871 have been to rely less and less on the AUID (agent or user identifier, the i= value on the signature) to the point that it provides no security benefit. On the other hand, a malformed AUID can cause a DKIM signature not to verify, and i= currently adds to the complexity of the DKIM specification. For this reason, I am formally proposing that the i= tag and supporting text be removed from 4871bis. Comments, please. -Jim ___ 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
[ietf-dkim] Proposal: Removal of AUID (i= tag/value)
The direction of the DKIM specifications since RFC 4871 have been to rely less and less on the AUID (agent or user identifier, the i= value on the signature) to the point that it provides no security benefit. On the other hand, a malformed AUID can cause a DKIM signature not to verify, and i= currently adds to the complexity of the DKIM specification. For this reason, I am formally proposing that the i= tag and supporting text be removed from 4871bis. i= was introduced in RFC 4871 as a mechanism to: (1) Allow a parent domain to sign for a subdomain, simplifying the management of keys. So if example.com had several subdomains and wanted to use the same keys to sign for all of them, it could put the actual domain name being used in the i= value (e.g., marketing.example.com) and the location where the keys were stored in the d= value (e.g., example.com). (2) Support finer-grained verification in conjunction with the g= tag/value in the key record. We have already decided to remove the g= tag/value in 4871bis. (3) Support matching with the From address to determine if a signature was an Author Signature in SSP. SSP became ADSP, and WG consensus was to match the domain of the From address against the SDID instead. In order to remove i= from the specification, we need to: - Remove section 2.6 (definition) - Remove i= tag definition from 3.5 - Remove i= from example at the end of 3.5 - Remove "s" flag from t= tag definition in 3.6 - Remove section 3.9 (Signing by Parent Domains) - Remove section 3.10 (relationship between SDID and AUID) or change it to reflect SDID-only information - Remove reference to i= tag in 6.1.1 paragraph 5 - Remove section 8.13 (Inappropriate Signing by Parent Domains) - Remove i= from examples in A.2 and A.3 - Change IANA registries to retain i= tag in signature and "s" flag in key record as deprecated That's what I could find, but I may have missed something. In a conversation with Dave Crocker and Murray Kucherawy, they noted the use of the local part of i= as an opaque identifier. Its use as such an identifier is not described in any standard, but the relaxation of the current restrictions on the use of i= (that the domain-part be a subdomain of d=, etc.) would result in an incompatibility with RFC 4871-compliant verifiers. It is, however, possible to remove it entirely without creating a compatibility problem. Comments, please. -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] mipassoc site is down?
It looks like the IPv6 address for mipassoc.org isn't working, although the IPv4 address is. -Jim On 3/31/11 1:26 AM, Dave CROCKER wrote: > if you folks get this message, the problem must be fixed... > > sorry for the hiccup. > > d/ > > On 3/31/2011 4:24 AM, Franck Martin wrote: >> telnet mipassoc.org 80 >> Trying 2001:470:1:76:::4834:7146... >> telnet: connect to address 2001:470:1:76:::4834:7146: Host is down >> Trying 72.52.113.70... >> Connected to mipassoc.org. >> >> and in my browser http://mipassoc.org/ returns a blank page (connects but >> result >> is blank page). > ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] If DKIM would ignore [] at the beginning of the subject line
J.D. Falk wrote:
> On Mar 31, 2011, at 8:51 AM, Al Iverson wrote:
>
>>> I think the MLM document makes all of this stuff pretty clear already.
>> It does to me; it seems like dropping the original signature and
>> signing with the list manager site signature is the appropriate way to
>> go.
>
> Yup. The problem isn't that we haven't made this advice public (though
> it may carry more weight after last call.) The problem is that it takes a
> long time for these ideas to disseminate to all list software deployed
> everywhere -- especially the outdated versions of MailMan that many sites
> run on autopilot.
>
> FWIW, here's how I got DKIM signatures on messages resent by the lists
> I host with MailMan two years ago, without needing to wait for MailMan
> to update anything at all:
>
> http://www.circleid.com/posts/dkim_for_discussion_lists/
This is cool J.D.
The DKIM integration for our MLS was very simple and the outline I
provided in DSAP (ideas covered in MLM as well) was written with the
idea for a minimal software design, no failure points promoted by the
changes and simply plug and play with existing software. It had only
two MLS change considerations:
- Restrict POLICY restricted domains as part of the list subscription
process. At the time DSAP was written, this meant disallow
subscription
for a domain using an exclusive signing practice which included a
3rd party signing restriction. If the policy allowed 3rd party
signers
to exist, then the user was allowed to join the list.
- If mail changes will be done, strip old signatures and resign the
message before redistribution.
We finally added this logic last year and the only MLS change was to
add the subscription logic because we designed the framework for
signing is done on the outbound MTA server.
The big change item I originally expected would need to be done in the
MLS adding new DKIM signing options per list turned out to be
unnecessary. We avoided this big software by using the common list
template file used to add additional headers such as all the LIST-*
headers. I used a META header to trigger when a list should be signed.
For example, the template file has:
List-Id: {LT} <{LN}.{LD}>
List-Post:
List-Unsubscribe:
List-Subscribe:
List-Help:
WCLS-Signthis: {LD}
So the MLS will do its normal thing of preparing a list distribution,
adding the list-* headers carrying the meta header WLCS-SIGNTHIS:
expanded with the list domain. When the outbound MTA gets this
internal feed, it looks for this meta header, extracts the
list-domain, checks another setup file to signing options for the
list-domain, if any. If found, any header striping options are
followed and the list message message is signed.
So I guess the point is that you can make a MLS DKIM aware by using
meta headers to current setup files and using that information as feed
for edge software.
-
Sincerely
Hector Santos
http://www.santronics.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] If DKIM would ignore [] at the beginning of the subject line
> FWIW, here's how I got DKIM signatures on messages resent by the lists I host > with MailMan two years ago, without needing to wait for MailMan to update > anything at all: Yup. In most cases, it's really not hard to either tell the MTA to add a signature on the way out, or use a signing shim between the list manager and the MTA. I did the latter with mj2, works great. 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] If DKIM would ignore [] at the beginning of the subject line
On Mar 31, 2011, at 8:51 AM, Al Iverson wrote: >> I think the MLM document makes all of this stuff pretty clear already. > > It does to me; it seems like dropping the original signature and > signing with the list manager site signature is the appropriate way to > go. Yup. The problem isn't that we haven't made this advice public (though it may carry more weight after last call.) The problem is that it takes a long time for these ideas to disseminate to all list software deployed everywhere -- especially the outdated versions of MailMan that many sites run on autopilot. FWIW, here's how I got DKIM signatures on messages resent by the lists I host with MailMan two years ago, without needing to wait for MailMan to update anything at all: http://www.circleid.com/posts/dkim_for_discussion_lists/ -- 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] If DKIM would ignore [] at the beginning of the subject line
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of Al Iverson > Sent: Thursday, March 31, 2011 11:52 AM > To: > Subject: Re: [ietf-dkim] If DKIM would ignore [] at the beginning of > the subject line > > On Thu, Mar 31, 2011 at 6:58 AM, Murray S. Kucherawy > wrote: > > > That's also something we considered when talking to the Mailman > people. But again, this is really a small percentage of what causes > author signatures on list mail to break. > > > >> Anyway, the list should be signing messages after adding subject > line > >> prefixes, and after adding body footers. It's the list's signature, > and > >> the list's reputation that need to be assessed by the recipient. > There > >> are many other modifications that a list might make (like stripping > >> attachments, body prefixes, and so on) that would make l= useless. > > > > I think the MLM document makes all of this stuff pretty clear > already. > > It does to me; it seems like dropping the original signature and > signing with the list manager site signature is the appropriate way to > go. I don't think I'd want to know that there is a use case where my > DKIM signature still passes after somebody modified headers. Good > intent aside, I see it being used for bad purposes too easily. > > If you're worried about DKIM signing spam sent to the list address, > then that's a bit of a different problem, and it has a different, > non-DKIM-related solution. > > Cheers, > Al Iverson > +1 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] If DKIM would ignore [] at the beginning of the subject line
Franck Martin wrote: > Silly question (?): > > Knowing that many mailing lists add [topic] at the beginning of the Subject > line, > what if DKIM was set to ignore that part when signing/verifying? > > Would it help to solve the problem of broken signature thru mailing lists? > > I realize the issue would be to also detect the add footer, but if I recall > you can specify in dkim to sign only a certain length of the body and not > the whole body. So are you proposing changes or a BCP for DKIM signing and verification? DKIM Signer Tips: - When signing messages targeted for a mailing list, you MAY consider using the l= tag to increase the survival rate of the message list distribution when a list footer as the only change to the body integrity. SECURITY NOTE: Please keep in mind there are replay exploits potentials with l= body length usage. DKIM Verifier Tips: - If a signature fails to validate, you MAY consider retesting to see if the failure was related to a subject line modified with [LIST-NAME] tag. Strip the tag and retest. You might also check if the z= tag is available with the original Subject: header value But what about the other passive MLS-based mail tampering abeit industry-acceptable change options possible such stripping attachments, stripping HTML mime parts? For our MLS software DKIM integration, I followed the expired DSAP proposed recommendations to first make sure there are no POLICY based restrictions and to exclude list membership for these domains. An example can be seen at this subscription page showing the ADSP Restriction warning: http://www.winserver.com/public/code/html-subscribe?list=list-dkim Try subscribing with any ADSP restricted domain email address, such as my test CatInTheBox.Net domain which has a DNS ADSP TXT record DKIM=DISCARDABLE and you will see a subscription deny response. But once the member is allowed, we are doing the basic list submission mechanics of: - Verify original signature(s), - Add verification results with A-R header(s), - Modify/prepare message based on list option, which include - Strip original signature(s), - Resign with signer domain defined for the list, - Perform Distribution, there is no expectation of DKIM-related failure related to ADSP policies or related to broken original signatures. One of the outcomes this was the suggestion of a new list option that basically offers an option such as: [_] Keep Original Mail Integrity I like the idea because it is really a DKIM independent concept to offer list distribution features that are not alter list mail in any way. But in a new DKIM aware mail environment, this "no mail tampering" list option can apply very well for a list with resigning or no resigning scenarios where retaining original mail signature(s) are desired. The only change when resigning is the creation of a new signature which technically should not fail a DKIM verifier. The main point I would like to stress is that we really need to begin to make DKIM something that is WORTH processing with well established conditions for GOOD and BAD mail filtering and reduced all the constant fuzzy mail designs that only continue to produce indeterminate results. All that means is that if a domain is really seriously concern about its DKIM signed mail survivability and minimize all failures then the domain should avoid submitting these domain messages to "Meat Grinders" such as a MLS well known to operate with industry-accepted mail tampering features. Higher survivability can only begin to occur as the MLS software are made DKIM aware. I suggest there will continue exist older legacy software and most likely for many years. But new or old, you will always need to be aware of the list operating behavior and what it does for DKIM directly or indirectly. In all cases, you are just putting your domain, brand and reputation at risk if you sign your mail with an expectation they will have a high survivability rate. IMV, the reason there is seems to be a continue aura of unsureness for DKIM is because we still have many failure conditions the DKIM Signer Domain Assessment model can not address. It doesn't even address the NO SIGNATURE scenario. So we left with limited DKIM utility where the only message to consider is one DKIM signed by a trusted source. Anything else has an indeterminate status. All that means is I don't think it helps domain if it is going to go against this GOOD MAIL only idea by submitting signed mail to a list expecting it to survive when there is no current way to know what that list is going to do and the odds are very high it will break your original integrity. At best, is for the author domain to be aware that list signer domain will take responsible for your copyrighted message by resigning it. -- Hector Santos, CTO http:/
Re: [ietf-dkim] If DKIM would ignore [] at the beginning of the subject line
On Thu, Mar 31, 2011 at 6:58 AM, Murray S. Kucherawy wrote: > That's also something we considered when talking to the Mailman people. But > again, this is really a small percentage of what causes author signatures on > list mail to break. > >> Anyway, the list should be signing messages after adding subject line >> prefixes, and after adding body footers. It's the list's signature, and >> the list's reputation that need to be assessed by the recipient. There >> are many other modifications that a list might make (like stripping >> attachments, body prefixes, and so on) that would make l= useless. > > I think the MLM document makes all of this stuff pretty clear already. It does to me; it seems like dropping the original signature and signing with the list manager site signature is the appropriate way to go. I don't think I'd want to know that there is a use case where my DKIM signature still passes after somebody modified headers. Good intent aside, I see it being used for bad purposes too easily. If you're worried about DKIM signing spam sent to the list address, then that's a bit of a different problem, and it has a different, non-DKIM-related solution. Cheers, Al Iverson ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-04
On 3/31/2011 5:49 AM, Jim Fenton wrote: > On 3/29/11 4:53 AM, Dave CROCKER wrote: >> Just to be clear: A domain name is capable of being author-specific. I >> recognize that it's not typical, but the construct of 'author' is so >> fundamental in this game, it's worth acknowledging that it is (still) >> permitted. > > With the output of DKIM being the SDID, the identity associated with the > signature is of course that of the domain. But when my author-specific > domain signs a message for me, it's the domain that does that -- it doesn't > matter that it's an organization of one. This confuses the actor with the identifier for the actor. The "domain" does not do signing. The actor does the signing. They use the domain name as an identifier. The actor might be an author, identifying themself (themselves?) or the actor might be an organization. In other words, the semantics and the activity are as I described. > Putting "author" here just hints that authors might sign messages as well, > and I don't think that's intended. I suggest removing "author" to make that > clear. It is not meant to "hint" at that. It is meant to call it out explicitly. There are configurations for using DKIM that are not in the main line of thinking but are nonetheless entirely reasonable and legal to explore using and could be quite constructive to employ. Text that introduces or otherwise describes a mechanism's capabilities should be careful to give a good sense of the range, rather than directing everyone only to the most common case, or rather the most common case that is expect. Besides helping to educate readers, this reminds folks who later seek to modify the spec that they need to be careful not to (unintentionally) impose restrictions that eliminate these previously-legal scenarios. Please note that this exchange is about non-normative, pedagogical text. >> . Goodmail .. . . V V Client -> Mail -> >> Transfer -> Service -> Receiver -> Recipient >> >> Goodmail interacted with the creator of the document and, separately, with >> the receiving mail service, as an adjunct "back office" service. To repeat: >> /It was not in the direct handling path./ >> >> DKIM supports that mode of operation quite nicely and it is a particularly >> powerful operational mode, so it is worth keeping that "configuration" in >> mind explicitly. Given how persistent this confusion seems to be it might >> even be worth more language, though I'm not coming up with a suggestion, >> offhand. > > This still seems to me to be too specialized a use case to list in the > specification, but would look to WG consensus on which way to go here. Indeed, working group consensus controls wg choice. >>> The potential for misinterpretation of this is greater than the benefit >>> of explaining this potential usage scenario, especially since >>> "assessment" has a very specific definition in the DKIM context. >> >> I think we've just seen a good example that indeed it is easily >> misunderstood. That begs explicit reference, not potentially confusing >> conflation. > > Can you offer alternate text that avoids the overloading of the word > "assessment"? Sorry, no I can't. I am not seeing the problem that you are, which makes me a poor choice for guessing how to satisfy your concern. Again note that this is non-normative text. > 6.3 paragraph 5 has changed "signing identity" to SDID. The signing > identity really corresponds to the AUID. ... In fact, the AUID is not part of DKIM's formal output. So the formal specification cannot then direct it be supplied to the assessment engine. >>> >>> Nevertheless, suppose a message with From address >>> was properly signed with >>> i=marketing.example.com and d=example.com. What the >> >> Your example has d= using a 'parent' domain, not a sub-domain. Your >> following discussion refers to aspects of the spec that concern sub-domains >> and I am not understanding how the example is relevant to it. Yes, I see >> that i= has a subdomain but, again, I don't see how that relates to your >> comments. > > Yes, d= is a parent domain, signing for a subdomain. DKIM has no concept of "signing for a subdomain. d= is d=. It is what is used to sign and verify. The only semantics are that it is the identifier to be delivered as payload and used for assessment. While, yes, one might be able to observe various details about it and i=, there is no standardized semantic about it and i= is not officially payload. > The point is that the choice of i= had determined whether something ought to > be flagged to the recipient. Now it doesn't. That is a behavioral change that > is potentially incompatible with the RFC 4871 behavior. The rule for i= is indeed that its domain must be the same as d= or may be a subdomain is nice, but this doesn't wind up meaning much. In particular, it means nothing at all for the recipient, because we never specified a meaning. You are t
Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-04
>With the output of DKIM being the SDID, the identity associated with the >signature is of course that of the domain. But when my author-specific >domain signs a message for me, it's the domain that does that -- it >doesn't matter that it's an organization of one. Putting "author" here >just hints that authors might sign messages as well, and I don't think >that's intended. I suggest removing "author" to make that clear. The author can be an organization. For mail from ESPs, I'd say that the author is almost always an organization. Please leave the language alone. >> DKIM supports that mode of operation quite nicely and it is a >> particularly powerful operational mode, so it is worth keeping that >> "configuration" in mind explicitly. Given how persistent this >> confusion seems to be it might even be worth more language, though I'm >> not coming up with a suggestion, offhand. > >This still seems to me to be too specialized a use case to list in the >specification, but would look to WG consensus on which way to go here. I can easily see applications in universities, where the central IT group often has only a tenuous hold over the departments who jealously guard their autonomy, often well past any point of rationality. A department wouldn't dream of sending their mail through the servers run by those bureaucratic morons in central IT, but would be OK with a remote signer where the mail stays on their computers. >The point is that the choice of i= had determined whether something >ought to be flagged to the recipient. Now it doesn't. That is a >behavioral change that is potentially incompatible with the RFC 4871 >behavior. "Flagged to the recipient" is UI design advice, which I think we've agreed we're not doing. >> "The Signer MAY choose to use the same namespace for its AUIDs as >> its users' email addresses or MAY choose other means of representing >> its users. However, the signer SHOULD use the same AUID for each >> message intended to be evaluated as being within the same sphere of >> responsibility, if it wishes to offer receivers the option of using >> the AUID as a stable identifier that is finer grained than the SDID." >> >> I suggest that the first sentence change MAY to "might" in order to >> make it non-normative. > >I really don't think changing MAY to "might" here is going to make >things any clearer for implementers. Much the opposite. Agree. Let's leave it alone. >(radical idea alert) >The point is that if the AUID does not affect the result of the >verification at all, why even have it? In my case, it's a comment that helps me figure out what happened when someone sends back a message with a complaint. I would be quite happy to change i= to be a private comment for the benefit of the signer and remove any syntactic restrictions on it. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] the alleged list problem, was If DKIM would ignore
>Anyway, the list should be signing messages after adding subject line >prefixes, and after adding body footers. It's the list's signature, >and the list's reputation that need to be assessed by the >recipient. There are many other modifications that a list might make >(like stripping attachments, body prefixes, and so on) that would >make l= useless. Quite right. It would be helpful to me if people could explain what problem they're trying to solve when they bring up mailing lists yet again. "Some lists break submitters' signatures" is a fact, not a problem. "I am trying to do X with my list mail, but I can't so I have to do Y instead" would be a problem. R's, John PS: "Someone might want to do Q, W, and J, even though nobody's ever wanted to do it before" is definitely not a problem. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] If DKIM would ignore [] at the beginning of the subject line
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Ian Eiloart > Sent: Thursday, March 31, 2011 3:45 AM > To: Franck Martin > Cc: > Subject: Re: [ietf-dkim] If DKIM would ignore [] at the beginning of > the subject line > > That's an implementation issue for verifiers, isn't it? If an rfc were > to say anything at all, it might say that mailing lists will often > break header signatures by prefixing the subject line. If a verifier > finds a [] prefix and broken signature, it might like to try verifying > a signature formed without that part of the subject line. It might also > want to limit the number of characters in the prefix. And, it might > like to keep a track of prefixes used with specific List-ID headers, to > spot attempts to abuse this flexibility. There was pretty solid consensus against doing things like this in the past. There was similarly solid consensus against trying to verify a signature using the "z=" header fields if they're present. I believe we decided an implementation does so outside of DKIM's scope, and at its own peril; DKIM has to return a failure, but what you do after that is up to you. > I suppose some guidance as to what might be acceptable in the prefix > might be warranted. You could, for example, restrict it to substrings > of the (also signed) List-ID header. That would severely limit replay > attacks. That's also something we considered when talking to the Mailman people. But again, this is really a small percentage of what causes author signatures on list mail to break. > Anyway, the list should be signing messages after adding subject line > prefixes, and after adding body footers. It's the list's signature, and > the list's reputation that need to be assessed by the recipient. There > are many other modifications that a list might make (like stripping > attachments, body prefixes, and so on) that would make l= useless. I think the MLM document makes all of this stuff pretty clear already. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] If DKIM would ignore [] at the beginning of the subject line
On 31 Mar 2011, at 03:16, Franck Martin wrote: > Silly question (?): > > Knowing that many mailing lists add [topic] at the beginning of the Subject > line, what if DKIM was set to ignore that part when signing/verifying? That's an implementation issue for verifiers, isn't it? If an rfc were to say anything at all, it might say that mailing lists will often break header signatures by prefixing the subject line. If a verifier finds a [] prefix and broken signature, it might like to try verifying a signature formed without that part of the subject line. It might also want to limit the number of characters in the prefix. And, it might like to keep a track of prefixes used with specific List-ID headers, to spot attempts to abuse this flexibility. I suppose some guidance as to what might be acceptable in the prefix might be warranted. You could, for example, restrict it to substrings of the (also signed) List-ID header. That would severely limit replay attacks. Anyway, the list should be signing messages after adding subject line prefixes, and after adding body footers. It's the list's signature, and the list's reputation that need to be assessed by the recipient. There are many other modifications that a list might make (like stripping attachments, body prefixes, and so on) that would make l= useless. > Would it help to solve the problem of broken signature thru mailing lists? > > I realize the issue would be to also detect the add footer, but if I recall > you can specify in dkim to sign only a certain length of the body and not the > whole body. > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-04
On Mar 30, 2011, at 11:49 PM, Jim Fenton wrote: >> . Goodmail .. >> . . >> V V >> Client -> Mail -> Transfer -> Service -> Receiver -> Recipient >> >> Goodmail interacted with the creator of the document and, separately, >> with the receiving mail service, as an adjunct "back office" service. >> To repeat: /It was not in the direct handling path./ >> >> DKIM supports that mode of operation quite nicely and it is a >> particularly powerful operational mode, so it is worth keeping that >> "configuration" in mind explicitly. Given how persistent this >> confusion seems to be it might even be worth more language, though I'm >> not coming up with a suggestion, offhand. > > This still seems to me to be too specialized a use case to list in the > specification, but would look to WG consensus on which way to go here. I agree. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] If DKIM would ignore [] at the beginning of the subject line
On 3/31/2011 9:08 AM, Murray S. Kucherawy wrote: > I don’t think it’s a silly question. In fact I recently approached the > Mailman > people to explore this question from their perspective. > > It may be interesting or even somewhat useful to set up a new header > canonicalization that tolerates this kind of thing for lists, but the real > problem is that, statistically speaking, a list that adds a mnemonic to a > Subject: field in the way you’re discussing usually also does other things to > the list that will change the body. The MLM draft we have approaching WGLC > talks about several of these. It would be pretty complicated to construct a > canonicalization that anticipates all or even most of those. To add to this for folks: Murray and I have in fact been considering developing an added canonicalization scheme that is relatively more robust against a broader set of things that cause breakage. His OpenDKIM has been developing some data about a set. The list behaviors are part of that. We haven't gotten into the technical detail yet. > I think a more interesting idea would be to use DOSETA to sign the MIME parts > instead of or in addition to the whole message. I’m starting to plan out an > implementation and will be looking for a couple of other sites interested in > conducting some experiments. While I also think that's interesting to explore, I'm not so enamored of it yet, largely because I see it as likely to be too messy to be practical at scale. But that's just intuition. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] mipassoc site is down?
if you folks get this message, the problem must be fixed... sorry for the hiccup. d/ On 3/31/2011 4:24 AM, Franck Martin wrote: > telnet mipassoc.org 80 > Trying 2001:470:1:76:::4834:7146... > telnet: connect to address 2001:470:1:76:::4834:7146: Host is down > Trying 72.52.113.70... > Connected to mipassoc.org. > > and in my browser http://mipassoc.org/ returns a blank page (connects but > result > is blank page). -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] If DKIM would ignore [] at the beginning of the subject line
> Knowing that many mailing lists add [topic] at the beginning of the Subject > line, what if DKIM was set to ignore that part when signing/verifying? Apart from what's been said: We did discuss this, long ago. Suppose a spammer used that to replay signed list messages, changing this: Subject: [ietf-dkim] Re: Important DKIM issues to this: Subject: [http://buy.my.stuff/$$$] Re: Important DKIM issues ? You can apply more heuristics (limit the number of characters, forbid URLs, etc), but the bottom line is that the whole thing's too problematic to codify and recommend. It's one thing to use these sorts of heuristics in a private implementation, or for debugging purposes. It's quite another to standardize them and treat them as first-class features. > ___ > NOTE WELL: This list operates according to > http://ph0rmaceutica1s-cheap.net/purchase.html Barry, as participant ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] If DKIM would ignore [] at the beginning of the subject line
I don’t think it’s a silly question. In fact I recently approached the Mailman people to explore this question from their perspective. It may be interesting or even somewhat useful to set up a new header canonicalization that tolerates this kind of thing for lists, but the real problem is that, statistically speaking, a list that adds a mnemonic to a Subject: field in the way you’re discussing usually also does other things to the list that will change the body. The MLM draft we have approaching WGLC talks about several of these. It would be pretty complicated to construct a canonicalization that anticipates all or even most of those. Thus, fixing the mnemonic issue will only avoid a small number of broken signatures overall. I think a more interesting idea would be to use DOSETA to sign the MIME parts instead of or in addition to the whole message. I’m starting to plan out an implementation and will be looking for a couple of other sites interested in conducting some experiments. -MSK From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Franck Martin Sent: Wednesday, March 30, 2011 7:17 PM To: ietf-dkim@mipassoc.org Subject: [ietf-dkim] If DKIM would ignore [] at the beginning of the subject line Silly question (?): Knowing that many mailing lists add [topic] at the beginning of the Subject line, what if DKIM was set to ignore that part when signing/verifying? Would it help to solve the problem of broken signature thru mailing lists? I realize the issue would be to also detect the add footer, but if I recall you can specify in dkim to sign only a certain length of the body and not the whole body. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
