Re: [ietf-dkim] versions of RFC822 mail messages, Where is the formal definition of DKIM-Signature?

2018-02-10 Thread John Levine
In article <20180210092127.33398.qm...@f3-external.bushwire.net> you write: >In any event, 822 is an existence-proof that decades-long upgrades are entirely >possible without the scorched-earth approach of versioning. ... Nope, see the PS. But anyway. I don't understand this scorched earth

Re: [ietf-dkim] DKIM and EAI

2018-02-09 Thread John Levine
In article <1707398.kN3rUcK64s@kitterma-e6430> you write: >Does this need to update RFC 7208 since there are SPF related MUST >requirements? I would think so, also 6376, 7489, 7601 since it updates DKIM, DMARC, and A-R specs. R's, John ___ NOTE WELL:

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

2018-02-08 Thread John Levine
In article <20180208203207.26575.qm...@f3-external.bushwire.net> you write: >After all, what are most senders going to do? They will not want their >signatures to be suddenly unrecognized by 99% of the planet so they'll continue >to generate a v=1 header and they will also want to reap the bennies

Re: [ietf-dkim] Timeouts retrieving keys from ietf.org

2013-10-09 Thread John Levine
I'm surprised Network Solutions had this problem. Unfortunately, I'm not. The current incarnation of NSI is a pale shadow of its former self, a subsidiary of web.com that as far as I can tell exists primarily to provide one-stop registration and hosting, along with business from the

Re: [ietf-dkim] Fwd: Request to move RFC 5617 (ADSP) to Historic

2013-09-12 Thread John Levine
http://wiki.apache.org/spamassassin/Rules/DKIM_ADSP_CUSTOM_MED If you look at the DKIM configuration files, you'll see that the ADSP usage is almost entirely faked up, via a list of entries for the usual phish targets (ebay, paypal, etc.) to pretend that they have ADSP records:

Re: [ietf-dkim] [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic

2013-09-11 Thread John Levine
This is a formal request, to have DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP) (RFC 5617) moved to Historic status. I'm one of the authors, and I think it's a dandy idea. Other than a few experiments and one or two impressive misfires, such as one that bounced

Re: [ietf-dkim] That weird i= is most probably EDSP

2013-08-04 Thread John Levine
My problem is that absent a draft, you're lobbing a vague proposal over the wall and hoping the community will do all of the work for you. That was my sense, too. Writing a draft and submitting it is not a huge effort (at least, not if you know what you're going to say), and it has the advantage

Re: [ietf-dkim] Weird i= in client mail

2013-06-20 Thread John Levine
It has many potential uses, but within DKIM itself, it's an expansion socket. Keep in mind that there are IANA registries for the tag names in both the signatures and the key records. If you want to try something new, just pick a tag name or two and have at it. RFCs 6541 and 6651 have recently

Re: [ietf-dkim] Weird i= in client mail

2013-06-17 Thread John Levine
My understanding matches Dave's. The i= value is an opaque token which for purely historical reasons has to look like an address in a subdomain of the d= domain. I've asked the client why they chose that, we'll see what they day. Huh, that's what the code does. Should it do something else?

Re: [ietf-dkim] Weird i= in client mail

2013-06-17 Thread John Levine
I haven't been able to find anything that discusses the intention behind the i=. I expect they chose this i= because that's the envelope from, but the i= is suppose to be a person, not a mechanical address, correct? Historical bit: it is my impression that i= was invented by people who were

Re: [ietf-dkim] Weird i= in client mail

2013-06-17 Thread John Levine
At one stage i= was thought to represent different mail streams with different reputation, however this did not get any traction... As far as I can recall, I don't think anyone but you had that theory. If you want two streams, you use two d= domains. On my system the i= tells how the mail was

Re: [ietf-dkim] Final update to 4871bis for working group review

