Re: [ietf-dkim] versions of RFC822 mail messages, Where is the formal definition of DKIM-Signature?
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 stuff. This is not IPv6, which is often incompatible for the sake of being incompatible, and is intended to make IPv4 go away sometime in the fourth millenium. The idea with DKIM v=2 is that there are things that you cannot say in a v=1 signature, no matter how many new tags you add, so you need some way to tell verifiers what they need to understand. How about this? We rebrand the v= tag to be a feature list so the syntax is now roughly v= word (, word)* where each word describes a semantic feature. Feature tag "1" is all the stuff in RFC6376. My feature is mandatory to understand tags, feature name "mandatory", so the signatures start DKIM-Signature: v=1,mandatory ... R's, John PS: The reason you haven't noticed the versions in RFC822 is that we put the version flags into SMTP. An 8BITMIME or EAI mail message is not backward compatible with RFC822. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM and EAI
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: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?
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 of your >fantastic SpamAssassin feature so they'll additionally generate a v=2 header. In my application, the feature that requires v=2 is double signing, i.e. this signature is valid only if there's also a signature from X. It was intended as a workaround for the DMARC mailing list problem The idea is that in addition to your regular v=1 signature, you'd also put a weak v=2 signature that requires re-signing by the mailing list. If you don't use conditional signing (or something else subsequently added that depends on v=2 semantics), then v=1 signatures are fine forever. The reason to make then both DKIM-Signature headers is that there is code, some of which I've written, that looks for DKIM-Signature headers in a message and calls a DKIM verifier library if it sees them. DKIM is slow, do you don't want to waste time verifying messages with nothing to verify. If you don't change the DKIM-Signature header, all of this code keeps working when you upgrade your DKIM library. If you invent a new header, it doesn't. >The end result is two DKIM-Signature headers with different versions for >decades >to come. This will no doubt tweak some receiver is a negative way. Only if their validators are broken. I realize that's likely to be the case now and then but I can't feel too sorry for them. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Timeouts retrieving keys from ietf.org
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 surprisingly large number of people who still don't understand that NSI and Verisign separated a decade ago. They've had some high profile DNS screwups recently, like this one: http://blogs.cisco.com/security/hijacking-of-dns-records-from-network-solutions/ I can think of several registrars who are notably more competent and charge less. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Fwd: Request to move RFC 5617 (ADSP) to Historic
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: http://svn.apache.org/repos/asf/spamassassin/trunk/rules/60_adsp_override_dkim.cf This tells us that while dropping unsigned mail purporting to be from famous phish targets is generally a good idea (something I've always agreed with), ADSP records in the DNS aren't a useful way to make that happen. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic
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 innocent bystanders off an IETF mailing list, nobody's ever used it. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] That weird i= is most probably EDSP
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 that it gives a stable reference for people to see what you're proposing. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Weird i= in client mail
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 added signature tags. I would think that i= would be a poor tag to use since a lot of people already have opinions about what it means or doesn't mean. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Weird i= in client mail
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? R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Weird i= in client mail
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 used to corporate mail systems where user identities are tightly controlled and all the mail can be traced back to an individual user, so the i= was that user's mail address. Needless to say, in the wider world, there are a lot of mail systems that don't work that way. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Weird i= in client mail
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 injected (submit, webmail, whatever) and who the user was if it knows. It's fairly obvious if you look at it, but it's not really of any use to anyone but me for tracking down the occasional odd user behavior. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Final update to 4871bis for working group review
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 surreal to have these arguments about what changes to make to avoid the horrors of a duplicate From: attack that is and likely will always be entirely hypothetical, when we can't even get our act together to deprecate the l= option, including l=0. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Mostly off topic: For Ian Eiloart
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 i...@sussex.ac.uk: 139.184.14.92 does not like recipient. Remote host said: 550-5.1.7 Verification failed for jo...@iecc.com 550-5.1.7 Called: 64.57.183.56 550-5.1.7 Sent: RCPT TO:jo...@iecc.com 550-5.1.7 Response: 553 Not our message (5.7.1) 550-5.1.7 sender verification failed for jo...@iecc.com 550-5.1.7 see http://www.sussex.ac.uk/its/helpdesk/faq.php?faqid=1101 550 5.1.7 the mail server for iecc.com denied the existence of jo...@iecc.com. Giving up on 139.184.14.92.ietf-d...@mipassoc.org ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and signatures again
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 forgeable like From:, or on something reliable like d=. That doesn't seem magical to me. In my experience, if a mailing list is worth delivering at all, the addresses on the From: line are plenty reliable for bozo or anti-bozo filtering, and don't require an extra magic step to decide whether the signature is sufficiently related to the author's address. A plan that expects every contributor to have a separate d= reputation domain seems pretty unlikely to work outside the lab. Maybe I'm not not imaginative enough, but all the scenarios for recipients using contributor signatures are either things we are doing already without signatures, or things that nobody has shown any interest in doing in the past several decades even though there were other ways to do them. I can think of some reasonable uses for contributor signatures at the MLM, e.g., skip the verification step for adds or removes if enough previous requests from the same signer were confirmed. But not for passing them through to the recipients. As I've said, I'm not opposed to experiments so long as they don't involve breaking things that work now. So adding a signed A-R is fine, removing signature tags and headers and footers is not. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and signatures again
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 definitive of future needs and uses. In case it wasn't clear, I wasn't referring to DKIM reputation. I whitelist mail from lists I'm subscribed to using List-ID or some other bits of stable header text. In theory evil people could forge them, in practice it's never been a problem. So having a DKIM signature to be the stable text would be nice, but wouldn't fundamentally change what I do already. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
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 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] 8bit downgrades
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 signatures, which is why they should sign on the way out. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
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 tell you is whether the text being hash has changed, not how the body has changed or which header changed. There's no separate hash for individual header lines. On the other hand, you might want to look at page 24 of RFC 4871. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Certifying the DKIM public key?
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 WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
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 to help much, certainly not compared to the large cost of implementing code even more complex than what relaxed does now. And anyway, if your goal is for your message to survive, you should armor it better, not come up with more arcane ways to declare that it may be bleeding heavily but it's not dead yet. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM and mailing lists
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 according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] l= statistics was 23 again (sorry John) was Output
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, this path involves significant effort. One could argue that it's cleaner to drop it now and explore re-introducing it in the effort to develop that template. This makes sense, but I suspect it's better to design it and use a new tag with the semantics you need rather than to try to recycle l= R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Issue: Consider deprecating l=
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 part. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Ticket #24
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 http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!
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 that matches the signature. The parts of the i= beyond what's in the d= are just an assertion by the signer with no semantics, verifiable or otherwise, and are no more useful than any other unverified assertion. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary
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 at all, other than perhaps to say that the main output is d= rather than i=. (Even there, the way the verifier extracts them from the message hasn't changed.) But we've trimmed or removed a lot of what's called in the legal world dicta, non normative comments. A good example is all the stuff that said that a verifier edits the message, which was someone's (I honestly don't know whose) idea of how it would fit into an application, but which no implementation I'm aware of actually did. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary
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 Section 7.1, or a success result code) - If the signature did validate, the value of the d= tag, i.e., the signing domain The verifier MAY include other outputs, but this is implementation-dependent and not mandatory. The verifier MAY also include as secondary data some information indicating the specific cause of a failure. Do we need to say anything about the possibility that there are multiple signatures? R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Ticket #10: public key example -- no change needed
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 reason to change it, suggest closing the ticket. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Ticket 17: validating A-labels
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=
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 http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Taking responsibility for a message
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 for which it wants to accept responsibility. Good lord, no. Taking some reponsibility for the message is not the same as taking responsibility for some of the message. If you do that, that pretty much requires that we put back the stuff that says that a verifier produces an edited verision of the message, and you better be prepared to have a very, very, very long discussion about how much of a message a signature has to include for it to be enough and how to design various metrics about the relative value of signatures that cover more or less of the message. If you think a message is worth signing, sign it. If you don't, don't. Those are the only two options. When a list manager's domain signs a message, it's not asserting anything about the literary merit of the message, it's just saying the message satisfied whatever criteria it uses to select and pass along the messages it signs. (Yes, this is fairly tautological.) The reason you might not include part of a message in the signature is that you don't care if someone changes it. I don't sign Received: or X-Mailer: headers, because changing or deleting them is harmless. I do sign nearly everything else. This also suggests why the l= option is not useful, since it says I don't care if other people add stuff to the end of the message. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] About DKIM and mailing lists
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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Revision to draft-ietf-dkim-rfc4871bis posted
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 [RFC5890]. Other than that, it looks great. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: non-ascii header text
The only thing that's not obvious to me is whether the hash functions should hash the bytes of the UTF-8, or convert them to UTF wide characters and hash those. Depending on the way the MTA is written, either might seem more natural, but I'm inclined to say you hash the UTF-8 bytes because the SHA-1 and SHA-256 hash functions are defined on bytes, not wider things. Can you suggest the exact change to make here, or confirm there isn't one? No change needed, it's all hypothetical at this point anyway. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
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 those lines, I hope it enjoys the same robust success as GOSIP. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Working Group Last Call on 4871bis// A-label requirement
Sorry, this message makes no sense. The IETF has been working on non-ASCII domain names and e-mail for over a decade, and we are certainly not going to do random things that ignore that effort and the many RFCs that describe the use of IDNs in the DNS. Sounds like what we actually need is some way to point to the relevant work elsewhere in the IETF, even though it's apparently a moving target with many strong opinions continuing to shove it in multiple directions. Is it permissible to simply reference the working group's tools page? The current language references RFC 3490, my proposed change references RFC 5890, which supersedes 3490. The title of 5890 is Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework. How much more of a pointer does anyone need? R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] [dkim] #4: non-ascii header text
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 interested in the swamp of non-ASCII domain names and mail addresses, head over to the EAI WG. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: verifier message editing language
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 around the text and the algorithms long enough to believe that must be what the current text means so I didn't think twice about it. I tried to be careful to distinguish between the language that describes how the verifier uses l= to manage what's fed to the hash, which is OK, and the language which suggests that it produces an edited message, which is not. Take a look and see if you agree. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] ISSUE: non-ascii header text
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: Internationalized domain names MUST be encoded as described in [RFC3490]. To: Internationalized domain names MUST be represented as A-labels as described in [RFC5890]. Suggested new language under i= on page 23: Change: Internationalized domain names MUST be converted using the steps listed in Section 4 of [RFC3490] using the ToASCII function. To: Internationalized domain names MUST be represented as A-labels as described in [RFC5890]. 3.5, z= tag, remove paragraph Header fields with characters requiring conversion (perhaps from legacy MTAs that are not [RFC5322] compliant) SHOULD be converted as described in MIME Part Three [RFC2047]. DKIM only applies to RFC5322 compliant messages, RFC2047 does not provide conversions for all of the fields that can be copied in a z= header, and as soon as the EAI RFCs come out, which is likely to be soon, this advice will be wrong anyway. Free extra bonus confusion: the EAI WG is working on 5322 extensions that basically allow UTF-8 anywhere in messages handled by EAI-aware mail software, specifically including anywhere in an e-mail address. (That is, the domain part does not have to be an A-label.) I think it is reasonable to assume that a DKIM-Signature in an EAI message can include UTF-8 characters in any data field where it makes sense, e.g., d=, i=, s=, z=. DKIM-quoted-printable doesn't need to change since there's no need to quote any non-ASCII UTF-8 characters. The only thing that's not obvious to me is whether the hash functions should hash the bytes of the UTF-8, or convert them to UTF wide characters and hash those. Depending on the way the MTA is written, either might seem more natural, but I'm inclined to say you hash the UTF-8 bytes because the SHA-1 and SHA-256 hash functions are defined on bytes, not wider things. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Extensions (was RE: Proposal: Removal of AUID (i= tag/value))
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. At this point, i= is clearly nothing other than an opaque token with a funky syntax, which seems not to be very useful semantics. I get the impression that some people (not you) are under the misconception that if they can sneak their pet feature into the spec, that will force everyone to implement 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
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 boredom, you can't. And it's not just mailing lists. Don't forget all the mail that bots can send with real stolen credentials, and mail to a friend, blah blah. (This is not an invitation to reargue those points.) So we need to make a hole -- hopefully as small as possible -- in our ADSP-like protocol so that mailing list traffic can get through. Otherwise no one will deploy it in a useful way. Hmmn. Give that this is all entirely hypothetical, it belongs in the ASRG, not a standards group. See you there. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP, not, was Proposal: Removal of AUID (i= tag/value)
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 about the mail they send. If you don't know the sender, you can't believe the assertions, so they're useless. If you do know the sender, you don't need the assertions, so they're not useful. This is why x= is either useless ot not useful. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Interpretation, was Open issues in RFC4871bis
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 new Message-ID for it, according to Section 3.6.4 of RFC 5322. Would that help deterring on-the-fly auto-conversions? No, and it would be a bad idea, anyway. I often get two copies of a message, one sent directly to me, one relayed through a mailing list that changed it enough to break the signature. By any normal standard, they're the same message, and it's useful to be able to tell that from the common Message-ID. Breaking long-established mail semantics to punish people who don't run mail the way you like is not a good idea. And in any event, if people were sufficiently aware of DKIM to do what you suggest, they're aware enough to add a new signature which is the right thing to do. 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)
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. The only arguments I'm aware of is that hostile or incompetent DNS managers refuse to install key records, which isn't a very good reason to add cruft to a standard and I want to do it some other way which is even worse. R's, John ___ 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] 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] 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] Comments on draft-ietf-dkim-rfc4871bis-04
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 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 further suggest removing the second sentence However It is giving (normative) usage guidance for something that it has already made out of scope. I'd also take out the INFORMATIVE NOTE. It's an opaque token, so a signer can do anything with the mailbox part of that token that it wants. With a d=example.com, you could equally well use i=b...@example.com or i=@bob.example.com. They're different names, but receivers can infer equally little from each of them. The closest I can come to what you describe in Section 6.3 is: If the SDID is not the same as the address in the From: header field, the mail system SHOULD take pains to ensure that the actual SDID is clear to the reader. Good lord, no. My users don't see SDIDs or any other part of a DKIM signature. That goes in the same bit bucket with the advice to display the signed and unsigned parts of the message in different colors. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Work group future
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 to do with standards development. If at some point in the future we figure out something where there would be a benefit if everyone did it the same way, we can charter a son-of-DKIM group to work on it. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Full name problem
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 perhaps too complex version of the same.) Anyone can sign a message which contains this: From: PayPal security secur...@paypay.com or even this: From: PayPal security secur...@paypal.com Despite a great deal of wishful thinking to the contrary, DKIM signatures are only useful to the extent you recognize the signer and have a good or bad opinion of the mail they sign. This is one of the reasons I've argued that ADSP is not useful; that it is trivial to circumvent if it becomes widely enough used to be an issue for phishers. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-rfc4871bis-03 submitted
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' convenience. I'm pretty sure we already had this argument, and SHOULD NOT was the rough consensus. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] wildcards, draft-ietf-dkim-rfc4871bis-03 submitted
2. Advice about wildcards in TXT records. Proposed change: Add a note in section 6.1.2 warning about the effect of wildcard TXT records on finding DKIM key records. Section 3.6.2.1 currently says: INFORMATIVE OPERATIONAL NOTE: Wildcard DNS records (e.g., *.bar._domainkey.example.com) do not make sense in this context and should not be used. Note also that wildcards within domains (e.g., s._domainkey.*.example.com) are not supported by the DNS. That first sentence is just plain wrong. I have been using wildcard DNS records of exactly that form for months, and they work fine. I put a unique selector on each message, and when I get around to it will extract the DNS lookup info to figure out how many people are looking at my signatures. This may be morally reprehensible, but it does make sense. I suggest we delete the whole note. Section 6.1.2 says: NOTE: The use of wildcard TXT records in the DNS will produce a response to a DKIM query that is unlikely to be 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. This is only true if the name of the record doesn't include _domainkey, so *._domainkey.example.com or *.foo._domainkey.example.com is OK, but *.example.com is not. So I suggest we rewrite it as: NOTE: Wildcard TXT records whose names are not in the _domainkey subdomain 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 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] Re-thinking the organization of the DKIM spec
Having looked at the two drafts, although the idea seems reasonable, I don't think we should do it. At this point, as I understand it, any application other than DKIM is hypothetical, which means we can't tell where the split between generic DOSETA and specific DKIM should be. As a concrete example, signing netnews messages seems like it should be about as close to signing mail as you can get. But relaxed canonicalization, which is in DOSETA, is not useful for netnews, since messages are not reformatted after injection, and changes of the sort it allows are likely to indicate tampering. Since usenet has a longstanding forgery problem, I wouldn't want to allow SHA1, so I'd rather not have that in DOSETA base either. Yet i=AUID, which is made specific to DKIM, would be useful in the common case that the author of a posting identified him, her, or itself to the injection agent. While we're at it, z= might be useful for debugging. You could move those items back and forth easily enough, but then the next application comes along, say some sort of transaction log that adds new entries at the bottom, and you want to apply signatures to note the state of the log at particular times. Oops, we need l= for that, better move it from DKIM into DOSETA, too. Let me repeat that I don't think that the curent split is necessarily wrong, but I don't have any reason to think it's right, either. Since we know what DKIM is, I'd rather keep DKIM-bis as one document, and if it makes 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 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] Proposed documentation split between DKIM and DOSETA
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 to reorganize. As it stands, 4871 suffers from too much history, and as a result contains a great deal of stuff that has nothing to do with implementing the protocol. I would, for example, get rid of everything about MUAs beyond mentioning the bare facts that MUAs can do DKIM signing and verification. We should be able to produce docs that are both clearer and shorter. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] FW: New Version Notification for draft-kucherawy-authres-vbr-00
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 name of the certifier. I imagine that in a scoring system different certifiers would be weighted differently, e.g., a list of spamless signers vs. a list of signers that send a mix but it's not all spam. The domain name being verified seems redundant since it should appear in a previous DKIM, DK, SPF, or S-ID clause, but it doesn't hurt anything and I suppose makes parsing easier. I'd suggest calling the fields vbr-certifier and vbr-domain, So your example would be: Authentication-Results: mail-router.example.net; dkim=pass (good signature) header.d=newyork.example.com header.b=oINEO8hg; vbr=pass header.vbr-certifier=voucher.example.net header.vbr-domain=newyork.example.com R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
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 4871bis so it doesn't say that any more. And that makes DKIM overall a poor place to do anything other than mention specific issues that directly affect the DKIM security model. Agreed. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
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 likely to implement a spec that says that verifiers fail due to trivial syntax errors in the message. At this point, the only things I'm aware of that present a risk of bad rendering are duplicate headers and l= that doesn't cover the whole message. That list may grow in the future, but I doubt it will grow very fast. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
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 that the signature is making no statement about it. 2) Refuse outright to sign or verify any message that is not syntactically valid. Rather than be so absolutist, I'd say any message with syntax errors that are likely to cause MUAs or other applications to interpret it inconsistently. The thought is that two Subject lines is worth rejecting, an extra at sign in the Message-ID is not. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Commments and clarifications to 4871bis-02
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 note about UTF-8 at the bottom. Page 17, informative implementation note at the top: Delete message editing language or remove text that appears after the specified content length, perhaps based on other criteria Agree. (Though I see that on page 18) Right, it's p.18. (It was pretty late, one number starts to look a lot like another.) Page 24. first pp: delete or MAY choose other means of representing its users. An AUID need have no relationship to any user. Some of my AUIDs refer to web scripts and mailing lists. Actually I think that whole sentence is redundant to the earlier text of the paragraph. OK with me. Page 24, informative note: suggest deleting, again because AUID need have no relation to any user. Or perhaps rewrite as: INFORMATIVE NOTE: The Local-part of the i= tag is optional. It can include the domain part without the Local-part of the identity. Since there are a lot of reasons one might wish to leave out the local-part (don't know, don't want to say, don't feel like it), I'm fine with being this simplistic. Maybe what you have, but tack onto the end if the signer is unable or unwilling to specify a value there? Sure. Page 24, informative discussion: delete everything after the second sentence, since it doesn't help robustness or interoperability I could live with it being out, but I like it in there if only to document our deliberations so others later won't have spend the energy to go down the same path. Hmmn. Do we want to say DKIM doesn't identify individual users so don't try to make it do that? If so, it's probably better to put somewhere closer to the top. Page 27, x= first informative note: delete, doesn't help robustness or interoperability. (Neither does x= but that's a lost battle.) I'm not even sure I understand that remark. Can someone remind us of what it's trying to say? We had long arguments in which some people argued that one could keep bad guys from replaying messages by making the x= time short enough. Page 28, z= last pp: it says that header fields SHOULD be converted as described in MIME Part Three [RFC2047]. That document describes encoding of specific character sets such as ISO-8859-1. What character set is it supposed to use? Interesting. I suppose it should be just basic DKIM-quoted-printable conversion, meaning this whole paragraph can go except perhaps to indicate that even eight-bit data can be thus represented. This is one of those places where I don't know how much we can change without the IESG deciding to recycle. Just saying to use QP isn't adequate, since then you couldn't tell whether =BD is the 1/2 symbol in 8859-1, the oe ligature in 8859-15, or those three characters. My inclination is just to take it out, since at this point the 5322 rules say that any non-ASCII should already be MIME-encoded in the headers that z= copies so there shouldn't be anything to downcode. Page 29, sec 3.6.1, first pp: delete, since it doesn't help robustness or interoperability. I had to think about this one for a while. Would it even be appropriate to describe this as the DNS Text Representation, rather than just Text Representation? We might do it a different way in HTTP without XML, for example. There was a bunch of quite hypothetical discussion of other ways to represent and serve keys, none of which ever amounted to anything. That's why I'd rather wait until there actually are other kinds of keys before describing what they are. Page 29, description of v=, last sentence: compare that to the note on page 20 that I suggested deleting. Not sure what you're saying here; did you want that last sentence out? It's saying that if, 1.0 != 1, so much for increasing arithmetically. This language is fine. (My preferred order is 5, 2, 8, 9, 4, 7, 6, 3, 1, 0, which is of course alphabetical order in French.) Top of page 36, first sentence. If we leave in the message editing stuff, change to Hence, DKIM's mandatory output to a receive-side Identity Assessor is a single domain name and a possibly edited version of the message that has been verified. I don't like the edited version stuff. I'd prefer it to be positioned as an explicit indication of what fields and portion of the body were signed. If we agree that's an explicit output, that'd be a rather large change to the spec. My DKIM verifier Mail::DKIM just says yes or no, perhaps with a note about whether failure was DNS related or one of the hashes not matching. Page 36, informative discussion: delete it, since as far as I can tell what it says is we don't know what if anything an AUID will be used
Re: [ietf-dkim] the usual misunderstanding about what DKIM promises
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 signatures, they're about a million times less likely to be forged than without those signatures. That's not to say that yahoo.com forbid forgery, but they may find that their mail stream reputation improves if they take measures to prevent forgery. Sure. Yahoo goes to some effort to verify that its mail users control the addresses they use, by sending a test message with a URL the user has to click. But that's a characteristic of what Yahoo does which you could tie to a d=yahoo.com signature, not of DKIM in general. I make no attempt at all to control my users' From: lines, since I know them all and don't expect them to misbehave. I do put in trace info to tell who sent what, but you can't tell that from my DKIM signatures, either. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
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 the RFC5322 Section 3.6 checks? Sheesh, I think I've answered this at least three times now. In the absence of a DKIM signature, there is no reason to worry about doubled headers since there is no reason to think one is real and the other fake. They're only a threat when they provide a way to make a DKIM signed message render differently from what the signer expected. No DKIM - no threat - no special treatment. I don't know how to make this any clearer. That's why sorting modules don't worry about it now. As I've also said before, either DKIM has a SHOULD about doubled headers, or the equivalent advice goes into the folklore about what you have to do make DKIM useful. Personally, I think the latter would be a cruel joke on future implementors, but apparently other people feel differently. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
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 if it had structure problems. I'd like to make the trust model as simple as possible, preferably good signature - good messsage rather than good signature + tidy SMTP + correct headers + unobjectionable HTML + favorable phase of moon - good message If a message doesn't have a credible signature, then you still use the structure heuristics. OTOH, we already have a SHOULD that tells MUA writers to splatter the d= field somewhere in the GUI where the user can't ignore it Ugh, you're right. Now that I look at it, I'd like to completely delete Appendix D, since it says some things that are just wrong, i.e. language that implies that the signature contains someone's email address, and some stuff that hasn't been implemented and quite possibly never will be, e.g., highlighting the signed parts of the message. Personally, I have no idea which signing domains are credible and which aren't, and I have no interest in my MUA showing them to me so I can try and guess. That's much better handled in the MTA or MDA, using something like VBR to check the signer's credibility. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM and patents
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 associated with mail. Since it's from Microsoft, the description uses Sender ID but the claims, which are what counts, are phrased more generally. It was filed in 2005, so offhand I don't know how hard it would be to find earlier discussions of reputation based filtering. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
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 haven't previously verified is potentially hostile, either deliberately or by mistake. This refers to DNS keys, DKIM signatures, and the message you're trying to sign or verify. By the way, has everyone tested their signing code to see what happens if there's no From: header at all? Do we even agree what the right thing is? I'd think it'd be approximately the same as if the private signing key (the only other mandatory input I can think of at the moment) wasn't present. R's from PHL gate F18, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] FW: An issue with DKIM reporting extensions
- 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 none of the above, Alex. I've seen a enough spam masquerading as DSNs that I really wouldn't want to give DSNs a free pass. I also think that history has not been kind to people who made permanent changes to standards to work around temporary software limitations. If the MTA can't sign its DSNs, that's a bug, no matter how popular it is. (Come to think of it, my MTA has the same issue, although since I will never publish dkim=all, it's not functionally a bug.) If people are serious about signing all their mail, they should sign all their mail. Maybe they'll switch MTAs, maybe their popular MTA will eventually fix the DSN signing bug, and then they can publish dkim=all. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
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 that are signed and aren't supposed to be duplicated, aren't? I'm not sure, but right now I'm leaning toward the latter. I went through pretty much the same thought process and came to the same conclusion. It seems to me that there are some fairly cheap extra checks tht a verifier can make that will defend against malformed mail that would be likely to display confusingly in an MUA. Yes, it's technically not DKIM's job to verifiy 5322 conformance of incoming mail, but as Barry noted, it's not anyone else's job, either. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
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. Realistically useful advice probably has to influence rendering of messages. That might mean MUA participation or it might mean mailstore participation that removes all (typically) rendered headers that are unsigned. Gosh, I hope not. I'd like DKIM to be sturdy enough that I can trust stuff signed by people I know and not have to backstop it by tricks elsewhere to defend against malicious changes that DKIM didn't notice. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-ietf-dkim-mailinglists-03
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 lower status than a one-paragraph BCP saying only that. If we do that, I think that in fairness to people reading it, we should say explicitly which recommendations are based on practice, and which are paper designs a/k/a wild guesses. Unless I've missed some implementations, we have considerable experience with lists signing, and some anedotal experience with damage from ADSP, but everything else falls into the latter category. I'm also scratching my head about the bits that are intended to help people work around faulty DKIM implementations. Are there other IETF documents that do that? R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From
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 conclusion being don't do that. DKIM is only defined to sign valid messages. If a MUA does something undesirable with invalid messages, I'd encourage people to improve their MUAs. I expect that an MUA that does something wacky with extra From: lines also does something wacky with extra Subject: or other extra lines. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] signing and verifying invalid messages
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 implications thereof. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs
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 respect to DKIM, I'm hard pressed to imagine something that doesn't meet that requirement. I was thinking of the various proposals to rewrite From: addresses, to outlaw subject tags and message footers, and otherwise change the behaviors that MLM users expect in order to make them conform to various ideas of how DKIM and/or ADSP are supposed to work. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] envelope signatures, was Corner cases and loose ends
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 worth a shot? Probably not. BATV is about 2/3 of what a scheme like that would be. It has a bounce address with a signature hash of the original bounce address and a timestamp, with its main limitation being that it uses a private key rather than public key signature, which would be straightforward to add. It works well for me, but people say it causes problems due to changing bounce addresses for the same correspondent (a surprising amount of software keys on bounce address) and local parts longer than 64 characters, a limit that some MTAs still enforce. To limit replays, it could include both the bounce and recipient addresses in the hash, but that would recreate much of what's wrong with SPF. So unless you have a truly brilliant way to solve all these problems (we can always hope), I don't see any point to going down this road again. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Discussion lists and broadcast lists are not the same thing
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 on behalf of customers, their relationship to the customers allows them to be the customer, as far as mail authentication is concerned. There are some issues about how a customer delegates part of its identity to its ESP, but they are completely, totally, unrelated to the MLM issues we've been arguing about. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-rfc4871bis
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
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 has 2nd party signatures, where you encrypt something using the recipient's public key. ADSP has no equivalent. And as Steve noted, DKIM has no Nth party signatures for any N, so let's stop here. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM+ADSP = FAIL, and it's our fault
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 no good deed goes unpunished, you can be sure that whatever Paypal does, you'll get complaints about it, but it sure would be nice to have running code we can poke and try out and see how useful it is. R's, John Minor niggle: the order of writing the code and the I-D is not critical. It's not a bad to do them at the same time, so that you can circulate the I-D among people whose opinons you value and get possibly helpful suggestions before the concrete around the code hardens too much. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
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 do it, small providers including MAAWG and myself also do. Beyond that, you're right, we're at best guessing and at worst pulling stuff out of our whatevers. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
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 the old percent hack, embedding one address in another in a way that makes it obvious what the embedded address is. A privacy feature would presumably use an opaque token that only the MLM could relate to the target address. They deal with different problems, and I can see a lot more merit in the blinding than in the percent hack. There's prior art for both which anyone planning to implement something should be aware of, e.g. every mailer in the 1980s and 1990s that had a percent hack or equivalent, and blinded remailers like anon.penet.fi. For the zillionth time, anyone who actually thinks this is worth doing should spend an hour and WRITE IT DOWN as an Experimental I-D. If it's not worth documenting, it's certainly not worth implementing. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
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 implemented. We have a serious problem that people in this group have deeply incompatible ideas of what DKIM does. A lot of the arguments seem to be from people who believe that a DKIM signature can or should identify the individual author of a message, and that subscribers to mailing lists need assurances about the identity of list authors beyond the minimal level that has been adequate for the past twenty years. I have trouble understanding how anyone who is familiar with DKIM or with the operation of mailing lists could hold these positions, but it is quite obvious that some do. 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, I don't think we will produce anything that is useful to anyone. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
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, I don't think we will produce anything that is useful to anyone. If that's all we can say, I'd say don't bother. I don't see much value in the DKIM working group saying it thinks mail should be signed by DKIM. e.g. means such as or for example. I expect there's a fair amount we agree on. Maybe it's enough to be worth documenting, maybe not, but I think it would be more productive to see what we agree on rather than trying to force our pet projects into the document. I'll cheerfully give up references to S/MIME, if other people will give up on telling software developers how to rewrite MLMs to do things they've never done before. Don't forget that an experimental RFC is the accepted way to document a paper design to see if it gets any traction, as the EAI group did with various ways to represent non-ASCII e-mail addresses. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Mailing lists and s/mime dkim signatures - mua considerations
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 that over 90% of mlm signatures could be verified. Real life data, from a large company's mail stream. You have no data other than blatant assertions. Hmmn. Unless I have misread previous mail, this verification process involved a variety of heuristics unrelated to RFC 4871 such as replacing the headers with stuff derived from the z= tag and guessing that strings in the subject line might be tags added by the MLM. There's nothing wrong with doing that for your private use, but it's not DKIM. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-rfc4871bis
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 unrelated to any mailbox. The document never says who the user is, and I see no advantage to language that implies that there is one. Section 7: Should this section reiterate all of the stuff in 4871, or since the IANA registry already exists, just say what if anything is different since 4871? I don't know which is better. http://www.iana.org/assignments/dkim-parameters/dkim-parameters.xhtml R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] marketing dkim
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: line. In the unlikely event that one user engages in hostile spoofing of another, there's enough stuff in the Received: headers and logs to figure it out. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] marketing dkim
* 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 unduely lost email * BUT otherwise its useless in its current state. I wouldn't say that. It's quite useful as is to recognize signed mail from people you know. Paypal is the obvious example, their legit volume is high enough to most places that it's worth whitelisting their signed mail, which then lets you crank up the phish filters to catch the unsigned fakes. Be sure to tell them that ADSP is not useful, according to one of the authors of the ADSP RFC. Rather than fooling around with with the near zero S/N ratio of ADSP, whitelist people you know, perhaps put in a few special cases to drop unsigned mail from phish targets like Paypal and Amazon who sign all their mail. (Amazon still signs with DK, but most filters can deal with that.) If you're an ISP, signing your own mail is of limited value unless you exchange a lot of mail with Yahoo and Google, which you probably do. In that case it helps them to recognize your mail stream, and in Yahoo's case send back FBL reports when people hit the spam button. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] marketing dkim
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, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists annex MUA considerations
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 the already standard List-ID header, regardless of whether it's signed? In my experience, nearly all of the mail that makes it through existing spam filters and has a List-ID header is really from a list. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists annex MUA considerations
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 same thing it'll show if this is the From: line From: John Doe bo...@phishphest.ru As Dave often points out, this group has negligible expertise in user interface design. But these are certainly things you should put in an I-D about this proposal. Needless to say, none of this is appropriate for a document describing what MLMs do now or are likely to do in the near future. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists annex MUA considerations
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 any relevance to the authenticity or lack thereof of anything in a message's From: line? Really, S/MIME does what you want. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] On changing From: when sending through lists
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 decide to alter the From: header (e.g. by percent encoding), plus some other useful changes. ... [ various comments ] OK, fine. I'm looking forward to your I-D. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] what does DKIM do, was draft-ietf-dkim-mailinglists-01 review request
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 key is for the DKIM camp to be modest in its claims and goals. Mailing lists do what they have done for 30 years, and they're not going to change in any major way. To the extent that DKIM can help them do what they're going to do anyway, it's useful. The discussion of different kinds of lists is certainly helpful, but we risk going into the weeds when we start getting into complex analyses and advice for scenarios that seem (to me at least) pretty far fetched. So, for example, one of the things that lists have always done is send mail to people who have subscribed and presumably want it. Signing the outgoing mail should help receipients recognize the mail they want, so it makes sense to recommend that. On the other hand, providing per-contributor reputation clues to subscribers (beyond what's on the From: line) is something that lists have never done, so I think it's a poor idea to try to invent ways to do that. Does that make sense? R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] On changing From: when sending through lists
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 unimplemented paper designs, but what you do with them is to write them up in an I-D, ask the IETF to publish it as Experimental (something I'd encourage the WG to do for this one), and once there's at least a modest amount of real life experience, perhaps come back and propose an updated version for standards track. For a good idea of the way this can work, look at the EAI group. It published a variety of Experimental RFCs fof non-ASCII email addresses, and now after they have some experience, they're moving ahead with one that seems to work less badly than the others. It's not the one I'd have expected them to pick, but when I read the messages about their experience, I see why they made the choice they did. 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: - Who do you accept forwarded messages from? List subscribers? Anyone? Subscribers and people who sign up on a forward-me pseudo list? - If a forwarded message is rejected or bounces, what do you do? At what point should you stop trying to forward? If you get mail to an address that you don't forward any more do you reject it? Drop it? Something else? - What do you do when someone unsubscribes? When someone bounces off the list? When someone changes his subscription address? (Yes, there are MLMs that let you do that.) - What kind of spam filtering is appropriate for forwarded messages? For returning bounces? Should you try to distinguish between real bounces and spam to bounce addresses ? - Many MUAs collect outgoing addresses into the local address book, so people who really have one address will now appear to have N+1 if they subscribe to N lists. Is that a problem? Why or why not? If it's a problem, what should you do about it? That's all that occurs to me in five minutes, but I'm sure that if you actually try it, you'll find lots more. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Straw poll results
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 mail, and here's what I found: From: address 0.5 (Steve said he sorts on both from and list) List ID or similar: 8.5 To: or Cc:. 3 (approximation to sorting by list name) rcpt-to address:1 (unique address per list, I gather) The overwhelming majority sort list mail by the identity of the list, not by anything else. The one person who sometimes sorts by From: said that verifying the address wasn't an issue. Unless people can offer real life examples of situations where they remotely verify the identity of list contributors beyond using the name or address on the From: line, I hope we can put this meme of preserving incoming DKIM signatures to bed permanently. I realize there's all sorts of hypothetical situations one might imagine, but since we have over three decades of actual list practice, it seems unlikly that any important model of list usage isn't already in use somewhere now. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Straw poll results
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 to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Straw poll results
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 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? R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
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 delayed after the crlf.crlf, and that's not supposed to happen. Why not? My MTA usually does a whole spamassassin run between the end of data and the ack. It adds maybe five seconds, at a point where 5321 says the timeout should be ten minutes. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] yet more hypothetical mail managemenet scenarios
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 that you're convinced sign all their mail and I get an unsigned message from one of them, I'm bound to be extra suspicious of that. Oooh, it came from a mailing list so I don't care isn't the most likely response. I can't speak for other hypothetical lists of domains who sign all their mail, but the domains on my small but real drop list send no mail to mailing lists. I suppose it is hypothetically possible that there would be well run lists that would leak the occasional forged message from some ESP domains. But since that happens now basically never, I don't see any reason to spend any effort on it. Maybe you'd look at the list's signature and deliver it, maybe you'd look at the drop list and drop it, leading to one filtering error in umpteen million messages. If that's the worst problem you have with your mail filtering, you don't have any problems. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
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 process does't include attempts to guess what alternate form of a message with a broken signature might have been signed. (Even Mike admits it's against the rules when he does that.) A broken signature is the same as no signature. ADSP has some fairly specific advice about when not to use discardable, which is relevant here. Hence: Sec 3.2 2nd pp on page 9: most direct conflict operationally with DKIM - widest range of possible interactions with DKIM or something like that. I don't see any confict at all. Sec 3.3 the addition of some list-specific text to the top or bottom of the message body. - modification of the message body. Lists do a lot more than add tag lines, as described in subsequent paragraphs. under Minor body changes: pose an immediate problem - will probably cause any existing signatures not to verify. Broken signatures are not a problem. under Major body changes: delete with little or no hope of compensation by either the signer or the verifier. There's no such thing as compensation beyond relaxed canonicanization, which isn't relevant here after human list manager add who hand-edits messages (that would be me) next pp starting In general, change first sentence to: In general, an MLM subscriber cannot expect signatures applied before the message was processed by the MLM to be valid. Sec 3.4 2nd pp: delete sentence starting The shortest path Personally, I think the shortest path is for the MLM's MTA to sign its outgoing mail, but I don't think we have consensus either way, so just take it out. Last pp in 3.4: even if there were a new header, few MUAs would interpret it. Suggest taking out Rather than ... purpose since it's not a realistic alternative. Section 4.1: There's no reason not to sign all the mail you send to a list. Even if the MLM breaks the signature, the MLM itself can use the signature when deciding how to handle the message. The implication in the first paragraph that a broken signature is worse than no signature is just wrong according to 4871. Also, [ADSP] says in Appendix B not to send mail to lists from discardable domains. So I suggest replacing the first paragraph with a sentence or two encouraging people to sign mail sent to lists the same way they sign mail to anyone else. In the second pp, change If this is cause for concern to For domains that publish strict ADSP policies Section 4.2: channelling Dave, standards shouldn't suggest heuristics. So change the second sentence to something like Sites whose users subscribe to non-participating MLMs should be prepared for legitimate mail to arrive with no valid signature, just as it always has in the absence of DKIM. Section 4.3: I'd just delete it. The second pp is OK, but people using DKIM are supposed to know that already, aren't they? Section 5.1: I'd strengthen it to say that since people aren't supposed to send mail to lists from discardable domains in the first place, lists should reject it or perhaps (for people who've already subscribed so you know it's not spam blowback) drop the message and send back a note explaining why. Section 5.2, second pp: I don't understand the point of creating a separate signing domain for mail you send to lists. Why would the reputation of mail that people send to lists be better or worse than mail they send anywhere else? It's the same people, I don't see the point of a separate mailstream. ADSP isn't a good reason, since it says not to use discardable for domains with human senders. The third pp suggests that you're telling people to separate their human mailstream from their transactions and their spam blasts. If that's what you mean, I agree, but I'd encourage you to trim down the section and reword it to say so more clearly. In Section 5.4, either delete it or add a sentence at the front that says THE ADVICE IN THIS SECTION IS SOLELY INTENDED TO WORK AROUND BRAIN DAMAGE IN FILTERS THAT DO NOT IMPLEMENT DKIM ACCORDING TO THE SPECIFICATIONS. (Well, adding an A-R header isn't, but removing signatures that might be broken sure is.) In Section 5,5, add a ref to [ADSP] Appendix B.5 which says not to send discardable mail to lists. In Section 5.6, first pp: add a sentence noting that recipient system will likely use the MLM's signature to recognize list mail and develop a (presumably good) reputation for the list itself. In Section 5.7 add to the end if senders misuse ADSP or the like. Section 5.9, second pp: change to Receivers are advised to ignore Authentication-Results
Re: [ietf-dkim] Clarifying DKIM (etc.) expectations for mailing lists in the face of digests
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 recent phish I can think of on my lists is the I've been robbed in a foreign country and need money scam. But that invariably comes from a compromised account, where the crook has stolen the purported sender's credentials. How could DKIM or any signature scheme address that? R's, John PS: my apologies to anyone who's finding this repetitive ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
