On 1/30/21 9:40 PM, Sam Kuper wrote:
On Sat, Jan 30, 2021 at 11:22:43AM -0500, Richard Damon wrote:
On 1/30/21 8:23 AM, Sam Kuper wrote:
[Unless] signatures and footers use distinct separators, it would not be practical for MUA developers to implement separate options for signature- and footer-handling. So, using distinct separators for footers compared to signatures still seems to me the right approach.
The issue is that the 'footer' separator that was used isn't really a truely distinctive line, just a line with some number of underscore that could easily just happen in a natural body of text. To be clear, I was not suggesting that the traditional Mailman footer separator was *perfect*. I'm not wedded to that particular footer separator.
All I am advocating is that:
Footer separators and signature separators should be machine-distinguishable from each other.
Footer separators should be distinguishable from likely body text, and should not be excessively long.
Signature separators should be distinguishable from likely body text, and should not be excessively long.
The problem is that the current Footer separator fails point 2 if 'likely' is interpreted as to by likely enough for a program to algorithmically trim a post based on it. In particular it looks like markdown code.
The key point with standard Signature separator was that the added space after the -- makes it have no needed presentation usages, so it was easy enough to carve out rules to keep automatic text generators from creating it.
The signature seperator was specifically chosen to be very unlikely to naturally occur, including that single space at the end of the line. Yes, I realise that.
Put differently: you and I both agree on point 3 above :)
The basic idea where this came from was that in the days with significant bandwidth limits, it was very important to get people in the habit of trimming messages, and the signature delimiter became a standard to allow 'good' tools to automatically eliminate the extra stuff that was added at the end of messages. I think netiquette was as much (if not more of) a motivation than bandwidth limits. But I may be wrong on this point. Anyway, it's tangential.
I sort of doubt that there is enough will to create and support some other 'standard' code to mark a second type of 'message ending' text, There's no harm in coming up with a sensible one and putting it in an RFC draft.
*Some* MUA developers probably care enough to implement it. Maybe Thunderbird (at least as an extension), Claws, Mutt, NeoMutt, Gnus, mu4e, etc.
So, I would ask you not to be defeatist about this.
The key aspect is that before MUA developers can really try to implement it as built in, the code needs to be reserved well enough that you won't find it occuring in the wild. That part of the spec is really needed to be implemented first or MUAs need a much more complicated code to allow an 'oops' you took too much mode.
I would say I am not being defeatist, but practical. The key factor here is that to implement your goal, you will need to get an RFC established and implemented that will add a requirement to all current mail systems (i.e. to NEVER generate a line that matches you footer seperator by accident) to allow for some systems to implement the optional feature of footer removal with independent control over footer and/or signature removal.
This is creating a moderate amount of work for a lot of people, so it really becomes a need to show a significant benefit. Is there REALLY a signifcant use case for a user want to remove list footers but not signatures?
And, it that use case important enough that it not only 'pays' for the work in creating a new RFC and getting it implemented, but also for the loss of footer trimming that happens because some people are still using MUAs that do the signature removal but haven't added the footer removal.
and it almost certainly would NOT be the line of underscores that mailman used. As I say, that's OK, as long as the three criteria above are met in a sensible way.
Given that Mailman's traditional separator is longstanding, and an unknown number of people have developed tooling around it, restoring it would probably be the best way to minimise disruption.
But if someone comes up with an even better separator (a line of underscores followed by a space, maybe?), then that's great.
All best,
Sam
-- Richard Damon