2011-07-07 Thread John Levine
Will your assume one more From than listed in h= lead to failed verifications on messages that actually follow the advice in the RFC to list duplicate headers in their h= values? The RFC also says you shouldn't sign messages that aren't RFC 2822. So pick your poison. I have to say it's a little

[ietf-dkim] Mostly off topic: For Ian Eiloart

2011-06-24 Thread John Levine
Ian's MTA has a buggy callback system that tries to use fake bounces to guess whether a sending address existed. I thought these had been stamped out due to both the fact that they mostly attack innocent bystanders, and the fact that they don't work, but I guess not yet. R's, John

Re: [ietf-dkim] MLMs and signatures again

2011-05-26 Thread John Levine
Let's say I route all traffic from list X to its own separate mailbox, but I also want my MUA to flag for special attention mail sent to that list by people I hold in high regard, for example, and I want that to be based on their accumulated reputations. I either have to base that on something

Re: [ietf-dkim] MLMs and signatures again

2011-05-26 Thread John Levine
In my experience, the reputation of the list is unrelated to the reputation of its participants. Given how little DKIM-related reputation work has been done, deployed and heavily used so far, perhaps we should all be a bit cautious about taking existing practices and treating them as

Re: [ietf-dkim] New canonicalizations

2011-05-25 Thread John Levine
The idea is to anticipate any unknown signature breaker. I'm pretty sure that's specifically out of scope. And I promise that whatever you do, short of wrapping the whole message in opaque armor, I can come up with something that will break it. Regards, John Levine, jo...@iecc.com, Primary

Re: [ietf-dkim] 8bit downgrades

2011-05-24 Thread John Levine
Of the 31, 20 were from Keith Moore signed messages into the IETF-SMTP list with a 3rd party signature and Hoffman's list server (non-dkim aware) doing this: Oh, it's a mailing list. Why are we even having this discussion? We all know there's a million ways that lists break incoming

Re: [ietf-dkim] New canonicalizations

2011-05-23 Thread John Levine
Could you get the effect of this by including the Content-Transfer-Encoding header in the 'h=' and doing some fancy checks involving the 'bh=' (to detect whether it was the body or the headers or both that were broken)? No, of course not. The bh= and h= are just hashes, so all they can

Re: [ietf-dkim] Certifying the DKIM public key?

2011-05-19 Thread John Levine
recently someone asked me whether it would have any added value if the DKIM public key, which is stored in DNS, would be 'certified' in some (yet to be determined) way by a 3rd party like VeriSign, Thawte etc.? Sure. See RFC 5518. R's, John ___ NOTE

Re: [ietf-dkim] New canonicalizations

2011-05-18 Thread John Levine
Since I more or less started this, my assertion was that relaxed doesn't do much better than simple, which at this point I think we can categorize as not disproven. The point I was making was that ever more complex ways to decide that two mutated versions of a message are the same aren't likely

Re: [ietf-dkim] DKIM and mailing lists

2011-05-11 Thread John Levine
It's unnecessary and unwelcome to call what other people write stupid. FYI, that section is taken verbatim from the MLM draft that Barry sent off yesterday. I guess now we know who read it and who didn't. R's, John ___ NOTE WELL: This list operates

Re: [ietf-dkim] l= statistics was 23 again (sorry John) was Output

2011-05-09 Thread John Levine
Oddly, I'm finding myself coming to believe that its use within a coordinated template for mediators might actually being helpful. 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,

Re: [ietf-dkim] Issue: Consider deprecating l=

2011-05-09 Thread John Levine
I think it was a mistake to include l= in the first place, but I find Murray's arguments against taking it out now persuasive. I would also really like to have a better idea of how people are using it, notably, for all those messages where l= doesn't cover the whole body, what's in the naked

Re: [ietf-dkim] Ticket #24

2011-05-06 Thread John Levine
I appreciate the work that Doug and Charles put into their proposal, but for reasons already discussed, I think we should leave section 6.1 as is in -09. R's, John ___ NOTE WELL: This list operates according to

Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

