Footer settings question: how common is dash-dash-space?
Hi,
my footer removal software fails on IETF's "last-call" mailing list because it looks for a line of underscores, whereas that list uses "-- ". That sequence is "the separator line between the body and the signature of a message", according to RFC 3676. However, I had never seen it in mailing list footers before.
My experience with mailing lists is limited, so I ask you. Is that sequence common enough to try and catch it in a footer removal function?
I asked the list owners, and they answered "We didn't choose these settings when the list was set up! It was probably just the default for that version of Mailman." Is that possible?
TIA Ale
On 1/29/21 12:14 AM, Alessandro Vesely wrote:
Hi,
my footer removal software fails on IETF's "last-call" mailing list because it looks for a line of underscores, whereas that list uses "-- ". That sequence is "the separator line between the body and the signature of a message", according to RFC 3676. However, I had never seen it in mailing list footers before.
My experience with mailing lists is limited, so I ask you. Is that sequence common enough to try and catch it in a footer removal function?
Probably yes.
I asked the list owners, and they answered "We didn't choose these settings when the list was set up! It was probably just the default for that version of Mailman." Is that possible?
According to https://www.ietf.org/mailman/listinfo/last-call that list is on Mailman 2.1.29. The default message footer separator was changed from "_______________________________________________" to "-- " as of Mailman 2.1.24
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro writes:
According to https://www.ietf.org/mailman/listinfo/last-call that list is on Mailman 2.1.29. The default message footer separator was changed from "_______________________________________________" to "-- " as of Mailman 2.1.24
Why did we do that? RFC 3676 doesn't standardize the practice, as far as I can tell. It simply mentions the convention and advises how to detect it properly (no requirements language for generators except that a line containing only "-- " must not end a paragraph when format=flowed is active).
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. In particular, if Ale wants to keep poster signatures, he has to keep track of which lists don't use footers. Maybe he doesn't, and the question is moot for this thread. But there is a potential for annoyance there.
If it makes sense, shouldn't we do it for Mailman 3 too?
Steve
On Sat, Jan 30, 2021 at 04:48:37PM +0900, Stephen J. Turnbull wrote:
Why did we do that? [..] 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.
+1
Sender signature != ML footer.
So, as Stephen says, the separators used to indicate those two distinct kinds of text block should be different.
Incidentally, if anyone reading this is working on an RFC that might have room to specify a standard for ML footers (or at least ML footer separators), please do!
Thanks :)
-- 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.
On 1/30/21 3:28 AM, Sam Kuper wrote:
On Sat, Jan 30, 2021 at 04:48:37PM +0900, Stephen J. Turnbull wrote:
Why did we do that? [..] 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. +1
Sender signature != ML footer.
So, as Stephen says, the separators used to indicate those two distinct kinds of text block should be different.
Incidentally, if anyone reading this is working on an RFC that might have room to specify a standard for ML footers (or at least ML footer separators), please do!
Thanks :)
The one advantage I can see for using the signature separator is that many (some?) email programs will automatically trim off the message after the separator, so it will automatically remove the list footer from a reply to the list.
-- Richard Damon
On Sat, Jan 30, 2021 at 06:19:41AM -0500, Richard Damon wrote:
On 1/30/21 3:28 AM, Sam Kuper wrote:
Sender signature != ML footer.
So, as Stephen says, the separators used to indicate those two distinct kinds of text block should be different.
The one advantage I can see for using the signature separator is that many (some?) email programs will automatically trim off the message after the separator, so it will automatically remove the list footer from a reply to the list.
Ideally, email clients ((MUAs) would have separate user-configurable options (with sensible defaults) for how to handle signatures and footers.
But 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.
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.
On 1/30/21 8:23 AM, Sam Kuper wrote:
On 1/30/21 3:28 AM, Sam Kuper wrote:
Sender signature != ML footer.
So, as Stephen says, the separators used to indicate those two distinct kinds of text block should be different. The one advantage I can see for using the signature separator is that many (some?) email programs will automatically trim off the message after the separator, so it will automatically remove the list footer from a reply to the list. Ideally, email clients ((MUAs) would have separate user-configurable
On Sat, Jan 30, 2021 at 06:19:41AM -0500, Richard Damon wrote: options (with sensible defaults) for how to handle signatures and footers.
But 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.
Sam
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. The signature seperator was specifically chosen to be very unlikely to naturally occur, including that single space at the end of the line.
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 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, and it almost certainly would NOT be the line of underscores that mailman used.
-- Richard Damon
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 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.
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
-- 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.
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
Richard Damon writes:
On 1/30/21 9:40 PM, Sam Kuper wrote:
All I am advocating is that:
- Footer 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.
Really? I can't recall ever seeing a long line of underscores in the wild -- except in my (accidentally) rms-baiting .sig (see below).
I don't have a strong opinion on this, myself (that's why I asked). But it's quite clear from RFC 3676 that there are tools that handle .signatures specially, and I'm not sure that they're all strippers. For example, they could be tools to extract contact information, in which case the naive implementation (go to EOF, back up to .sig separator, parse) would fail or even corrupt data if list footers use the "-- " convention. The fact that the RFC goes to the trouble of special-casing the .sig separator (it's specifically NOT format=flowed even if that is specified, and not subject to stuffing, DelSp, etc.) strongly suggests that there are a lot of naive tools out there.
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.
A slightly more precise spec than Sam's such as exactly 72 underscores followed by exactly one SPC (or even HT) should be unlkely to occur even in markdown.
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
Not the way IETF works. Almost certainly[1] this convention would be considered "not wire protocol" and therefore not in scope for IETF, except perhaps for an update to 3676 giving the footer separator the same treatment as the .sig separator (and that assumes my suggestion were adopted). If the distinction is desired by users, having Mailman document it, and IWBNI other MLMs adopted it, that would be enough. No RFC needed, really.
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.
I don't consider that a big loss if we switch back. Given the prevalence of top-posting nowadays, I doubt anybody cares about .sig stripping except us Boomers (and Mark, who is honorary Greatest Generation no matter his age :-). Especially since "-- " has only been the footer separator since June 2017. I doubt many users will have noticed (either way).
Steve
Footnotes: [1] In IETF mail standardization, all we can be certain of is uncertainty itself.
--
What are those straight lines? "XEmacs rules."
On 1/31/21 9:20 AM, Stephen J. Turnbull wrote:
Richard Damon writes:
On 1/30/21 9:40 PM, Sam Kuper wrote:
All I am advocating is that:
- Footer 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.
Really? I can't recall ever seeing a long line of underscores in the wild -- except in my (accidentally) rms-baiting .sig (see below).
It is one of the 'Markdown' codes for a horizontal rule (in fact, I would say it was used as the footer separator based on similar principles), and also not unheard of in 'ASCII Art' type applications. I will occasionally end up with a line like that when documenting an electrical signal that is always low (at least for a given example).
The 'two dashes' for a signature separator would have some similar issues, which is why the signature separator includes the space after. While it would be possible to define a footer separator as a string (of specified length) of underscores followed by a single space and then a new line, that would make the definition not match the existing practice, so list settings would need to be edited. Also, the question comes does the separator require and exact number of underscores (and the frustrations of having the wrong number) or just a course range, and the increased chance of false positives.
-- Richard Damon
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
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-leave@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
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:
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.
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.
"Stephen J. Turnbull" wrote:
Mark Sapiro writes:
According to https://www.ietf.org/mailman/listinfo/last-call that list is on Mailman 2.1.29. The default message footer separator was changed from "_______________________________________________" to "-- " as of Mailman 2.1.24
Why did we do that?
Because it makes sense. The message footer is identical to a signature in every respect: a standardized attachment to the actual message with no direct content reference to it, which you want to be able to hide and which should be suppressed in a reply. 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.
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?
-thh
Thomas Hochstein writes:
"Stephen J. Turnbull" wrote:
Because [reusing the .sig separator for the footer] makes sense.
I understand that they are syntactically identical.
The message footer is identical to a signature in every respect:
Not true. The mail standards are very careful to distinguish between *originator* elements, such as Reply-To, and those that may be used by third parties, such as Received and List-Id. This could go either way.
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 the semantics are different. One is for use by the author, the other for use by the list. I would not want .signatures stripped or suppressed because they are often interesting or amusing, but do want most footers suppressed (and would rarely care if they were stripped) because my MUA knows how to get list information (such as archives) out of the message header.
I'm not suggesting that my peculiarities are a good reason to override the sense of most users. It's an example of how the semantics are different, and might usefully be given different syntax.
Steve
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.
On 1/29/21 11:48 PM, Stephen J. Turnbull wrote:
Mark Sapiro writes:
According to https://www.ietf.org/mailman/listinfo/last-call that list is on Mailman 2.1.29. The default message footer separator was changed from "_______________________________________________" to "-- " as of Mailman 2.1.24
Why did we do that?
Because of https://bugs.launchpad.net/mailman/+bug/266269. You can see from that thread that I didn't want to do it, but I was apparently convinced :(
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro writes:
On 1/29/21 11:48 PM, Stephen J. Turnbull wrote:
Mark Sapiro writes:
According to https://www.ietf.org/mailman/listinfo/last-call that list is on Mailman 2.1.29. The default message footer separator was changed from "_______________________________________________" to "-- " as of Mailman 2.1.24
Why did we do that?
Because of https://bugs.launchpad.net/mailman/+bug/266269. You can see from that thread that I didn't want to do it, but I was apparently convinced :(
Thought it might be something like that. Feel free to ping me at @netiquette-busters if you want any help standards-nerding bad ideas into oblivion. :-)
I still don't know if it's a good idea or a bad idea, BTW. ;-)
Steve
participants (6)
-
Alessandro Vesely -
Mark Sapiro -
Richard Damon -
Sam Kuper -
Stephen J. Turnbull -
Thomas Hochstein