[Mailman-Developers] Re: Footer settings question: how common is dash-dash-space?
On 2/1/21 3:25 AM, Stephen J. Turnbull wrote: > Richard Damon writes: > > > It is one of the 'Markdown' codes for a horizontal rule > > But 72 of them? Don't most people use about 5? But if they are using it AS the horizontal rule in a plain text document, it could easily be that long. > > will occasionally end up with a line like that when documenting an > > electrical signal that is always low (at least for a given > > example). > > OK, that's very plausible, and an excellent example. It will almost > never happen to me (and that instance was in 1997 or so ;-), but for > you it could be an ongoing, if occasional, annoyance. Not cool. As I said, I could see it quite likely AS a horizontal ruler in a 'plain text' document (like an RFC) > > that would make the definition not match the existing practice, so > > list settings would need to be edited. > > True, for those folks who have edited their footers. For the rest, > they get it with the upgrade, as the IETF list did. We can mitigate > that, with some risk of guessing wrong. But it's not a huge > consequence if we do guess wrong, I think. > > > Also, the question comes does the separator require and exact > > number of underscores > > Yes. I think 72 is the sweet spot, or maybe 70 with a trailing space. My guess is 72 is likely getting into the the increased chance of false positive range, being about the width of a 'standard' page. Something more like 40 or so, longer than for real Markdown, but narrower than for a real Horizontal Ruler might be safer. Adding the trailing space would really be needed to truly drop the false positive range. > > (and the frustrations of having the wrong number) > > I doubt anybody would notice. :-) Again, we can mitigate. We separate > the footer from the separator. I think we already do that in Mailman > 3. > > If you have time, please keep trying to poke holes in my ideas. > Whether to revert in Mailman 2 is entirely up to Mark, but Mailman 3 > is still up for discussion. I think the biggest issue is that common tools are unlikely to adopt the new standard quickly, especially any optional trimming. This says that many tools that currently would be trimming the footer (if it had the signature code in front of it) wouldn't trim the footer unless it was preceded by a signature (and many email clients/users DON'T setup the proper signature code by default). This says that to try and switch to this method begins with a loss in automatic trimming of the footer. The big problem is going to be convincing the industry that the advantages of a new separator for mailing lists is worth the effort for MUAs to support the new seperator code. > > Steve > ___ > Mailman-Developers mailing list -- mailman-developers@python.org > To unsubscribe send an email to mailman-developers-le...@python.org > https://mail.python.org/mailman3/lists/mailman-developers.python.org/ > Mailman FAQ: https://wiki.list.org/x/AgA3 > > Security Policy: https://wiki.list.org/x/QIA9 -- Richard Damon ___ Mailman-Developers mailing list -- mailman-developers@python.org To unsubscribe send an email to mailman-developers-le...@python.org https://mail.python.org/mailman3/lists/mailman-developers.python.org/ Mailman FAQ: https://wiki.list.org/x/AgA3 Security Policy: https://wiki.list.org/x/QIA9
[Mailman-Developers] Re: Footer settings question: how common is dash-dash-space?
On Sat, Jan 30, 2021 at 10:18:22PM -0500, Richard Damon wrote: > On 1/30/21 9:40 PM, Sam Kuper wrote: >> On Sat, Jan 30, 2021 at 11:22:43AM -0500, Richard Damon wrote: >>> 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: >> >> 1. Footer separators and signature separators should be >> machine-distinguishable from each other. >> >> 2. Footer separators should be distinguishable from likely body >> text, and should not be excessively long. >> >> 3. 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. I am aware of this. Hence my saying, in my previous message in this subthread, "I was not suggesting that the traditional Mailman footer separator was *perfect*." > 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. Indeed. I was aware of this, too, as I likewise indicated in my previous message. > 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. Indeed. > 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. That would be ideal, yes. But in practice, mail system developers do as they please. Some of them conscientiously respect RFCs and consider accessibility, etc. Some of them don't. For the developers who are conscientious, implementing a mechanism for handling ML footers is likely to mean writing a few lines of code. They might be able to partly re-use existing signature-handling code. Not a biggie. The developers who aren't conscientious will just ignore an RFC, as usual. > 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? Correction: a small amount of work for a small number of people. I believe that getting this right will occupy fewer developer-hours overall (i.e. across all affected parties, for the entire future), than leaving it wrong. By "leaving it wrong", I mean leaving Mailman continuing to use the signature separator line as a footer separator. Leaving it wrong will mean that everyone who wants to programmatically distinguish between signatures and ML footers will have to find or develop code for this, and probably tweak it endlessly and manually screen the output. *That* is a moderate-to-high amount of work for anyone unfortunate enough to need to do it. > 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. Thankfully few MLs (ab)use the signature separator as a ML footer separator, This means that few users receive the "benefit" (really a drawback, unless the user desires it) of having ML footers treated as though they were signatures. So, the number of users negatively impacted would be minuscule >> But if someone comes up with an even better separator (a line of >> underscores followed by a space, maybe?), then that's great. In case you overlooked it, I draw your attention to this point. All best, Sam -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you. ___ Mailman-Developers mailing list -- mailman-developers@python.org To unsubscribe send
[Mailman-Developers] Re: Footer settings question: how common is dash-dash-space?
On Sat, Jan 30, 2021 at 07:40:17PM +0100, Thomas Hochstein wrote: > "Stephen J. Turnbull" wrote: >> Why did we do that? > > Because it makes sense. The message footer is identical to a signature > in every respect: Ah, no. It is not. > [..] It doesn't matter if such a footer or signature is added by the > poster, by the mail client or server (for example in a corporate > setting) or by a mailing list manager. Actually yes, it does. Here are some use-cases that depend on being able to distinguish between a signature added by the sender, and a footer added by a mailing list. - A recipient may wish, in the mail-reading interface of their MUA, to hide mailing list footers (once you've seen one, you've seen them all, at least for any given ML), while still displaying user signatures (which can be diverse and interesting). - A milter designed to *selectively* strip or otherwise process signatures, ML footers, or both. - Email corpus researchers wishing to selectively analyse signatures or ML footers. >> It's not obvious to me that that was a good idea. Maybe it's better >> to distinguish the list's "signature" from a poster's signature by >> using a different separator. > > Why? Because they are not the same thing. Sam -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you. ___ Mailman-Developers mailing list -- mailman-developers@python.org To unsubscribe send an email to mailman-developers-le...@python.org https://mail.python.org/mailman3/lists/mailman-developers.python.org/ Mailman FAQ: https://wiki.list.org/x/AgA3 Security Policy: https://wiki.list.org/x/QIA9
[Mailman-Developers] Re: Footer settings question: how common is dash-dash-space?
Richard Damon writes: > It is one of the 'Markdown' codes for a horizontal rule But 72 of them? Don't most people use about 5? > will occasionally end up with a line like that when documenting an > electrical signal that is always low (at least for a given > example). OK, that's very plausible, and an excellent example. It will almost never happen to me (and that instance was in 1997 or so ;-), but for you it could be an ongoing, if occasional, annoyance. Not cool. > that would make the definition not match the existing practice, so > list settings would need to be edited. True, for those folks who have edited their footers. For the rest, they get it with the upgrade, as the IETF list did. We can mitigate that, with some risk of guessing wrong. But it's not a huge consequence if we do guess wrong, I think. > Also, the question comes does the separator require and exact > number of underscores Yes. I think 72 is the sweet spot, or maybe 70 with a trailing space. > (and the frustrations of having the wrong number) I doubt anybody would notice. :-) Again, we can mitigate. We separate the footer from the separator. I think we already do that in Mailman 3. If you have time, please keep trying to poke holes in my ideas. Whether to revert in Mailman 2 is entirely up to Mark, but Mailman 3 is still up for discussion. Steve ___ Mailman-Developers mailing list -- mailman-developers@python.org To unsubscribe send an email to mailman-developers-le...@python.org https://mail.python.org/mailman3/lists/mailman-developers.python.org/ Mailman FAQ: https://wiki.list.org/x/AgA3 Security Policy: https://wiki.list.org/x/QIA9