2011-05-05 Thread John Levine
I don't think this is correct. The signer creates and signs the i= value, so it's not garbage, and it can't be false either. Perhaps the word stable would be more applicable. The d= value is tied to the DNS, is relatively stable, and the verifier can check that there's a key record in the DNS

Re: [ietf-dkim] Output summary

2011-04-29 Thread John Levine
It is indeed an effort based, at least in part, on clarifying stuff we learned since the earlier version based on experience. I think it's pretty clear that's what's being done. Dropping g= is a prime example. We've hardly changed the parts that describe how to create and verify the signature

Re: [ietf-dkim] Output summary

2011-04-27 Thread John Levine
4.9. Output Requirements The output of the verifier MUST embody: embody -- include (if it embodied them, that arguably implies that it doesn't include anything else) - A result code that indicates whether or not the signature was validated (PERMFAIL or TEMPFAIL as described in

[ietf-dkim] Ticket #10: public key example -- no change needed

2011-04-26 Thread John Levine
Whether the name in the DNS record should be brisbane or brisbane._domainkey or brisbane._domainkey.example.org depends entirely on the most recent $ORIGIN line in the master file. If the $ORIGIN is _domainkey.example.org, an entirely plausible scenario, the current text is correct. I see no

[ietf-dkim] Ticket 17: validating A-labels

2011-04-26 Thread John Levine
I agree with Dave, the proposed change is entirely outside the scope of DKIM. Suggest closing the ticket with no change. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

[ietf-dkim] Ticket 10: list-post and d=

2011-04-26 Thread John Levine
As previously discussed, a binding between the domain in d= and the domain in another header is outside the scope of DKIM. I suggest deleting the paragraph with no replacement. R's, John ___ NOTE WELL: This list operates according to

Re: [ietf-dkim] Taking responsibility for a message

2011-04-25 Thread John Levine
I don't so much view DKIM as protecting content; rather, my current view of its semantics aligns with the whole taking some responsibility for approach. So far, so good, the signer takes some responsibility for the message. And thus, a signer should only sign those parts of the header and body

Re: [ietf-dkim] About DKIM and mailing lists

2011-04-24 Thread John Levine
Pretty short-sighted if you ask me. NANOG is an interesting mix of cutting edge network managers and people who seem to have configured their networks in 1998 and see no reason to change it now. The latter group often go out of their way to avoid seeing reasons to change it now. R's, John

Re: [ietf-dkim] Revision to draft-ietf-dkim-rfc4871bis posted

2011-04-24 Thread John Levine
Nits: In 4.5: for consistency, please use the same a-label language for d= and i= tags. The same language needs to go in s= since selectors are domain names, too. Suggested language all three places: Internationalized domain names MUST be encoded as A-Labels, as described in Section 2.3 of

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

2011-04-20 Thread John Levine
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

Re: [ietf-dkim] ADSP stats

2011-04-20 Thread John Levine
That's what I did. The only ADSP I see this year is Paypal. That's a success story of a sort. We know that ADSP is only potentially useful in a narrow set of circumstances. Data that indicates the protocol isn't being widely deployed for domains for which is not suited is good news. Along

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

2011-04-19 Thread 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

Re: [ietf-dkim] [dkim] #4: non-ascii header text

2011-04-18 Thread John Levine
Would it be acceptable to put some text like the following? Internationalized domain names MUST be represented as A-labels as described in [RFC5890]. NOTE: For experimental use only, domain names MAY be represented in UTF-8 as described in [RFC5335]. Please, no. If you're

Re: [ietf-dkim] ISSUE: verifier message editing language

2011-04-13 Thread John Levine
The stuff having to do with producing an alternate version of the text is certainly wrong insofar as there's no extra visible copy produced, but I've always interpreted that language as referring to the internal copy that gets fed to the hash function. It certainly could be that I've just been

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

2011-04-13 Thread John Levine
Oops, this is a separate issue. But I hope it's also not contentious. 3.5, d= and i= tags: references to RFC3490 should be RFC5890. The reference to ToASCII() should go, or else in both places say IDNs are represented as A-labels. Suggested new language under d= on page 22: Change:

Re: [ietf-dkim] Extensions (was RE: Proposal: Removal of AUID (i= tag/value))

2011-04-06 Thread John Levine
For there to be reasonable semantic meaning, it must be understandable. Whether it were done by adding semantic signposts for i=, additional tag values, or additional 5322 headers, it should *not* be done in an ad-hoc fashion. Quite right. We need drafts, implementations, all the usual stuff.

Re: [ietf-dkim] the alleged list problem, was If DKIM would ignore

2011-04-05 Thread John Levine
Isn't it obvious? Yes, but not in a good way. We'd like to be able to deploy DKIM, coupled with some ADSP-like protocol (The real ADSP is hopelessly inadequate) in order to block all forgeries at the MX. *All* forgeries, not just phish. Well, as we've established long past the point of

Re: [ietf-dkim] ADSP, not, was Proposal: Removal of AUID (i= tag/value)

2011-04-04 Thread John Levine
One new-ish data point: I believe Hotmail is leveraging the ADSP records from domains they trust to be operating with consistency. As has often been pointed out, if it's domains you already know something about, you don't need ADSP. ADSP is only the most obvious of assertions that people make

Re: [ietf-dkim] Interpretation, was Open issues in RFC4871bis

2011-04-04 Thread John Levine
Signers SHOULD NOT remove any DKIM-Signature header fields from messages they are signing, even if they know that the signatures cannot be verified. Instead, when a relay alters a message such that any valid signature gets broken, it SHOULD re-identify the message by synthesizing a

Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)

