Re: [ietf-dkim] the usual misunderstanding about what DKIM promises
Barry, I think this might be a matter of definition for validity. I was not speaking of truthfulness, authentication or authorization. I am stating that a valid DKIM signature is making a series of validity statements or correctness assertions for the various parts it binds to the signature. This really has nothing to do with whether the validity statements are actually truthful and/or authorized to be used. See inline: Barry Leiba wrote: No matter how many times it is stated and repeated, it will never be true. If one wants this to be true, then remove the required binding the Author Address, A.K.A 5322.From. No, not at all. While I think it was probably a mistake to make the signing of ANY header fields MUST (we should have just put From in with the other SHOULD fields), the fact that From MUST be signed says, in itself, nothing about the *validity* of the address (nor the display name) in that field. That's up to the signer. And it can also be up to author domain to decide what a) signer domain it will and b) what fields are hashed to create the DKIM signature and implicit statements of validity for the parts the author decides to bind. It's all a question of what the signer is willing to sign. And that could also be the author deciding who is the signer and what parts are signed. Part of the on-going usual misunderstanding contention is the on-going attempts to separate the author from the picture when in fact, the author may very well be: 1) the signer itself, 2) use a different signing domain owned by the author, and//or 3) authorized outsourced 3rd party signer. I believe you are focused on the DKIM product implementation where the 3rd Party is the decider of what parts it binds to the signature. I believe this market has been covered and IMO, 4871bis remolding reflects what changes are necessary to cover this market. However, the next frontier to increase DKIM adoption is to get private domains to adopt DKIM and in this case, they will desire more control over what is bound to the signature and what signer domain is used to represent them for some out of scope reputation engines. I have two submission domains that I use. One, gmail.com, which does DKIM signing, will only allow me to use a From address after it has sent a test message to that address and seen that I can access the test message. So it's made *some* level of confirmation that I owned the address at the time I set it up. But there's no confirmation that I still own the address, and there's certainly no assessment of the display name that I associate with it. Gmail will sign mail that I send with my old IBM addresses in the From, though I have not worked for IBM for over a year and a half, and no longer have any authorization from IBM to use those addresses. Is that valid? I would suggest it is not valid from a authorization standpoint. Nonetheless, from the purity of a DKIM signature, your old IBM address would still be a statement of validity - to be authenticated at some later date (future DKIM results analyzer layer) perhaps. Small point of clarification. As far as I recall (last month), the GMAIL 2nd account setup is: - STARTTLS Test - User ID/Password AUTH test - Gmail does not DKIM sign these Smart Host setup path So yes, it is possible to use a valid but not authorized 2nd account setup. But your setup is still a statement of validity. I don't recall it testing the 2nd account as a MAIL FROM or RCPT TO. Maybe it did, but note this is a feature for outbound mail, not inbound. See note below regarding MAIL FROM checking. The other submission domain I sometimes use, which does not currently DKIM-sign, will let me put anything at all that I like in the From field, including, say, presid...@whitehouse.gov. It doesn't check, and it doesn't care, as long as I'm connected to their network when I send the message. Right, for most SMTP systems, the public port fundamental rule is: - Anonymous (no authentication/authorization), allow mail for local users only, i.e. no open relay - Authenticated/Authorized, allow mail for local or remote. So as long as you are Authenticated/Authorized, it will allow the transaction to be accepted and for some, if not most, it will skip all the checks. For us, we skip the 821 level checks and leave the 822 checks to the operators. For the private port (587), the submit protocol requires authentication (login) and it also provides additional enforcement rights to validate most or all parts of the transactions. One pitfall we found regarding authenticated sessions is that it might skip checking the MAIL FROM. The problem here is a non-delivery bounce to no where. So for our system, an authenticated user MAIL FROM is always checked against the local user database to make sure a bounce is deliverable. They could start signing with DKIM tomorrow. If they did, would you
Re: [ietf-dkim] the usual misunderstanding about what DKIM promises
On 10/23/2010 12:25 PM, Barry Leiba wrote: No, not at all. While I think it was probably a mistake to make the signing of ANY header fields MUST (we should have just put From in with the other SHOULD fields), the fact that From MUST be signed says, in itself, nothing about the *validity* of the address (nor the display name) in that field. That's up to the signer. It's all a question of what the signer is willing to sign. It is, I think, quite easy to read that last sentence as contradicting the preceding paragraph. With respect to the validity of information, it most definitely does NOT matter what is signed. The choice of what to sign affects the robustness of the tatoo in affixing the d= domain. That is, it affects how easy or difficult it is to re-purpose the signature with modifications to the message. I have two submission domains that I use. One, gmail.com, which does DKIM signing, will only allow me to use a From address after it has sent a test message to that address and seen that I can access the test message. So it's made *some* level of confirmation that I owned the address at the time I set it up. Well, this is a reasonably common type of example. I think it confuses the difference between a signer's policies, versus DKIM semantics. It is certainly true that different signers have wildly different meanings behind their signing behavior. However there is nothing in DKIM that communicates a signer's policies. (Obviously, ADSP is an example of a value-added semantic, but as we all have been reminding ourselves, that's an additional function.) The critical point, here, is the question: What can the verifier know? They cannot know about differential policies and in particular the choice of what parts of the message are covered by the signature communicates no additional semantics. The other submission domain I sometimes use, which does not currently DKIM-sign, will let me put anything at all that I like in the From ... The fact is that probably 99% of their users just use the proper domain in their From fields, and it doesn't matter. ... But that's all outside the scope of DKIM. Exactly. DKIM only provides assurance of the *signing* domain, and that the message has arrived substantially unchanged from when it was signed (modulo h= and c=). It is possible to read the first clause as meaning more than you actually meant, so I'll suggest a slight tweak which is still what you meant: DKIM only provides an assurance of the valid use of the signing domain name (d=), and that the message... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] the usual misunderstanding about what DKIM promises
Dave CROCKER wrote: I have two submission domains that I use. One, gmail.com, which does DKIM signing, will only allow me to use a From address after it has sent a test message to that address and seen that I can access the test message. So it's made *some* level of confirmation that I owned the address at the time I set it up. Well, this is a reasonably common type of example. I think it confuses the difference between a signer's policies, versus DKIM semantics. It is certainly true that different signers have wildly different meanings behind their signing behavior. However there is nothing in DKIM that communicates a signer's policies. (Obviously, ADSP is an example of a value-added semantic, but as we all have been reminding ourselves, that's an additional function.) The critical point, here, is the question: What can the verifier know? They cannot know about differential policies and in particular the choice of what parts of the message are covered by the signature communicates no additional semantics. I think that is a different question but one that is based on a fundamental premise of having statements of validity for cryptographically protected parts of the message. Does all this suggest that one must begin with a presumption of false information? In other words before you can ask the question How/what can the verifier know? it has to begin with the validity claims made by the signature and its bound parts. So when you sign a message with signer-domain and it has a required bind for a author domain, these are two minimal statements of validity to be verified and perhaps confirmed by some higher power. Perhaps Policy with its author-domain feed, and/or perhaps out of scope reputation engines with its signer-domain feed. I think it is the latter that you are pushing for. I would like to keep DKIM pure and open to not just be about the signer domain. I believe that as long we continue to minimize the statement of validity a valid DKIM signature provides for 5322.From, the more these usual misunderstandings will persist. There is a reason why it doesn't go away and might we are trying to promote an obscure and abstract concept of an independent signer domain that today it is still very hard to grasp, especially with the lack of application demonstration. On the other hand, the majority of the industry can grasp and feel the issues regarding a 5322.From and can better understand the idea that DKIM might be a technology to help protect it. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Proposal for new text about multiple header issues
Here's my proposal for a section in Security Considerations to talk about the malformation issues that have been discussed on the list. This is an addition to -02 directly and does not continue from any of the other proposals. 8.14 Malformed Inputs The universe of email is replete with software that forgives messages which do not conform strictly to the grammar that defines what valid email looks like. This is a long-standing practice known informally as the robustness principle, originally coined by Jon Postel: Be conservative in what you do, be liberal in what you accept from others. A number of popular email packages, including MTAs, MLMs, MUAs and so forth, thus forgive or ignore properties of messages that deviate from the standard format. A frequent example involves violations of Section 3.6 of [MAIL] which specifies minimum and maximum counts for particular header fields. Thus, a message with more than one From or Subject header field is not a legal email message, but most packages apply some trivial heuristic, e.g. use the first one and ignore the others, to interfere minimally with delivery of mail that might still be desirable to end users. This can expose those packages to subtle abuse vectors. For example, two different handlers of a message might identify the Subject field of a message by choosing the first one it finds. This would always produce the same result, regardless of whether the search is top-down or bottom-up, unless a message had more than one Subject field. Although [MAIL] specifically disallows this instance, it is tolerated by many mail handling agents, and so the possibility of confusion among implementations exists. This case becomes more interesting when one considers that a filtering agent might make a filtering decision based on one header field instance but a user agent might display the other. Knowing that this is the case, an attacker seeking to fool a user might exploit this to get past filters and render false data to a user. DKIM exacerbates this concern by assigning a signature to part or all of a message. It is possible that one could craft a message conforming to [MAIL], then affix a DKIM signature to it, and then add header fields atop the message that were not signed. Since many agents will overlook the fundamental invalidity of such a message, a DKIM verifier might produce a valid signature result while some other agent assumes an unsigned field is valid and applies it (e.g., renders it to a user) alongside some indication attesting to the message's validity. This is especially concerning where one of the fields in question has to do with an identity, such as From or Sender. Because of this, DKIM implementers are strongly advised to apply one or more of the following design decisions: 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. 3) For any header field listed in Section 3.6 of [MAIL] as having an upper bound on the number of times it can appear, include the name of that field one extra time in the h= portion of the signature to prevent addition of fraudulent instances. Any attachment of such fields after signing would thus invalidate the signature (see Section 3.5 and 5.4 for further discussion). ___ 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] Proposal for new text about multiple header issues
-Original Message- From: John Levine [mailto:jo...@iecc.com] Sent: Sunday, October 24, 2010 9:25 PM To: ietf-dkim@mipassoc.org Cc: Murray S. Kucherawy Subject: Re: [ietf-dkim] Proposal for new text about multiple header issues I mostly agree. (Wow!) Huzzah! 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. I'm fine with that if we think implementers will find it easier to construct a comprehensive likely list versus just enforcing the spec. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Statistics about DKIM and MIME
OpenDKIM now has enough data to make some interesting observations about signatures and MIME. As far as MIME encodings go (only the outermost encoding was counted), there was a pretty common theme: binary failed 4% of the time quoted-printable failed 4% of the time 7bit failed 7.7% of the time base64 failed 7.8% of the time 8bit failed 14% of the time 16bit (?!) never failed (though there was only one attempt) I expected 8bit to fail more for some reason. As far as MIME parts go (again, only the outermost MIME type was counted), most of them have about a 90-93% survival rate which is about in line with general signature survival rates. The one that stands out is multipart/signed (from RFC1847) which drops to about a 65% survival rate. I don't know much about how this is typically formatted or treated enroute, but it was easily the biggest outlier in the report. Not sure if that should be a surprise to us or not. ___ 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
On Oct 24, 2010, at 9:05 PM, Murray S. Kucherawy wrote: Here’s my proposal for a section in Security Considerations to talk about the malformation issues that have been discussed on the list. This is an addition to -02 directly and does not continue from any of the other proposals. I like the sentiment, and the background up to here, but... Because of this, DKIM implementers are strongly advised to apply one or more of the following design decisions: 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. There are a couple of issues with this. First, it implies that if a DKIM signature does cover a header, then that DKIM signature is saying that that header is valid, which isn't the case in general. Second, this is nearly meaningless operationally. for the sort of attack that's been envisioned (showing different author or subject in an apparently signed message), as there's no real way to consider any particular field as valid or invalid (unless you're communicating the information all the way to the MUAs display code, or you're deleting headers in transit - which are both possibilities, but ones that would need to be called out explicitly). 2) Refuse outright to sign or verify any message that is not syntactically valid. This is overly strong, as a lot of messages that are not 5322 valid are wanted (bare linefeeds, amongst other issues). Encouraging signers or verifiers to deny the existence of a DKIM identity in those cases just makes it harder to distinguish between wanted invalid mail and unwanted invalid mail. 3) For any header field listed in Section 3.6 of [MAIL] as having an upper bound on the number of times it can appear, include the name of that field one extra time in the “h=” portion of the signature to prevent addition of fraudulent instances. Any attachment of such fields after signing would thus invalidate the signature (see Section 3.5 and 5.4 for further discussion). This works, and is definitely on the right track as it's looking at the specific problem rather than broad 5322 compliance, but feels like a hack workaround by the signer for a problem that's simpler for the receiver to deal with directly. It is something we can encourage that's strictly within the bounds of a DKIM spec, but that doesn't make it the ideal solution to the problem. Something that's more to the point we're concerned about might be more like A mail system that considers DKIM signatures during mail delivery should treat with suspicion any email that has multiple copies of any header where RFC 5322 requires they have no more than one, as it may be an attempt to replay a DKIM signed message with different content. DKIM verifier implementors may consider messages that are malformed in this way as unsigned. Cheers, Steve ___ 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 universe of email is replete with software that forgives messages which do not conform strictly to the grammar that defines what valid email looks like. This is a long-standing practice known informally as the robustness principle, originally coined by Jon Postel: Be conservative in what you do, be liberal in what you accept from others. Well, I'm clearly the outlier here, but I think be liberal is protocol nonsense that has been accepted as conventional wisdom for far too long now. Put another way, Accept crud and pass it on constitutes good protocol design? Gimme a break. More particularly, DKIM is a security protocol which means that being liberal is entirely antithetical and highly risky to boot. In short, I don't think any part of DKIM should be based on be liberal because it always trades off security. Mark. ___ 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
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Mark Delany Sent: Sunday, October 24, 2010 9:56 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Proposal for new text about multiple header issues Well, I'm clearly the outlier here, but I think be liberal is protocol nonsense that has been accepted as conventional wisdom for far too long now. You're not the outlier. I quite agree. [...] In short, I don't think any part of DKIM should be based on be liberal because it always trades off security. What the text is trying to do is show the reader the caveats of the email world that exists today, not agreeing with or attempting to espouse that strategy. ___ 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
On 10/24/2010 9:55 PM, Mark Delany wrote: Well, I'm clearly the outlier here, but I think be liberal is protocol nonsense that has been accepted as conventional wisdom for far too long now. Put another way, Accept crud and pass it on constitutes good protocol design? Gimme a break. Jon Postel did not intend the interpretation that folks apply. As you note, carried to the current extreme, it produces silliness. His statement was meant to refer to the handling of protocol ambiguities. No matter how well a protocol is written, there are places that wind up being subject to slightly different interpretation. Especially during early stages of deployment, these ambiguities are discerned incrementally and often not resolved for quite awhile. In these circumstances, code that supports the differing interpretations is more robust. The situation with email comes from the rather different problem that complaints are from recipients and directed at their local operators, who have no control over the sources of the problems. So they hack their own code infinitely, to reduce local complaints. That produces the silly cruft. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
On Oct 24, 2010, at 9:55 PM, Mark Delany wrote: The universe of email is replete with software that forgives messages which do not conform strictly to the grammar that defines what valid email looks like. This is a long-standing practice known informally as the robustness principle, originally coined by Jon Postel: Be conservative in what you do, be liberal in what you accept from others. Well, I'm clearly the outlier here, but I think be liberal is protocol nonsense that has been accepted as conventional wisdom for far too long now. Put another way, Accept crud and pass it on constitutes good protocol design? Gimme a break. More particularly, DKIM is a security protocol which means that being liberal is entirely antithetical and highly risky to boot. In short, I don't think any part of DKIM should be based on be liberal because it always trades off security. A DKIM verifier generates a single bit, validly signed or not, and an identifier in the validly signed case. It doesn't pass mail along, well formed or not, nor does it control whether mail is passed on or not. All it can do is provide an identity for other pieces of the mail path to consider when making routing decisions. The only action a DKIM signer can take with regards to ill-formed email is to refuse to sign it. The only action a verifier can take with regards to ill-formed mail is to consider it unsigned, refusing to provide information to the rest of the mail delivery system. Given that, I don't think that either the DKIM signer or the DKIM verifier are the right place to take a stand against 5322 format violations. And that makes DKIM overall a poor place to do anything other than mention specific issues that directly affect the DKIM security model. Cheers, Steve ___ 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
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Steve Atkins Sent: Sunday, October 24, 2010 9:54 PM To: IETF DKIM WG Subject: Re: [ietf-dkim] Proposal for new text about multiple header issues 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. There are a couple of issues with this. First, it implies that if a DKIM signature does cover a header, then that DKIM signature is saying that that header is valid, which isn't the case in general. Ah right. Need to be meticulous here. How about: 1) During the handling of a message in conjunction with a DKIM result that indicates a valid signature, observe the distinction between those parts of the header and body that were covered by the signature and those that were not. Note that this is not to say unsigned content is not valid, but merely that the signature makes no statement about it. Second, this is nearly meaningless operationally. for the sort of attack that's been envisioned (showing different author or subject in an apparently signed message), as there's no real way to consider any particular field as valid or invalid (unless you're communicating the information all the way to the MUAs display code, or you're deleting headers in transit - which are both possibilities, but ones that would need to be called out explicitly). The text is intended to be generic, referring to any entity that might consume a DKIM pass result. The particularly interesting ones are of course the MUAs and anything that does authentication of a service (e.g., an MLM) based on a signed field, but I was trying to avoid talking about them specifically. 2) Refuse outright to sign or verify any message that is not syntactically valid. This is overly strong, as a lot of messages that are not 5322 valid are wanted (bare linefeeds, amongst other issues). Encouraging signers or verifiers to deny the existence of a DKIM identity in those cases just makes it harder to distinguish between wanted invalid mail and unwanted invalid mail. This is the informative equivalent of the normative SHOULD/MUST upon which people were insisting. If you think it would help, we could call out specifically 3.6 of 5322, but the risk there is that people will harden against that vector only to have something else come up later that we didn't call out specifically. Something that's more to the point we're concerned about might be more like A mail system that considers DKIM signatures during mail delivery should treat with suspicion any email that has multiple copies of any header where RFC 5322 requires they have no more than one, as it may be an attempt to replay a DKIM signed message with different content. DKIM verifier implementors may consider messages that are malformed in this way as unsigned. Maybe that can be some example-type text tacked on to the second bullet point? ___ 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
On Oct 24, 2010, at 10:15 PM, Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Steve Atkins Sent: Sunday, October 24, 2010 9:54 PM To: IETF DKIM WG Subject: Re: [ietf-dkim] Proposal for new text about multiple header issues 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. There are a couple of issues with this. First, it implies that if a DKIM signature does cover a header, then that DKIM signature is saying that that header is valid, which isn't the case in general. Ah right. Need to be meticulous here. How about: 1) During the handling of a message in conjunction with a DKIM result that indicates a valid signature, observe the distinction between those parts of the header and body that were covered by the signature and those that were not. Note that this is not to say unsigned content is not valid, but merely that the signature makes no statement about it. That still expands the API from the DKIM verifier quite a lot - it requires the verifier to explicitly list which headers are signed, and which aren't (that the h= field doesn't do that is what we're having problems with). It would also require that to be pushed all the way downstream to other pieces of software, perhaps via something similar to an extended Authentication-Results type of header. That's not impossible, but seems very complex for the specific problem we're considering - we just need to communicate This message violated 5322, specifically in a way that makes us think the sender is trying to game DKIM (either by flagging the mail as syntactically invalid and suspicious at some point in the mail stream, or invalidating the DKIM signature). Second, this is nearly meaningless operationally. for the sort of attack that's been envisioned (showing different author or subject in an apparently signed message), as there's no real way to consider any particular field as valid or invalid (unless you're communicating the information all the way to the MUAs display code, or you're deleting headers in transit - which are both possibilities, but ones that would need to be called out explicitly). The text is intended to be generic, referring to any entity that might consume a DKIM pass result. The particularly interesting ones are of course the MUAs and anything that does authentication of a service (e.g., an MLM) based on a signed field, but I was trying to avoid talking about them specifically. If we need to communicate a list of valid headers to downstream consumers of a DKIM pass result it's a lot more complex than a simple pass/fail and we'd need to consider what that API might be (partly so we're clear on what data in addition to a DKIM pass, here's your d= we're communicating). 2) Refuse outright to sign or verify any message that is not syntactically valid. This is overly strong, as a lot of messages that are not 5322 valid are wanted (bare linefeeds, amongst other issues). Encouraging signers or verifiers to deny the existence of a DKIM identity in those cases just makes it harder to distinguish between wanted invalid mail and unwanted invalid mail. This is the informative equivalent of the normative SHOULD/MUST upon which people were insisting. Yup. It's a backdoor SHOULD, and I don't like it for the same reason :). If you think it would help, we could call out specifically 3.6 of 5322, but the risk there is that people will harden against that vector only to have something else come up later that we didn't call out specifically. I'm more concerned with the suggestion that *any* violation of 5322 (or 2045 and friends - it's all syntax) is grounds for refusing to validate a message. I think that DKIM verifiers refusing to pass on a d= identifier due to trivial format violations is likely to reduce the quality of the mailstream rather than increase it. (Those violations may well be grounds for another part of the mail handler to reject the mail altogether, but that's outside DKIMs main job of providing an identifier to help the downstream mail handlers make informed decisions.) Focussing on just those issues that may affect the DKIM security model (which, if we kill off l=, is likely to just be adding unsigned headers) seems like it'd push implementors in a more useful direction. Something that's more to the point we're concerned about might be more like A mail system that considers DKIM signatures during mail delivery should treat with suspicion any email that has multiple copies of any header where RFC 5322 requires they have no more than one, as it may be an attempt
Re: [ietf-dkim] Proposal for new text about multiple header issues
Mark Delany wrote: The universe of email is replete with software that forgives messages which do not conform strictly to the grammar that defines what valid email looks like. This is a long-standing practice known informally as the robustness principle, originally coined by Jon Postel: Be conservative in what you do, be liberal in what you accept from others. Well, I'm clearly the outlier here, but I think be liberal is protocol nonsense that has been accepted as conventional wisdom for far too long now. Put another way, Accept crud and pass it on constitutes good protocol design? Gimme a break. More particularly, DKIM is a security protocol which means that being liberal is entirely antithetical and highly risky to boot. In short, I don't think any part of DKIM should be based on be liberal because it always trades off security. Really, its an inappropriate attempt in a history lesson and it actually doesn't apply here. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
