> On May 24, 2024, at 19:55, John Levine <[email protected]> wrote:
>
> It appears that Jon Callas <[email protected]> said:
>> And look at it -- l= is intended to increase robustness and strictness of
>> interpreting the message.
>
> I don't see how that followes. In all the years I've been futzing with
> email I can't ever think of a time where a message showed up with
> added crud at the end and the right thing to do was to discard the
> crud and keep going. (I'm ignoring the old sendmail bug that added
> blank lines.) Maybe you can tell it's from a list and the crud is
> benign, or maybe you can't and you should treat it as suspicious.
And yet, I didn't make up the word robustness, it's there in the spec as Dave
quoted.
>
> The rationale I recall for l= is that it would let mailing lists put a
> footer on messages. That never seemed very persuasive, both because
> lists make a lot of other changes to messages, and because it opens up
> a hole you can drive an ocean liner throught.
And also lots of other trailers, like AV scanners, and so on. For mailing
lists, there are plenty of other issues, too, and let's not get into that, as
it's a mess that's orthogonal to this discussion.
>
> I also recall people claiming with a straight face that MUAs would
> show the signed and unsigned parts of a message in different colors so
> the user could decide which parts of it to believe. I hope I don't
> have to explain why that was a terrible idea.
You don't, at least not to me. I think it's a horrible idea, too. The Yahoo
guys considered it, and I vaguely remember there was some mail client that did
it once.
The bottom line for me is twofold:
1) It appears that the issue with l= is that implementers are not doing it
correctly, and that there's even lazy-unto-hostile use of it. If this is the
case, that implementers are not doing the spec properly, I don't see that
changing the spec is going to fix the issue, that of implementers not doing the
spec.
2) If we get a couple implementers to lean hard in the other direction -- an
anti-Postel's Law if you were, be conservative in what you generate and really
obsessive about compliance on receipt -- then it wouldn't need to be changed in
the spec.
I was originally against it because I thought it would be hinkey in ways not
dissimilar to the way it's got issues today. I was convinced that it was a good
idea if it were implemented well, which it's not. At the end of the day,
implementers have to either implement it right or not at all. I'm on board with
that. Removing it from the spec is a fine way to address the problem, providing
that we end up with implementers implement not doing it correctly.
I still think that implementers implementing it correctly is a better solution
than implementers removing it correctly, in part because removing it correctly
means handling some error condition when it's there (unless we agree that
ignoring it is fine).
Jon
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