2011-04-03 Thread John Levine
Another way is to have a dkim tag that specify the header that indicates the stream classification Many ways to kill the same bird. If there is a reason why people aren't able to use a d= domain per stream, I wish someone would explain in simple terms that even a dimwit like me can understand.

Re: [ietf-dkim] Open issues in RFC4871bis

2011-04-01 Thread John Levine
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

Re: [ietf-dkim] the alleged list problem, was If DKIM would ignore

2011-03-31 Thread John Levine
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

Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-04

2011-03-31 Thread John Levine
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

Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-04

2011-03-29 Thread John Levine
On 3/28/2011 11:27 PM, Jim Fenton wrote: 1. authors and their organizations could be misinterpreted ... I'm with Dave. It looks clear ro me that it's a list of examples. The Signer MAY choose to use the same namespace for its AUIDs as its users' email addresses or MAY choose other means

Re: [ietf-dkim] Work group future

2011-03-28 Thread John Levine
Furthermore, I'm not sure whether the DKIM WG has concluded on thinking about the value of DKIM, what it can be used for. Is it's purpose limited to providing input to a reputation engine? Is that it? Or is there more than that? Those are all interesting questions, but I don't see what they have

Re: [ietf-dkim] Full name problem

2011-02-27 Thread John Levine
Hence, I could send a phish as: From: PayPal mich...@talamasca.ocis.net Um, you must be new here. We've argued about this ad nauseam over the years. As Dave points out, DKIM does not validate anything other than that the message you received is the same as the one the signer signed (for a

Re: [ietf-dkim] draft-ietf-dkim-rfc4871bis-03 submitted

2011-02-26 Thread John Levine
Therefore, a verifier SHOULD NOT validate a message that is not compliant with [RFC5322, RFC2045 and RFC2047] specifications. IMHO, it is somewhat vague. That SHOULD-NOT could be promoted to a MUST-NOT for a finite number of specific features --to be explicitly listed for readers'

Re: [ietf-dkim] wildcards, draft-ietf-dkim-rfc4871bis-03 submitted

2011-02-16 Thread John Levine
will generally produce a response to a DKIM query that is not a valid DKIM key record. This problem applies to many other types of queries, and client software that processes DNS responses needs to take this problem into account. Regards, John Levine, jo...@iecc.com, Primary Perpetrator

