I feel like I ought to comment. I've always had mixed emotions about l=, and I also agree with some of the things John Levine said.
When we first talked about l=, I thought it was kinda silly. What brought me around to it was a comment someone made that the receiver of a message with l= ought to cut the message at the end of l= and just drop all message content after that. With that observation, I turned around. The silly thing about was that it was essentially the statement by the authoritative domain, "well, I attest to generating this message, but only the first 1234 bytes of it, after that, well -- you're on your own." And this is indeed a silly thing. Why attest to a part of the message? However, once one looks at this and decides that the remaining characters ought to go into the bit bucket, it makes sense. When the sender is using l= to tell you they're only signing that, they're also saying that the tail end of the message is detritus or even passive forgery. That trailer really ought to go. We have a signed statement that it's not part of the message, after all. Now, all of a sudden it made sense to me. I even got excited about it. It has real meaning. (Now, one could also argue that without l= an MTA oughta chuck any unsigned parts of the message, as well, but let's not go there quite at this moment.) John Levine pointed out two important things: that the issues with l= stem from its misuse, not its use (and often misuse that is in violation of the standard), and also that we can't expect that people who are not following the standard are suddenly going to start following the standard if we change it. Each of these are important things to discuss. Let's take the case of someone who stupidly signed a message with l= and a small number, thus permitting a spammer to put actual bad stuff at the end (and not just an irrelevancy like whose antivirus product is failing to flag the malware in it). If a receiving MTA cut off the message at the end of l=, not only would this eliminate the bad content, it would deliver a message that would very likely look strange or bogus to the human who looked at it. "WTF, this message cuts off after only 12 characters -- huh, I guess I'll delete it." If software did this -- actually implemented what l= says (albeit passively, not actively) that the message is only N bytes long -- then the problem would go away, and this is a *better* solution than getting rid of l=. Now let me get to John's very important point. A standard is a description. It's almost like a grammar. It's a way that an implementor can use to know that if they want to express a concept X, they should lay out the bytes in that standard's form. At the same time, it says to the receiving implementor that when someone says X, here's what they were trying to say. If someone is not emitting a message according to the standard, then our changing the standard is rather like a photo of a gravestone I saw last week that read, "Here lies (not LAYS) ..." of an English teacher. My comment was that although I'm a descriptivist, I stan the message. That is relevant to us, because much of the discussion -- and John's point -- is that if implementors are not doing what the standard says (let alone things it implies), no amount of changing the standard is going to do something. Heck, we might as well put l= on DKIMs gravestone. Secondarily, implementors have a lot of leeway in what they do. There's nothing wrong with (also mentioned as a thing some people do) to consider wacky use of l= to be a sign that it's spam and just toss it. Moreover, that apparently got people to fix their code. From a standards and implementation standpoint, the best fix to this situation is not to get rid of l= as that's letting the shoddy implementors win. The best fix is for implementors to double down on l= and interpret it in the way that I think is the best way. If there's an l=, then drop everything afterwards. (Note that one could also implement this concept passively -- excising unsigned content from a message in a lot of places. If someone did it, it's outside the standard anyway, and would be a Good Thing for the integrity of the email ecosystem.) Summing up: I completely agree with John's real point. If people aren't following the standard, you aren't going to fix that by changing the standard, no matter what change you make. Secondarily, I think that a better fix for this situation to strictly interpret l= than get rid of it because a strict interpretation leads to messages being delivered to humans that are exactly what was said, but not what was meant. Make them say what they mean and mean what they say. Jon _______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org