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