Re: [ietf-dkim] Re-thinking the organization of the DKIM spec

2011-01-15 Thread John Levine
sense to do DOSETA, which strikes me as premature until we have a better idea of what the applications are, make it a short document that defines a subset of DKIM features by reference to the DKIM spec. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please

Re: [ietf-dkim] Proposed documentation split between DKIM and DOSETA

2011-01-07 Thread John Levine
Here's the proposal that Barry just announced, for splitting the DKIM specification into a DKIM-specific portion and an underlying, more generic portion that could be re-purposed for other services. It's current working acronym is DOSETA. Seems reasonable to me, both the split, and the plan

Re: [ietf-dkim] FW: New Version Notification for draft-kucherawy-authres-vbr-00

2010-11-12 Thread John Levine
Comments welcome, even if it's just I read this, looks good to me so that some support or consensus can be recorded. I read it, it almost looks good to me. A VBR-Info header can list multiple certifiers, so unless there's something I missed, the vbr clause in the A-R header should include the

Re: [ietf-dkim] Proposal for new text about multiple header issues

2010-10-25 Thread John Levine
A DKIM verifier generates a single bit, validly signed or not, and an identifier in the validly signed case. Well, actually, if you read 4871, it also produces an edited version of the message. As I suggested in my message a few days ago, I don't think that's what we intended, and we should fix

Re: [ietf-dkim] Proposal for new text about multiple header issues

2010-10-25 Thread John Levine
The thought is that two Subject lines is worth rejecting, an extra at sign in the Message-ID is not. I'm fine with that if we think implementers will find it easier to construct a comprehensive likely list versus just enforcing the spec. It's not easier but I'm with Steve here. People are not

Re: [ietf-dkim] Proposal for new text about multiple header issues

2010-10-24 Thread John Levine
I mostly agree. (Wow!) 1) During the handling of a message in conjunction with a DKIM result that indicates a valid signature, consider as valid only those fields and the body portion that was covered by the signature. Note that this is not to say unsigned content is not valid, but merely

Re: [ietf-dkim] Commments and clarifications to 4871bis-02

2010-10-22 Thread John Levine
Page 11, informative implementation note at the bottom of the page: Delete it. If we want to support EAI, we should support EAI, but this language just encourages code that won't interoperate. I don't see anything on page 11 about EAI, nor any informative notes. Oops, that's page 12, the

Re: [ietf-dkim] the usual misunderstanding about what DKIM promises

2010-10-22 Thread John Levine
DKIM makes no statement about the validity of a sender address. d/ I guess I should have said Author address. DKIM makes no statement about the validity of an Author address. In practice, if I look at mail with yahoo.com author addresses for example, I find that with DKIM yahoo.com

Re: [ietf-dkim] detecting header mutations after signing

2010-10-18 Thread John Levine
difference between a green bar SSL page and one with no SSL. I don't want to mess with the MUA at all, but rather use DKIM to help decide what messages to show her and which messages to consign to the junk folder. Why do we think such a sorting module can't/won't have the intelligence to do

Re: [ietf-dkim] detecting header mutations after signing

2010-10-18 Thread John Levine
There's a strong correlation between badly structured emails (SMTP, MIME, HTML) and email that the recipient doesn't want to see. You're right, but I think that's largely orthogonal to DKIM. If a message has a good signature from a credible signer, I expect I'd want to show it to the user even

Re: [ietf-dkim] DKIM and patents

2010-10-16 Thread John Levine
US PATENT 7487217 http://www.freepatentsonline.com/7487217.html but then it seems prior art existed in the form of DKIM (which was started around 2004 http://news.domainmonster.com/dkim-email/) This isn't a patent about authentication, it's about spam filtering using the reputation of domains

Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments

