Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)
Jim Fenton wrote: I am formally proposing that the i= tag and supporting text be removed from 4871bis. [snip] 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. By remove, does that mean implementators can safely begin to not offer it for Domain signers to use or consider? Documenting this stuff to layman operators is HARD especially when we don't even have a firm grip of its utility or what value it offers. :) If its one more useless thing we don't have to ambiguously document for customer to understand and use with no real verification payoff, then +1 to remove i= from DKIM. -- 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
Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)
On 4/1/11 10:01 AM, Hector Santos wrote: Jim Fenton wrote: I am formally proposing that the i= tag and supporting text be removed from 4871bis. [snip] 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. By remove, does that mean implementators can safely begin to not offer it for Domain signers to use or consider? I should probably have used the term deprecate rather than remove. That's correct, an implementation compliant with 4871bis would not normally use the i= tag/value in signatures. Documenting this stuff to layman operators is HARD especially when we don't even have a firm grip of its utility or what value it offers. :) That's part of the reason for deprecating the feature: if people don't understand the utility of it, and it is not being used, then it is only adding complexity to the spec. If its one more useless thing we don't have to ambiguously document for customer to understand and use with no real verification payoff, then +1 to remove i= from DKIM. Thanks. -Jim ___ 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)
Jim Fenton wrote: By remove, does that mean implementators can safely begin to not offer it for Domain signers to use or consider? I should probably have used the term deprecate rather than remove. That's correct, an implementation compliant with 4871bis would not normally use the i= tag/value in signatures. Ok, so if we begin to REMOVE it from the documentation, which I think would be better because deprecation suggest some documentation regarding the deprecated mechanics remains, the question is then is what advice is provided to current DKIM verifier implementations in regards to being prepared to handle legacy usage. In other words, for current DKIM signers, the advice might be they may begin to not offer it in their Signer Setups and for future DKIM signer setups, to not consider it at all. For example, this is right on for me because we are still getting all the setup and GUI help done and removing i= tag would be great to finishing it. I don't have to worry about past signer compatibility versions so I can just get rid of it. But for verifiers, old or new, the question is whether the software can be simplified to remove the handling legacy usage. The issue is not that software can keep the old logic intact even its not going to be used, the issue is when legacy usage is found, what outcome comes from it? Off hand, and I have to go back, I believe seeing some systems using Authetication-Results to always include a i= as part of its A-R header result whether it was defined or not and when not, a default value is displayed. For example, this is the A-R result for my signature into this IETF-DKIM list: Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@isdg.net My isdg.net signer domain setup does not have a i= defined, yet it is showing one in the A-R record when verified by sbh17.songbird.com. Does that mean, a proposal to remove i= in DKIM-BASE, would imply an update to the A-R draft is necessary? -- 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
Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)
On 03/31/2011 02:33 PM, Jim Fenton wrote: 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. The working group was bamboozled into the false dilemma that DKIM had to produce a singular output. It has all gone down hill from there. Things that use heuristics like spam filters thrive with more information, and suffer with less. So we've destroyed information in the name of aesthetics while the main consumers of the output thrive on the messy details. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Work group future
I think it can be immensely useful if the list plainly says /why/ the WG closes. As Rolf noted, DKIM is not (yet) a well refined protocol that any of us would recommend his grandma to make use of. If that's the requirement, I think that pretty much every IETF standard since the dawn of the Internet is a failure. DKIM's main audience is the people who run mail systems, for MTA-MTA security, not individual users. 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] Proposal: Removal of AUID (i= tag/value)
On 4/1/11 1:31 AM, Franck Martin wrote: 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. +1. And as DKIM d= information already is shown to end users by some UA implementations (e.g. Gmail shows 'this message was signed by domain, when clicking on details) the need/advise to use different domains for different streams conflicts with the threat of phishers registering look-alike domains. /rolf ___ 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)
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Michael Thomas Sent: Friday, April 01, 2011 10:41 AM To: Jim Fenton Cc: IETF DKIM WG Subject: Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value) The working group was bamboozled into the false dilemma that DKIM had to produce a singular output. It has all gone down hill from there. Things that use heuristics like spam filters thrive with more information, and suffer with less. So we've destroyed information in the name of aesthetics while the main consumers of the output thrive on the messy details. My recollection was that we decided DKIM has to produce at least one specific output, and that the spec needed to identify what that one particular item was. We never precluded it from making other information available. OpenDKIM makes the entire signature and result available to the caller, so it can use whatever it wants. And that doesn't make it non-compliant. ___ 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 would suggest we deprecate i= and add st= (if not already used) that would let the sender specify a stream category. It would be limited to say 20 (or so) chars and we could specify a set of standard words (but not limited to). I'm thinking of things like transactional, marketing, password-reminder, sub-confirmation, billing, corporate, personal,... It would be left to the receiver to use them or not of course. I understand some of these words could be abused, but then the receiver could build a confidence factor in domain/stream association, etc... With IPv6 we may loose IP reputation, this is a way to bring it back within DKIM. PS: http://postmaster.facebook.com/outbound gives a good idea of streams in IPv4 world with DKIM equivalent, but they may be about the only ones to do that with DKIM. - Original Message - From: Rolf E. Sonneveld r.e.sonnev...@sonnection.nl To: Franck Martin fra...@genius.com Cc: Jim Fenton fen...@cisco.com, IETF DKIM WG ietf-dkim@mipassoc.org Sent: Saturday, 2 April, 2011 8:14:45 AM Subject: Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value) On 4/1/11 1:31 AM, Franck Martin wrote: 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. +1. And as DKIM d= information already is shown to end users by some UA implementations (e.g. Gmail shows 'this message was signed by domain, when clicking on details) the need/advise to use different domains for different streams conflicts with the threat of phishers registering look-alike domains. /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Open issues in RFC4871bis
In our conference call with Jim, Dave and I are left with three things that need discussion in the working group before we request a working group last call on it. The first, and biggest, is the removal of i= that Jim has proposed separately, so please comment on that thread. Two lesser issues are: 1) The document currently talks about authors signing their mail, when authors really don't sign their mail, ADMDs do. The point of the objection is that it might be wiser to talk about actual uses only and not include possible uses. The suggestion is thus to remove the idea that an author can do signing, changing it to authors' organizations or perhaps authors' ADMDs. Is there support for this, or support against making that change, or does it not really matter? 2) The document has text related to assessment. Does an independent assessment service fit into the DKIM model? Again, the issue is whether or not we want to include discussion of uses that are possible but uncommon. Is there support for this change, or support against making the change, or does it not really matter? The text in question is this: 2.3. Identity A person, role, or organization. In the context of DKIM, examples include the author, the author's organization, an ISP along the handling path, an independent trust assessment service, and a mailing list operator. We'd like to hand a revision to the chairs by April 10th to start WGLC, so please weigh in sooner rather than later on all three of these points so we can get some idea of consensus opinion and prepare the drafts accordingly. -MSK ___ 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)
Hi Hector, At 11:18 01-04-2011, Hector Santos wrote: Off hand, and I have to go back, I believe seeing some systems using Authetication-Results to always include a i= as part of its A-R header result whether it was defined or not and when not, a default value is displayed. For example, this is the A-R result for my signature into this IETF-DKIM list: Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@isdg.net [snip] Does that mean, a proposal to remove i= in DKIM-BASE, would imply an update to the A-R draft is necessary? RFC 5451 is a proposed standard. It is not a product of the DKIM WG. It's up to the author of that RFC to see whether an update is necessary. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Work group future
By closing down the WG the momentum will be lost; There's plenty of momementum in MAAWG and other operational fora. The IETF is about standards development. You don't get deployment by keeping a standards WG going. 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] Work group future
On 4/1/11 9:18 PM, John R. Levine wrote: I think it can be immensely useful if the list plainly says /why/ the WG closes. As Rolf noted, DKIM is not (yet) a well refined protocol that any of us would recommend his grandma to make use of. If that's the requirement, I think that pretty much every IETF standard since the dawn of the Internet is a failure. DKIM's main audience is the people who run mail systems, for MTA-MTA security, not individual users. it seems to me you don't take Alesandro's statement very serious, by responding only to this part of his message. Let's face the situation. Some 90% of all mail sent across the Internet is spam. The vast majority of this spam is caught by DNSBL based filtering. As we all know, the upcoming use of IPv6 poses some interesting challenges to the way current DNSBLs operate/are used. Over the years, 'the people who run mail systems' have started to use non-(IETF-)standard anti-spam tools, not bothering too much about the collateral damage (false positives and delivery delays) they cause. We all know the examples of call back verification, greylisting, DNS back and forward checking of IP/names etc. etc. Because these techniques are not standardized, they cause problems with the delivery of legitimate mail. Although DKIM is not an anti-spam technique in and by itself, it is the only spam-related standards track technology around. By closing down the WG the momentum will be lost; in my view it's essential to keep momentum and a WG that is actively investigating the impact of DKIM and further developing the standard based on real-world usage, can be a way to keep the industry and government interested. Note that the investigation of the real-world usage of DKIM has led to the removal of g= and to the proposal to remove i= in 4871bis. However, if there is consensus to close down the WG, I would like to suggest to followup this WG by chartering a reputation WG, which will pick up the work done so far on the domainrep mailing list, to make a start with 'cashing' on the results achieved with DKIM so far. /rolf ___ 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)
Just trying to connect the dots. SM wrote: Hi Hector, At 11:18 01-04-2011, Hector Santos wrote: Off hand, and I have to go back, I believe seeing some systems using Authetication-Results to always include a i= as part of its A-R header result whether it was defined or not and when not, a default value is displayed. For example, this is the A-R result for my signature into this IETF-DKIM list: Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@isdg.net [snip] Does that mean, a proposal to remove i= in DKIM-BASE, would imply an update to the A-R draft is necessary? RFC 5451 is a proposed standard. It is not a product of the DKIM WG. It's up to the author of that RFC to see whether an update is necessary. Regards, -sm -- 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
Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)
On 3/31/2011 5:33 PM, Jim Fenton wrote: 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: 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 Interesting. I've been thinking in exactly 180 degrees from that, from the point of view of what would need to be added to make i= useful? The problem I see with i= is the opacity, and as an opaque value with no semantics for the localpart of it. If there were a way for a domain to indicate exactly what semantics the signer is using for the i= value, the combination of that plus the i= value can then be used in various ways by the recipient verification engine. For example, our implementation would put the username@domain into the i= value when it was dealing with an authenticated user mail submission, and otherwise leave it blank. If there were a way in the DNS key record to indicate those semantics, the recipients could use that information for additional processing. So, -1 without full consideration of what could be done to make it useful. Tony Hansen t...@att.com ___ 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)
Yes, could be good to do it as a separate extension, I thought also about specifying an X-Header that would be signed by DKIM. Another way is to have a dkim tag that specify the header that indicates the stream classification Many ways to kill the same bird. As for the stream name, I think giving a few codified ones, would help the receiver in making decision, but if sender wants to use his own, then be free to do so. Should we resurrect your draft, or go another way? Which way you want to go? (How does it work in IETF?) - Original Message - From: Jim Fenton fen...@cisco.com To: Franck Martin fra...@genius.com Cc: Rolf E. Sonneveld r.e.sonnev...@sonnection.nl, IETF DKIM WG ietf-dkim@mipassoc.org Sent: Saturday, 2 April, 2011 9:33:10 AM Subject: Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value) I'm told that adding something like this to 4871bis would require that it go around again at Proposed Standard, rather than progress to Draft Standard. It might be possible as a separate extension to DKIM, however. I have an expired draft along these lines, draft-fenton-dkim-reputation-hint-00. But it didn't include the specific stream names. -Jim On 4/1/11 2:04 PM, Franck Martin wrote: I would suggest we deprecate i= and add st= (if not already used) that would let the sender specify a stream category. It would be limited to say 20 (or so) chars and we could specify a set of standard words (but not limited to). I'm thinking of things like transactional, marketing, password-reminder, sub-confirmation, billing, corporate, personal,... It would be left to the receiver to use them or not of course. I understand some of these words could be abused, but then the receiver could build a confidence factor in domain/stream association, etc... With IPv6 we may loose IP reputation, this is a way to bring it back within DKIM. PS: http://postmaster.facebook.com/outbound gives a good idea of streams in IPv4 world with DKIM equivalent, but they may be about the only ones to do that with DKIM. - Original Message - From: Rolf E. Sonneveldr.e.sonnev...@sonnection.nl To: Franck Martinfra...@genius.com Cc: Jim Fentonfen...@cisco.com, IETF DKIM WGietf-dkim@mipassoc.org Sent: Saturday, 2 April, 2011 8:14:45 AM Subject: Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value) On 4/1/11 1:31 AM, Franck Martin wrote: 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. +1. And as DKIM d= information already is shown to end users by some UA implementations (e.g. Gmail shows 'this message was signed bydomain, when clicking on details) the need/advise to use different domains for different streams conflicts with the threat of phishers registering look-alike domains. /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Open issues in RFC4871bis
On 4/1/11 2:08 PM, Murray S. Kucherawy wrote: In our conference call with Jim, Dave and I are left with three things that need discussion in the working group before we request a working group last call on it. The first, and biggest, is the removal of “i=” that Jim has proposed separately, so please comment on that thread. For ADSP the d= and the From domain must match, which removes the need for i=. Nevertheless, the i= can introduce different identities that might assist when transitioning to different IDN encodings. There is a growing use of UTF-8 DNS labels. For example use dig to resolve バスケ指導.meblog.biz or xn--rckp2e534u8jh.meblog.biz. RFC6055 should be read with an understanding there will be increased UTF-8 use in DNS. While currently RFC5321 requires email domains to use letters digits and hyphens, such a requirement will be problematic for other name services. It is also not clear whether UTF-8 aliases would be prohibited, since the only requirement appears to be resolution of necessary resources. It is too soon to know how this might be best resolved, so why toss out options that might help resolve what a signing domain hopes to permit. Two lesser issues are: 1) The document currently talks about authors signing their mail, when authors really don’t sign their mail, ADMDs do. The point of the objection is that it might be wiser to talk about actual uses only and not include possible uses. The suggestion is thus to remove the idea that an author can do signing, changing it to “authors’ organizations” or perhaps “authors’ ADMDs”. Is there support for this, or support against making that change, or does it not really matter? It matters, and it should indicate the domain does the signing, while also getting rid of the g= stuff in the key. 2) The document has text related to “assessment”. Does an “independent assessment service” fit into the DKIM model? Again, the issue is whether or not we want to include discussion of uses that are possible but uncommon. Is there support for this change, or support against making the change, or does it not really matter? It is likely the only sustainable assessment will be matching with known good sources, which would benefit by having a means to handle aliases and authorized paths. :^) The text in question is this: *2.3**. Identity* A person, role, or organization. In the context of DKIM, examples include the author, the author's organization, an ISP along the handling path, an independent trust assessment service, and a mailing list operator. DKIM should make no claims about identities. DKIM only relates signed portions of a message with that of a domain that publishes the public key. Would it be right to suggest this domain _is_ an identity? Take your time. There is no rush is there? -Doug ___ 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)
Murray S. Kucherawy wrote: The working group was bamboozled into the false dilemma that DKIM had to produce a singular output. It has all gone down hill from there. Things that use heuristics like spam filters thrive with more information, and suffer with less. So we've destroyed information in the name of aesthetics while the main consumers of the output thrive on the messy details. My recollection was that we decided DKIM has to produce at least one specific output, and that the spec needed to identify what that one particular item was. We never precluded it from making other information available. OpenDKIM makes the entire signature and result available to the caller, so it can use whatever it wants. And that doesn't make it non-compliant. Read: All outputs are equal, but some outputs are more equal than others. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Open issues in RFC4871bis
2.3. Identity A person, role, or organization. In the context of DKIM, examples include the author, the author's organization, an ISP along the handling path, an independent trust assessment service, and a mailing list operator. The current language looks fine to me. R's, John ___ 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)
Taking out i= doesn't create a back-compatibility problem because new signers won't add i= so old verifiers don't use it, and new verifiers ignore i= so old signers will still work. So that won't derail a Draft Standard effort. Adding something new, however, will. The best bet would be to add the st= or equivalent in a new draft, updating the IANA registries accordingly. Then RFC4871bis can still get Draft Standard, and the new tag becomes official on its own. From: ietf-dkim-boun...@mipassoc.org [ietf-dkim-boun...@mipassoc.org] On Behalf Of Jim Fenton [fen...@cisco.com] Sent: Friday, April 01, 2011 2:33 PM To: Franck Martin Cc: IETF DKIM WG Subject: Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value) I'm told that adding something like this to 4871bis would require that it go around again at Proposed Standard, rather than progress to Draft Standard. It might be possible as a separate extension to DKIM, however. I have an expired draft along these lines, draft-fenton-dkim-reputation-hint-00. But it didn't include the specific stream names. -Jim On 4/1/11 2:04 PM, Franck Martin wrote: I would suggest we deprecate i= and add st= (if not already used) that would let the sender specify a stream category. It would be limited to say 20 (or so) chars and we could specify a set of standard words (but not limited to). I'm thinking of things like transactional, marketing, password-reminder, sub-confirmation, billing, corporate, personal,... It would be left to the receiver to use them or not of course. I understand some of these words could be abused, but then the receiver could build a confidence factor in domain/stream association, etc... With IPv6 we may loose IP reputation, this is a way to bring it back within DKIM. PS: http://postmaster.facebook.com/outbound gives a good idea of streams in IPv4 world with DKIM equivalent, but they may be about the only ones to do that with DKIM. - Original Message - From: Rolf E. Sonneveldr.e.sonnev...@sonnection.nl To: Franck Martinfra...@genius.com Cc: Jim Fentonfen...@cisco.com, IETF DKIM WGietf-dkim@mipassoc.org Sent: Saturday, 2 April, 2011 8:14:45 AM Subject: Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value) On 4/1/11 1:31 AM, Franck Martin wrote: 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. +1. And as DKIM d= information already is shown to end users by some UA implementations (e.g. Gmail shows 'this message was signed bydomain, when clicking on details) the need/advise to use different domains for different streams conflicts with the threat of phishers registering look-alike domains. /rolf ___ 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] Work group future
Plus, the future of DKIM doesn't have to come from this WG. If there's momentum to be preserved, interested people can spin up a DKIMbis WG or something similar. The domain reputation stuff and DOSETA both have people talking at the IETF, for example. From: ietf-dkim-boun...@mipassoc.org [ietf-dkim-boun...@mipassoc.org] On Behalf Of John R. Levine [jo...@iecc.com] Sent: Friday, April 01, 2011 2:40 PM To: Rolf E. Sonneveld Cc: DKIM List Subject: Re: [ietf-dkim] Work group future By closing down the WG the momentum will be lost; There's plenty of momementum in MAAWG and other operational fora. The IETF is about standards development. You don't get deployment by keeping a standards WG going. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Work group future
There already is some work on domain reputation in progress, though it hasn't quite got enough momentum to charter a working group yet. Stay tuned. But domain reputation is explicitly something DKIM is not supposed to work on. So without that, I don't know why we still need a working group; we've done everything we set out to do. From: ietf-dkim-boun...@mipassoc.org [ietf-dkim-boun...@mipassoc.org] On Behalf Of Rolf E. Sonneveld [r.e.sonnev...@sonnection.nl] Sent: Friday, April 01, 2011 2:03 PM To: John R. Levine Cc: ietf-dkim@mipassoc.org; Alessandro Vesely Subject: Re: [ietf-dkim] Work group future On 4/1/11 9:18 PM, John R. Levine wrote: I think it can be immensely useful if the list plainly says /why/ the WG closes. As Rolf noted, DKIM is not (yet) a well refined protocol that any of us would recommend his grandma to make use of. If that's the requirement, I think that pretty much every IETF standard since the dawn of the Internet is a failure. DKIM's main audience is the people who run mail systems, for MTA-MTA security, not individual users. it seems to me you don't take Alesandro's statement very serious, by responding only to this part of his message. Let's face the situation. Some 90% of all mail sent across the Internet is spam. The vast majority of this spam is caught by DNSBL based filtering. As we all know, the upcoming use of IPv6 poses some interesting challenges to the way current DNSBLs operate/are used. Over the years, 'the people who run mail systems' have started to use non-(IETF-)standard anti-spam tools, not bothering too much about the collateral damage (false positives and delivery delays) they cause. We all know the examples of call back verification, greylisting, DNS back and forward checking of IP/names etc. etc. Because these techniques are not standardized, they cause problems with the delivery of legitimate mail. Although DKIM is not an anti-spam technique in and by itself, it is the only spam-related standards track technology around. By closing down the WG the momentum will be lost; in my view it's essential to keep momentum and a WG that is actively investigating the impact of DKIM and further developing the standard based on real-world usage, can be a way to keep the industry and government interested. Note that the investigation of the real-world usage of DKIM has led to the removal of g= and to the proposal to remove i= in 4871bis. However, if there is consensus to close down the WG, I would like to suggest to followup this WG by chartering a reputation WG, which will pick up the work done so far on the domainrep mailing list, to make a start with 'cashing' on the results achieved with DKIM so far. /rolf ___ 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