2010-10-15 Thread John Levine
In article 201010151013.26823.ietf-d...@kitterman.com you write: On Friday, October 15, 2010 10:04:40 am MH Michael Hammer (5304) wrote: why don't we just deprecate l=? Yes. Please. Agreed. Has anyone ever found it useful for its nominal purpose of messages transiting MLMs? R's, John

Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records

2010-10-15 Thread John Levine
In this case, we've gone to some lengths to make the environment pure, by using the underscore branch. And then along come these pesky wildcards. Even without wildcards, there's been a variety of broken key records. I would hope it would be obvious that you have to assume that any data you

Re: [ietf-dkim] FW: An issue with DKIM reporting extensions

2010-10-13 Thread John Levine
- In order to make use of ADSP, Y needs to change which MTA it's using. This is almost certainly an expensive effort. - Y simply can't use ADSP. - The DKIM reporting extensions should have a flag that says DSNs should not cause generation of fraud reports. I'll take

Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments

2010-10-13 Thread John Levine
Subject: Buy fake watches at fakewatch.example.com! Will some clients display the second subject line? I suspect some will. Do we need to recommend that signers also add a protective second subject: to their h= value? Or do we need to require that verifiers make sure that any header fields

Re: [ietf-dkim] detecting header mutations after signing

2010-10-08 Thread John Levine
A) You have to sign either all occurences of a header or none of them, ... B) Same as A, but limited to an enumerated set of headers that are supposed to occur only once. c) Same as B, but tell signers to use the h= trick to make verification fail if extra headers show up.

Re: [ietf-dkim] New Version Notification for draft-ietf-dkim-mailinglists-03

2010-10-05 Thread John Levine
My perception of the rough consensus is that we do want to make some statements about the issues discussed in the draft. However, the only truly normative thing upon which we appear to agree is that MLMs should sign their mail. I would rather we produce this more complete document at a

Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From

2010-10-05 Thread John Levine
It has been observed by implementations that is it possible to replay a message with a 2nd 5322.From header at the top ... A thing with two From: headers isn't a valid RFC 5322 message. You may recall a lengthy argument about what to do with messages with bare carriage returns, with the final

Re: [ietf-dkim] signing and verifying invalid messages

2010-10-05 Thread John Levine
Still, though, it's a solution to deal with malformations to which MUAs are susceptible, and not strictly a DKIM problem. Would it be a good idea to recommend in 4871bis that DKIM implementations should not sign or verify invalid messages? I cheerfully admit that I haven't thought out all the

Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs

2010-09-29 Thread John Levine
This might be a good time to remind people that MLMs in their current form are not broken, and any proposal that requires them to stop doing something that they're currently doing, like rewriting messages or adding message tags, is a non-starter. Since nothing requires anyone do anything with

Re: [ietf-dkim] envelope signatures, was Corner cases and loose ends

2010-09-28 Thread John Levine
That no workable envelope-level DKIM equivalent has materialized to date is unfortunate. Not for lack of trying, but I just don't see how you could prevent bad guys from replaying good envelopes on bad mail. Yeah. Short-lived keys is the best thing I can come up with. Do you think it's

Re: [ietf-dkim] Discussion lists and broadcast lists are not the same thing

2010-09-24 Thread John Levine
Do concepts generalize enough to allow issuing draft-ietf-dkim-mailinglists also for these authoring MLMs? No. All of the complications in mailing lists arise from the fact that the author of the message is not related to the operator of the list. Even though ESPs are generally sending mail

Re: [ietf-dkim] draft-ietf-dkim-rfc4871bis

2010-09-23 Thread John Levine
Sounds like an improvement to me. Yes and thanks! Seems unanimous. Dave, do you have enough changes to do another version? R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] party list it's whatever

2010-09-15 Thread John Levine
To apply the 'normal' and commonly used in other contexts (eg contracts and insurance) definitions. The sender is the first party. The recipient(s) jointly and individually are the second party. Anyone else is a third party. I have never heard anyone talk about 2nd party signatures. S/MIME

Re: [ietf-dkim] DKIM+ADSP = FAIL, and it's our fault

2010-09-14 Thread John Levine
But what everyone has been telling me is that it would be better in fact to go and deploy something before drafting the I-D and debating it here. This is the main reason why I went quiet on these lists since the Barcelona MAAWG meeting (until this week). Yes indeedy. Keeping in mind that

Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review

2010-09-10 Thread John Levine
Forgot to mention: I'd totally support the creation of a separate draft listing Things We Thought Of But Haven't Tried Yet, so long as it's clearly labeled. Of course. This is the Experimental I-D and perhaps RFC that I've been encouraging people with paper designs to write. R's, John

Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review

2010-09-10 Thread John Levine
It's not clear to me that there's consensus that anything qualifies as Best Current. We have some small samples of a few things that some people have tried, but I don't sense we're there yet. I hope that lists signing their outbound mail qualifies. Large providers Googlegroups and Yahoogroups

Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review

2010-09-10 Thread John Levine
This is not the only potential use of such a feature. I've spoken to one MLM developer who told me the feature has been previously requested for privacy reasons nothing to do with DKIM or ADSP. That sounds like a somewhat different feature. What we've been talking about so far is basically

Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review

2010-09-01 Thread John Levine
ANNEX A - MUA Considerations Is a draft about mailing lists the right place to make recommendations to MUA developers? Seems like those should probably be in a separate document. No, but the entire document is riddled with advice that has no basis in experience and is unlikely ever to be

Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review

2010-09-01 Thread John Levine
At this point, unless we can cut back the MLM document to stick to items that we have consensus about, e.g., that it is typical for signatures applied to incoming mail not to verify after a message passes through an MLM, and that it would be nice if a list or its MTA signed its outgoing mail,

Re: [ietf-dkim] Mailing lists and s/mime dkim signatures - mua considerations

2010-08-22 Thread John Levine
l= over substantial opposition under the theory that it would compensate for a significant fraction of MLM modifications. I think we now have found that was overoptimistic. The right thing to do is to deprecate l=, not make more mistakes. This is, as usual, shamelessly wrong. We showed

Re: [ietf-dkim] draft-ietf-dkim-rfc4871bis

2010-08-20 Thread John Levine
I went through it. It's a very thorough piece of work. So far I only have two comments. Section 3.5, near the bottom of page 23: Local- part MAY be drawn from a namespace that does not contain the user's mailbox I'd suggest changing that to Local- part MAY be drawn from a namespace

Re: [ietf-dkim] marketing dkim

2010-08-20 Thread John Levine
Why isn't a signed 822.From sufficiently accurate sender information from a provider who cares? The who cares bit is a reputation system, you know. I also suspect that my signing model is fairly typical of small providers. I sign everything, and make no effort to validate stuff on the From:

Re: [ietf-dkim] marketing dkim

2010-08-19 Thread John Levine
* DKIM is a really well developed standard for signing email Right, but emphasize that the granularity is a signing domain -- it is not and cannot be a way to attribute mail to individual people. * Combined with ADSP=discardable it can filter email at ISP gateways without too much fear of

Re: [ietf-dkim] marketing dkim

2010-08-19 Thread John Levine
Encouraging use of DKIM, and avoiding confusion between ADSP flaws and DKIM flaws is a big part of the work at hand, I think. If it's not, it should be. Agreed. It would be nice to collect enough data about ADSP so we can figure out whether my take on it or Mike's is closer to reality. R's,

Re: [ietf-dkim] draft-ietf-dkim-mailinglists annex MUA considerations

2010-08-17 Thread John Levine
I'm trying to get the same goal by recommending adding some non-artisicly specified form of a list: mlm.example display so its more evident to the user without percentage hacks. I must be missing something. What does this have to do with DKIM? If this were important, why don't MUAs look for

Re: [ietf-dkim] draft-ietf-dkim-mailinglists annex MUA considerations

2010-08-16 Thread John Levine
If the original was From: Joe Doe j...@discardable.example and a recipient sees it as From: Joe Doe joe%discardable.exam...@mlm.example then he will still have a pretty clear idea that it originated from Joe Doe, ... Actually, in both cases, most MUAs will show: From John Doe It's the

Re: [ietf-dkim] draft-ietf-dkim-mailinglists annex MUA considerations

2010-08-16 Thread John Levine
I was going on a desireable assumption that a verifier would add a Authenticated-Results header field and online/offline MUAs could depend on this if it falls within the right domain or its domain is accepted by a user. You are aware, I hope, that nothing in an Authenticated-Results header has

Re: [ietf-dkim] On changing From: when sending through lists

2010-08-11 Thread John Levine
I have to say that this particular proposal is currently no more than 1/3 baked, since unless I've missed something, I don't see much effort to work out failure and security models. For example: OK, in the scenarios which follow, you is some MLM, and the proposition is that the MLM might

Re: [ietf-dkim] what does DKIM do, was draft-ietf-dkim-mailinglists-01 review request

2010-08-10 Thread John Levine
But what you're saying seems antithetical to most of the document, which goes to some lengths to describe ways that MLMs and DKIM can co-operate better. So should we not bother? Oh no. (That is. we shouldn't not bother.) There's plenty of good stuff in your draft, but on reflection I think the

Re: [ietf-dkim] On changing From: when sending through lists

2010-08-10 Thread John Levine
Comments? And if you agree, your rationales in either direction? (I'll take Daniel's text at that link into account.) Unless I misunderstand, this is a paper proposal that has never been implemented that addresses a quite possibly purely hypothetical problem. There's nothing wrong with

[ietf-dkim] Straw poll results

2010-08-09 Thread John Levine
In article 548b10a3a5fcf3025a4b5...@lewes.staff.uscs.susx.ac.uk you write: However, if there's a need to trust the original sender, and you don't quite trust the list to get that right for you, ... It appears that we can discard this concern as counterfactual. I asked how people sort their list

Re: [ietf-dkim] Straw poll results

2010-08-09 Thread John Levine
Let me try to explain. If the identity of the list contributor is of any value to the receiver of an MLM-distributed message, ... We're going in circles here. Please see Steve A's recent message. R's, John ___ NOTE WELL: This list operates according

Re: [ietf-dkim] Straw poll results

2010-08-09 Thread John Levine
This assumes mail from MLMs is treated differently than other mail. While individual users may (and probably do) treat it differently, receivers of non- trivial scale don't and can't. Sigh. Anyone who uses gmail would know that your assertion is just plain wrong. And in any event, even if your

Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request

2010-08-09 Thread John Levine
I agree with most of Dave's suggestions, but as a niggle: Upon DKIM and ADSP evaluation, a receiver may decide to reject a message during an SMTP session. If this is done, use of an [SMTP] DKIM and ADSP evaluation are not performed during an SMTP session, unless the session is

Re: [ietf-dkim] yet more hypothetical mail managemenet scenarios

2010-08-09 Thread John Levine
And in any event, even if your assertion were true, so what? Our working assumption is that receivers will use valid DKIM signatures to whitelist mail from signers they like. How does it matter whether the signer happened to be a related to a list? If I'm a consumer of your list of domains

Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request

2010-08-06 Thread John Levine
I went through -01 again. Basically, it's fine. There's a few places where it says things that are out of scope of DKIM. A signature either verifies or it doesn't, and there's nothing inherently good or bad about that. RFC 4871 carefully describes the way one verifies a signature, and that

Re: [ietf-dkim] Clarifying DKIM (etc.) expectations for mailing lists in the face of digests

2010-08-05 Thread John Levine
there are phishing attacks possible that work through lists but are extremely unlikely to work when the message is part of a digest. Could you give some examples of phishing attacks that work through lists? Real ones you've seen would be much more helpful than hypothetical ones. The only

  1   2   3   4   5   6   >