Closed Bug 58406 Opened 24 years ago Closed 14 years ago

[RFE] let user choose signature separator

Categories

(MailNews Core :: Composition, enhancement)

Product:
MailNews Core
Component:
Composition
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
Thunderbird 3.3a1

People

(Reporter: netdragon, Assigned: kieran)

References

(Blocks 1 open bug,
URL
)

Details

(Whiteboard: [gs])

Attachments

(3 files, 10 obsolete files)

a really simple UI for this
70.48 KB, image/png
Details
Added parens around conditional as requested
7.28 KB, patch
kieran
: review+
standard8
: superreview+
Details | Diff | Splinter Review
Unit test
6.10 KB, patch
Bienvenu
: review+
Details | Diff | Splinter Review 
There needs to be a setting to turn off -- being placed before the signature -
as I made my own seperator.
The "-- " signature separator is a widely used convention, and many email
clients (at least Outlook, Pine, and Mozilla from my cursory search) use this to
detect signatures (for example, to remove signatures from quoted material in
replies, or for message highlighting). Any other signature separators will not
be recognized by such software. If such a setting is eventually implemented, it
almost certainly wouldn't warrant a GUI control.

Outlook doesn't place the -- in front of the signatures ( It lets the users do 
it themselves). I don't think people should be forced to follow the "standard".
makign summary clearer, enhancement/rfe
Severity: trivial → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: -- Placed before signature → [RFE] let user choose signature seperator
Future...
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Summary: [RFE] let user choose signature seperator → [RFE] let user choose signature separator
There should definitely be an option to turn this separator off. I think this is
very confusing. Coming from Eudora where I had a separator defined in my
signature file I was very confused by the appearance of this "-- " separation, I
was looking everywhere to turn it off.
For News:
"-- " is part of the signature, see son-of-rfc-1036. An option to turn it off
therefore violates basic standards, and there should not be an option to remove it.

For Mail:
In my opinion the "-- " is not that important for e-mail, and why not have an
option to turn it off in this case.
I agree that "-- " shouldn't be allowed to change in outgoing messages, but I'd
suggest that user could select how that mark is *displayed* (that is, "-- "
could be replaced with any content during viewing, you already replace smileys
if requested).

*** Bug 149806 has been marked as a duplicate of this bug. ***
Please either hide or allow removal of the '--' separator, it's greatly anoying
and looks old fasioned.  

I understand that some email clients like and recognise it.  But it's my email
client, so I should be able to include/exclude what I want want sending an email
to somebody.
Feel free to remove it manually!
If I feel free to remove it, do I have to delete each '-- ' on each message or
is there a pref to get rid of it in the sig file or prefs........ 

I would favour being able to edit the file I specify as the sig file so my
ending appeared with my name being part of the message - the ending looking like
this:

Regards, Gavin
-- 

Then any garbage sig put by any mailing list etc

At the moment even if I have a sig with the '-- ' characters mozilla puts in
it's own '-- ' before my specified sig loads. I consider the sig to be more in
terms of BBS sigs -quoted text and promo text - and don't think of my name as
being a sig (OK it's closer to a 'signature' than BBS style sigs). If I don't
specify a sig nothing is put in. I'd like a pref to control this but do try to
convince me to change my ways if you feel I'm asking too much......

just chiming in to say that I too do not enjoy having to remove the "-- " on
every email i send out and would be happy to have a pref for this.
I agree that this being able to turn off the '--' separator would be beneficial.
 I remove this from about 50 emails a day.  Thanks
It's extremely annoying to have the signature delimitier automatically placed
before a signature file like
bye
-- 
some text

Two remedies:
1. enable the user to turn off the automatic delimiter
2. look not only at the first four bytes for an existing delimiter in the sig
but at the whole sig.

The first one is simple (except the prefs get stuff) but makes it possible for
users add none or the wrong delimiter (I don't mind - if the user wants to
disgrace himself, he should -, but some commenters here do).
The second one is more costly (string search) but fool-safe.

That's at least true for non-HTML-sigs as the classic delimiter doesn't work in
HTML (because of the trailing <br>).
This is No 2 I wrote about. It's not considered to be complete, it should just
show what I mean.
Searching for "-- \r" and "-- \n" would work to (and make the existing
firstFourChars.Equals ifs obsolete), but wouldn't be that save.
For attachment 134987 [details] [diff] [review]

I like your idea, but what if I use ***** ////// or anything else as my
seperator? According to comment #6, its only necessary for News to use dashes
according to the RFC (and can't we just blow off the RFC anyway for news? Are --
that important?)

We need to search for any non-alphanumeric characters that repeat on the first line.

How many people do:

>1111111111111111
>
>My Signature - this is a really lame signature
>And I'm too boring to write anything else. Look
>at my Signature Seperator, its 11111 kewl huh?


Not many, so non-alphanumeric search is the way to go, imho.
What's the intention of a signature delimiter nobody else will recognize?
People will recognize it visually. I don't filter out signatures, but anything
reasonable, I'll realize is a seperator. Any combination of non-alphanumeric
characters could constitute a signature seperator. It wouldn't take long to
realize its a seperator. Example:


Hi John,
I have the new circuit diagrams you requested. They will be on FTP.

====================

Carpe Dium
Mike Arbuckle, MS Computer Systems Engineering



Scanning that for five seconds, it would be quite obvious what the signature
seperator is.

> Scanning that for five seconds, it would be quite obvious what the signature
> seperator is.

yes, for Brain 1.0 it would be obvious. But not for Mozilla, which cannot guess
what's your separator, but which - with a standard separator - can
- cut off the signature when replying (Seeing the mail threads where people
  quote 20 signatures, 5 lines each, for *nothing*, I really love this feature.)
- display the signature in a different color/layout when displaying the mail.
  This means it will take me 0.01 seconds to realize that it's a signature, and
  that I do not even need to think about looking into it's direction. Given the
  sheer number of messages some people have to read every day, this sums up to a
  remarkable amount of saved time.

> and can't we just blow off the RFC anyway

No, we shouldn't. The point is, a signature doesn't belong to the real mail
content, and having a *standard* delimiter enables *intelligent* mail cliens to
treat them appropriately (probably in more situations than the 2 outlined above).

The problem with people having a non-standard delimiter is that it's wasting
resources of other people who have to read the messages ...
Cross-References: (pardon the cross-post)

To save others the time I spent researching this issue ... these
bugs solve essentially the same problem:  

The signature delimiter, "--[space]/n", does not reliably indicate
that the rest of the e-mail is a signature.  Assuming it is reliable, and
processing mail on that basis, causes problems.

Bug 54570  - No end-of-signature detection in message display
Bug 58406  - [RFE] let user choose signature separator
Bug 216728 - Let delimiter behaviour with position of signature be overridden

Personally, I see a broken, buggy feature; whatever the intent is, it doesn't
work.  Do it right or at least give people the option to turn it off.  I found
the bug while helping a user in the Mozillazine forums:

http://forums.mozillazine.org/viewtopic.php?p=379925&sid=5d5307d9baecffa10d28d46c649914fd#379925

Comment on attachment 134987 [details] [diff] [review]
proposed patch with automatic decision

This patch has been checked in as part of bug 229044.
Attachment #134987 - Attachment is obsolete: true
Quanxi, digests are a problem, yes. But in regard of detecting the separator and
don't quote the rest. At least this and bug 216728 is about inserting the separator.
This is the single most important issue for me which is why I've registered now.
 I wondered if it would have been "fixed" in 0.5 which I've just installed, but
no :(

I too would like to see the (new line)"-- "(new line) as an option which should
be enabled by default, most people will then leave it that way.

I'd use it, but I want to be able to put it in place myself!
*** Bug 232621 has been marked as a duplicate of this bug. ***
*** Bug 232621 has been marked as a duplicate of this bug. ***
Just point me to the RFC that says that a mailer 'MUST' place a '--' as a sig
seperator and I for one will not complain. But, until that happens, there needs
to be an option to turn it off. This causes more problems than you guys seem to
think it fixes.
*** Bug 257485 has been marked as a duplicate of this bug. ***
*** Bug 239239 has been marked as a duplicate of this bug. ***
I can see justification for defaulting to RFC 2646
(http://www.faqs.org/rfcs/rfc2646.html) for newsgroup and private message
addressing. However the bulk of thunderbird users in the future and probably
right now do not use or even know what a newsgroup is. I still feel that it
would be nice to bring the quoting (default above instead of below) and reply
(signature removed automatically) sanity to the private message space but im
afraid there is a lot of resistance as noted by this 4 year old RFE. 

My suggestion to ameliorate the masses is provide the ability to remove the
double dashes but default them to the on position. People who willingly choose
to flaunt the RFC should not be limited by our mail client. I think we should
encourage good practices and tolerate bad ones. We can't change the world if
they dont use the software in the first place.

Proposed functionality:

Dashes ON:
1. Add newline
2. Add 2 dashes plus newline
3. Add signature content (respecting full contents)

Dashes OFF:
1. Add newline
2. Add signiture content (respecting full contents)

This behavior allows for all types of signature permutations including custom
delimiters and full control of spacing.
Product: MailNews → Core
I'd personally love to see an option in Thunderbird 1.0 that enables users to 
switch off the double-dash. These days, lots of people use HTML signatures 
(which perhaps include perhaps a small logo), and the dashes make the mail 
look ugly. My Outlook doesn't add dashes either: i want to be in control of 
what appears in my emails and what doesn't!
I agree with the opinion that it should be given as an option.  Part of the
reason I loved Mozilla was that I could change just about any function of the
program I liked, in terms of visual style or functionality of a feature (for
example, I hate when my bookmarks show ...'s if they're too long; I prefer to
let them extend all the way out on my Personal Toolbar).

And yet Thunderbird doesn't give you this option.  Unfortunately, even with the
option not there in 1.0, I think I'm actually going to have to go into
thunderbird.exe with a hex editor and manually remove the '-- ' from the program
in the first place, because I don't feel that I should have to abide by an
outdated "standard" should I choose not to.

To the person who said that Pine added the signature dashes in: You're quite
correct, and yet not quite at all.  Pine did what Thunderbird should: It had a
configuration option called 'enable-sig-dashes' that you could very easily turn
off.  Why is it so hard to do the same in TB?
This should be an option.  Sure it's used by a lot of programs as a content 
delimiter for email messages.  However I've used Eudora and it uses an <hr> 
tag to delimit it's message from a signature.  Why can't we have the option as 
well to simply change what the delimiter is?

I personally do use a delimter, but just not the dashes so it would be nice to 
have the option to:

not use the delimiter
use the default delimiter
use a custom delimiter
The delimiter "-- \n" convention was chosen for /technical/ reasons, not beauty.
Its usefulness lies in the automatic detectability of a signature; if everyone
would be using his own fancy something, that would be lost...
(In reply to comment #33)
> The delimiter "-- \n" convention was chosen for /technical/ reasons, not 
beauty.
> Its usefulness lies in the automatic detectability of a signature; if 
everyone
> would be using his own fancy something, that would be lost...

But most people don't know this! So, what if i just put some dashes somewhere 
in my email, e.g., to make something stand out, like so:

This is a sample email message. You were asking for my address, here it is:

--
My Name
454 Mystreet
Mycity, CA
USA
--

What does it do then?? Make my email look different from the dashes down? 
(like, light-gray) People don't know this convention anymore, and so the email 
program shouldn't do things differently based on the body of an email message, 
which could be anything. I want to have control over my emails: at least make 
it optional!

>The delimiter "-- \n" convention was chosen for /technical/ reasons, not beauty.
>Its usefulness lies in the automatic detectability of a signature; if everyone
>would be using his own fancy something, that would be lost...

Yeah, but the problem is that the idea of /customizability/ is lost.  Regardless
of whatever de facto standards exist, there are always reasons for going against
standards.  A great example I've seen is that of digest-mode mailing lists,
which disappear when being replied to because of one single delimiter.  One of
the great things about the Mozilla suite is that it gives the USER the ability
to change things about it (in Firefox, for example, I routinely edit the CSS
files to make tiny tweaks in my themes).

In short, it's not about convention.  It's about preference.  As was stated
before, it's YOUR job to edit your replies; don't make us suffer because you're
lazy.

However, in the interest of cooperation, I just had a thought:

Would it be possible to use HTML comments to put a delimiter in?  For example,
if I were to use, on three lines in my signature file, a <!--\n, followed by the
delimiter, followed by a -->, to make it recognize that there's a delimiter in
it but still hide it?

Hmm... I guess not.  In an HTML email it MIGHT work (but then as soon as the
email was replied to it would strip everything after the delimiter, thus leaving
an opening HTML comment marking.  It also wouldn't work for plain-text emails.
> But most people don't know this! So, what if i just put some dashes somewhere 
> in my email, e.g., to make something stand out, like so:
> 
> This is a sample email message. You were asking for my address, here it is:
> 
> --
> My Name
> 454 Mystreet
> Mycity, CA
> USA
> --
> 
> What does it do then??

Well, it wouldn't do anything, because the delimiter for an email signature
includes a space after the two dashes.  But you're right about the idea of it. 
However, it only takes effect when the email is replied to; it wouldn't have any
effect on just reading the message.
See also bug 344400
*** Bug 344400 has been marked as a duplicate of this bug. ***
I strongly *discourage* changing the defacto standard sig delimiter "-- " to anything else.

this delimiter has been well established ever since. Just because some **** apps (outlook (express),...) are not able to set and detect proper delimiters we don't have to adopt this shortcoming!
NOBODY is asking that the so-called "defacto standard sig delimiter" no be the default. We have been asking that an option be provide to "not automatically insert" the special line and to ignore it under other conditions.
The "standard" is not really a standard, just some 'idea' that someone came up with and started pushing that it be used. It's just like the fake "standard" that quotes should be at the top of the email and not at the bottom. It's **** that is being pushed by a few "I am smarter than you" hackers. 
It's been over 6 years since we asked that a new option be provided, and all we ever get from the developers is: "NO, because we know better." The one option has caused me much pain and suffering as stuff was "lost" after the dashs line when  replying. We just want an option, and we have been patient for 6 years. And some of us would jump to another client because of this issue if there was another good linux email client. 
Frankly speaking it **** me off receiving mail which does not contain a sig delimiter! I have to chop off the sig by myself everytime I hit reply.

When some people would start to change that in their client, I would just stop replying them cuz their client settings just suck.
If you want it to be a real standard, then you need to get off your rear and get it adopted as part of an RFC (or equal). You get it adopted as a standard and we will just all shut up. 
FYI, you can throw away any email you want that is not written to your perfect "way", that is your right. Just like it is my right to not put the dashs line in if I don't want to since there is not RFC that requires it.
> Frankly speaking it **** me off receiving mail which does not contain
> a sig delimiter! I have to chop off the sig by myself everytime I hit
> reply.

Netiquette dictates that it's your job to edit the reply before it's sent anyway.    If you choose to be rude and not edit the message, why should somebody else have to tailor THEIR message just to save you a whopping five seconds?

Let me remind some of you of something that I said way at the top of this bug: There are email clients such as PINE that have had the option to remove sigdashes for YEARS.  I don't know anybody who doubts PINE's adherence to the RFC, so why is it such a big deal with Thunderbird?  I should be able to configure my mail client the way that *I* want.  As it stands, I have to use a binary file editor to remove those sigdashes in the executable itself, and I have to do it after each update.  It's not the end of the world for me, since I know where to look, but it would certainly be easier if it was just an option in the program.
I would also add that it is very annoying to have the "--" added before my signature. Outlook and Outlook Express, two of the most popular email apps out there, do NOT do this. Not everyone wants or needs an email sig prefix! And if they do, they should just included in their actual sig.
> I would also add that it is very annoying to have the "--" added before my
> signature.

So would I be if it indeed would be just a "--". But, Lo!, it's a "-- ", the famous sig delimiter. If you want to add a sig, it's preceeded by a sig delimiter. If there's no sig delimiter, there simply isn't a sig...

Not having a sig is perfectly legal, though - you're looking for a message template to be used when replying/composing.

> Outlook and Outlook Express, two of the most popular email apps out
> there

LOL. Popular, yay! ;-)

> do NOT do this.

Bustage is no matter of numbers.

> Not everyone wants or needs an email sig prefix! And if
> they do, they should just included in their actual sig.

A sig is a sig is a sig is a sig. Yours isn't.

Karsten, 
You are flat wrong. There is NO RFC that says that the dashs line MUST or even just MAY be included. This whole "standard" speech is just a whole lot of BS. It's not a standard and never has been a standard. It's just a bunch of people who "think they know what is best for everyone" trying to force something down everyones throat without going though the correct RFC standards process because they know they don't have a snowballs chance in hell in getting this turned into a proper standard via an RFC.
(In reply to comment #47)
> Karsten, 
> You are flat wrong. There is NO RFC that says that the dashs line MUST or even
> just MAY be included. This whole "standard" speech is just a whole lot of BS.
> It's not a standard and never has been a standard. It's just a bunch of people
> who "think they know what is best for everyone" trying to force something down
> everyones throat without going though the correct RFC standards process because
> they know they don't have a snowballs chance in hell in getting this turned
> into a proper standard via an RFC.
> 


Do we need a RFC here??? Isnt common sense appropriate enough????

I wan NOT willing to strip off 6 lines of "sig" while replying if TB could do on  it's own with a proper delimiter.

This is the same stuff like ppl reply with their reply ABOVE the question which really **** me off.
> I wan NOT willing to strip off 6 lines of "sig" while replying
> if TB could do on  it's own with a proper delimiter.

So the rest of us should be forced into your way of thinking.  That's really embracing the open-source spirit.
(In reply to comment #49)
> > I wan NOT willing to strip off 6 lines of "sig" while replying
> > if TB could do on  it's own with a proper delimiter.
> 
> So the rest of us should be forced into your way of thinking.  That's really
> embracing the open-source spirit.

where is the relation to open-source??

are you willing read in your mail the same template over and over again?
Are you really stating that someone should do your sig work?

Explain me why a sig should be a part of the mail text and not be handled separately?

A sig is always out of context and should be handled separately.


As has already been stated several times, there's no standard that dictates a sig delimiter.  So what you're trying to enforce is an arbitrary standard.  That's what goes against the open-source spirit.

Also, as I've said more than once, netiquette dictates that editing the reply is YOUR responsibility.  What you want is for the program to do something for you because you're lazy.

We've never stated that Thunderbird would neither (a) not recognize the de facto "-- \n" delimiter nor (b) not allow you to use it in your own emails.  We're only asking for an OPTION to disable it should we CHOOSE to.  Why?  Because sometimes, some users want to do things differently.  I don't see why it can't even be an OPTION.
If you declare this as the opposite of the open-source spirit so do you declare all endeavour as against OSS which try to unify competing APIs under linux e.g. which do all the same and produce a mess like ALSA and other sound APIs.

sometimes you just need a consensus and a consensus is almost always an arbitrary decision about the best effort which can be done to satisfy virtually every need.
Shortcoming won't vanish!

no one would gain any benefit from if you would start to use "<>" as your sig separator cuz no app would recognize it, it would be superfluous anyway.
Ah, but there you go again, telling me that I have to use SOMETHING as a sig delimiter in the first place.  Why?  Again I say that if even PINE allows us the option of choosing whether we want to show a sig delimiter (a program that has been in existence for 18 years), why shouldn't Thunderbird?

The fact of the matter is that you're never going to convince those of us who think it unnecessary that it absolutely has to be there.  And I would go so far as to say that there are a lot more people that believe it's unnecessary than who believe it should be there, since a large number of people use Exchange in the workplace.  Telling us that we're not only wrong, but deluded, only succeeds in making us angry.
I don't that pine is a good example for.
1. Pine is only known to geeks
2. the bulk of the poeple don't even use a mail client at all

Exchange is the worst example you can give at all.
Have you even seen microsoft complying a standard?? MS' own standard aren't even compatible to themeselves.

Especially we should NOT learn from Microsoft!
(Almost) no big OSS project encourages Microsoft.

I'm not using Microsoft as an example of what we should follow.  What I AM saying is that many people who use Microsoft products WANT to have the same features when they use OTHER products.  I happen to be one of them, in this particular instance.

The long and short of it is that you continue to tell us that you know better than we do.  Meanwhile, we're not trying to tell you that you HAVE to do ANYTHING, and we're only asking to be able to do as WE want.
IF everyone could do what he wants, world would end up in chaos!

you are free to write an extension for TB.

I made some RFEs, none of them have been even assigned. What shall I do.
I will learn how to write extensions to do my own solutions for.
Perhaps I'm ignorant in this situation, but how exactly would I write an extension to countermand something that is completely hardcoded into the executable?

There are variables stored in a prefs.js file for every single option.  Why not for this as well?
Guys, this is a bug report, not a news group. :)

Apparently no one wants a change enough to make it.

Extension?

As a quick thought, an extension would come awake at onLoad from the compose window and then tweak the innerHTML of the message body and/or sub-elements. No biggy. I'll do it for $1000 USD. Takers, anyone? :)

Seems like the only hassle would be the learning curve to get your first extension rolling. Bunch of magic incantations. Here's probably where to start:

http://developer.mozilla.org/en/docs/Extensions

I imagine it might be possible to add this feature as an option to the existing "Signature Switch" extension (https://addons.mozilla.org/firefox/611/).
(In reply to comment #48)
> This is the same stuff like ppl reply with their reply ABOVE the question which
> really **** me off.

Are you aware that there are many top-100 companies that REQUIRE that the reply be done at the top? The last large organization that I worked for required that the reply be first AND that the FULL email being replied to be quoted inline (not as an attachment) and that quote had to include all signature lines. Sometimes the quoted material was 20 or more previous emails.

You may not like MS (neither do I), but they own the corporate world. If TB ever wants to make inroads into corporate environments, they have to learn to play in the MS world.


OK, just suppose, for the sake of discussion (!), that Thunderbird (either natively or via an extension) were to support turning off the signature separator -- in which case the signature would presumably be delimited only by a completely empty line.

IF this were to be done, how would code that changes signatures (e.g., if the user changes the "From:" to point to a different account with a different default signature) know how to remove an old signature before adding a new signature?

The problem I see here is that if there had previously been NO signature, a routine to CHANGE the signature -- using an empty line as a separator -- would end up deleting the last paragraph of message text, on the mistaken assumption that it was the old signature.

One compromise, I suppose, might be to use a line containing exactly ONE BLANK, and nothing else, as the alternate signature separator.  I'm not enthusiastic about the idea of creating yet another convention that isn't currently used by anyone (as far as I know), but I'm not sure what the alternative would be.

Any thoughts on this (other than blanket rejection, out of hand, of the whole concept of doing anything to the current signature separator at all)?
> IF this were to be done, how would code that changes signatures (e.g.,
> if the user changes the "From:" to point to a different account with
> a different default signature) know how to remove an old signature
> before adding a new signature?

Rich, in answer to your question:

I have hacked thunderbird.exe using a hex editor, so that it doesn't load an email with "-- " in it.  Changing email accounts (and thus, changing to a new sig) works perfectly fine.
(In reply to comment #61)
> OK, just suppose, for the sake of discussion (!)

Well, I've seen this "discussion" (<sarcastic comment snipped>) for over a decade now, and the "arguments" pretty much don't change...

> use a line containing exactly ONE BLANK,
> and nothing else, as the alternate signature separator.  I'm not enthusiastic
> about the idea of creating yet another convention that isn't currently used by
> anyone (as far as I know), but I'm not sure what the alternative would be.

And it won't help anyway, someone would be crying "but XYZ doesn't do this!!!11" nonetheless.

> Any thoughts on this (other than blanket rejection, out of hand, of the whole
> concept of doing anything to the current signature separator at all)?

My mention of templates was dead serious. 
If our template system would allow for replaceable tokens, this "discussion" would be just futile. You'd just write a template 

$caret$
On $day$, $author$ wrote:
$quoted_body$
$footer:path/to/local/file$

Choose this template to be used for all your replies and let the system fill in the variables...

What Andrew and others are looking for is a kind of "footer" - calling it "sig", which already has a special meaning for mails/postings, doesn't help much...

Another way to allow people who prefer (or are required) not to have the signature separator might be to write an extension which would hook into Thunderbird's "send message" action and edit out the line in question from the message text before sending the e-mail.  This would allow Thunderbird's existing signature code, as well as extensions like Signature Switch, to be used unchanged; the message would appear to have the "-- " line all through the composition process, but the line would be taken out (and a single empty line inserted before the signature if necessary) as the message was sent.  People who want to keep the separator wouldn't need to install the extension.
Will an extension also be able to stop the removal of any sigs with the "-- " when replying?
(In reply to comment #62)

> I have hacked thunderbird.exe using a hex editor, so that it doesn't load an
> email with "-- " in it.  Changing email accounts (and thus, changing to a new
> sig) works perfectly fine.

Andrew - would you be willing to share your hack? Of course, anyone who uses it would do it at their own risk ...


If you go get a hex editor (such as, in Windows, the Free Hex Editor, frhed) and open the file thunderbird.exe, then do a search for the string "-- ", after a couple tries you'll get the section that prints it in the signature.  You can tell that it's there because there's something just before it that says something like "moz-signature".  You'll want to delete that string (change it all to zeroes, if you're editing the hex side of the file) as well as the <BR> that comes either right before it or right after it, I can't remember which.

After a bit of trial and error, you'll get the hang of it.

I was partially incorrect, by the way, with my comment about changing the sig.  It turns out that if you start typing an email and THEN decide to change the account/sig (something that I rarely do), it will delete the whole message and replace it with the other sig, which will not happen if the sig delimiter is in place.
Well add me to the LONG list of people who want the option to get rid of this stupid delimeter.

The arguments against it seem to surround having the email client be able to strip  a sig from replies.  And they seem to also have a problem with TOP REPLY.

I for one prefer TOP REPLY as well.  I work in a professional office and I've NEVER ONCE seen a reply placed at the bottom.  All replies are basically in REVERSE CHRONOLOGICAL order.  The user shouldn't have to scroll through a bunch of stuff that's already been read in previous messages just to get to the current reply.  That's why I prefer TOP REPLY.  If someone is added to the message thread three or for messages in, they can scroll to the bottom and catch up.

And in addition, we don't remove signatures from previous replies.  We want everyone in the message thread to be able to identify who said what leaving the signatures there allow this.

There seems to be a large contingent of people who prefer BOTTOM REPLY and stripping signatures and I'm not going to try and convince them that my way is right.  I can respect that they've got their reasons for doing things that way.  But I'd appreciate the same level of respect.

I just want to get rid of this delimiter without having to use a hex editor to edit the executable (possibly corrupting it).  And what happens when I install a new version--edit the executable again?
Maybe this is not about people not understanding the standard, but about a
standard that isn't really a standard. I've looked at some 100 incoming mails
of the last year, and there are really very few email clients that bother with
the '-- ' prefix to the signature. Most people like to have a signature like:

Kind regards,
Marc
=============
Marc Richards
Director of Marketing
Adventron Inc.
www.adventron.com

Any prefix or prohibitive 'standard' is perceived as annoying and inconvenient. I presume that's why Lotus Notes, MS Outlook and most other clients don't include it.

You can define a bug in two ways:
1. Something that doesn't work as the programmers intended
2. A feature that's inconvenient and annoying.
This is a bug of type 2. Can it be put on the priority list, please?
Assignee: ducarroz → nobody
Status: ASSIGNED → NEW
Priority: P3 → --
QA Contact: esther → composition
Target Milestone: Future → ---
I agree that there should be an option of removing the sig separator. I've been using Internet for 8 years on a daily basis and I don't remember ever having seen a "-- " type separator anywhere. Now I've checked my incoming mail in TB and I couldn't find an e-mail with a "standard" sig sep. What are we talking about then? It's just an old custom (not standard) that very few people follow these days. Outlook and Outlook Express don't recognize it, Gmail and Yahoo don't recognize it. The majority of e-mail users are already out. It makes no sense to force it down people's throats. If it were included as an option, enthusiast could still continue using it, and that's it.

BTW, I also resorted to the HEX editor solution and removed it from thunderbird.exe. Only way to be spared a lot of pain.
In general, I would rather not use the "-- " sig separator, and I definitely resent being FORCED to use it.

I can see one possible advantage to keeping the "-- " separator, at least during message composition.  If I want to change the signature automatically (e.g., via the default signature setting for an account, or the "Signature Switch" extension), there needs to be some reasonable way for software to identify where the signature starts, and "-- " functions well in this regard.  However, I would like to be able to set an option (or use an extension) that would find the separator and remove it just before sending my message.

If some people really want to use the "-- " separator, I certainly won't complain, but trying to force TB users to use it -- in hopes of converting the entire Internet community -- is a losing battle that we shouldn't be trying to fight.
Folks, 
a sig is "defined" (by common usage) as a piece of text delimited by "the" sig delimiter, and this sig delimiter is "-- \n" and that won't change.
What you guys want is a customizable _footer_, with arbitrary text - this is a perfectly valid RFE, but it has nothing to do with our current sig handling.

Calling a tree "house" and then complaining to the carpenter that it has no walls isn't very helpful...
WHERE? People keep claiming that it is defined, but there are NO RFC (or equal) that so defines a sig line for email. You can't force people to use a sig line by hard-coding it then turn around and claim "common usage". The only major email client that currently use this "sig delimiter" is T-bird. Yet, as much as we want it, T-bird usage is still a minor player compared to Outlook.
This is like saying: "It's ok for me to steal your stuff because it's common for me to steal and it's been a 'standard' for me to steal because I have been stealing for a very long time."
There's no need to shout, and it won't make your case "more right" anyway.

While Son-of-1036 never became a "real" RfC, wide parts of it have been a de-facto-standard ever since. And even Son-of-1036 does not create the sig delimiter from thin air, but says it's already a "well-understood convention" at that time (1994)!

Just because MS doesn't give a bit about conventions let alone standards doesn't make it go away.

Mind, I don't reject having a footer feature, I just think it'd be part of a more general template mechanism, as outlined in my comment #63...
"a sig is "defined" (by common usage) as a piece of text delimited by "the" sig
delimiter"

No--my signature is MY NAME.  Some people insist that the signature should be separated from the "message" by this delimiter.  I as the person sending the message should have the OPTION to NOT use this delimiter.

In 10 years of internet & email usage, I've NEVER encountered this delimiter.  That is until I started using TBird.  And I have NOT been an exclusive M$ user either.  Outlook, OE, Eudora, YahooMail, Mail.com etc.  ALL are email clients/services that I've used in the past.

And Tony Thigpen's analogy is right on target. 
Karsten, you said in #73 that the sig delimiter is defined by common usage, but I would vehemently argue against that.  Thunderbird is the only major email client that uses this convention, regardless of what others might recognize the usage of the convention.

Personally, guys, I've given up on this quest.  Obviously the developers are more concerned with forcing outdated conventions from plain-text days on the user than they are with the spirit of Mozilla and its family, which is to allow the user to modify anything they want.  What could have been an easy change from hardcoding to a configuration option (it didn't even have to be in the options! it could just have been something you had to open about:config to do) has turned into an almost-decade long battle.

It's never going to happen.  I think we should just resign ourselves to it.
(In reply to comment #72)

> I can see one possible advantage to keeping the "-- " separator, at least
> during message composition.  If I want to change the signature automatically
> (e.g., via the default signature setting for an account, or the "Signature
> Switch" extension), there needs to be some reasonable way for software to
> identify where the signature starts

Since TB put the original signature there in the first place, it should be able to remove it too. That must be reasonably easy to program. Then TB can replace the signature in the cases you mentioned.

Karsten, I think anyone who wants to can be "more Catholic than the Pope" in adhering to what they perceive as standards or to "long-standing conventions in Usenet news which also commonly appear in Internet mail". But forcing the entire TB user base to participate in this is a wholly different matter.
First, an update:  RFC 3676 replaced RFC 2646 four years ago.  

Then a clarification:  Both RFCs address signatures only for NNTP (newsgroup) messages.  Neither RFC addresses signatures for E-mail.  

Finally, a problem:  If you digitally sign a message using OpenPGP (e.g., with PGP, Enigmail) and the message ends with a text signature within the scope of the message being digitally signed, the OpenPGP RFC 4880 requires the dash-dash-space text signature delimiter be changed to dash-space-dash-dash-space.  That's because the OpenPGP RFC 4880 (section 7.1) requires any line beginning with a dash have dash-space prefixed to it.  This allows strings of dashes to be used to delimit the OpenPGP message header, signature header, and message tail (technically, armor headers and tail).  

All this means that the dash-dash-space of a text signature is corrupted by applying an OpenPGP signature.  RFCs 3676 and 4880 conflict with each other.  This conflict existed in predecessor RFCs, with the predecessor OpenPGP RFC 2440 being published before the text signature predecessor RFC 2646.  

The discussion in this bug report seems to revolve around standards.  While
there are RFCs addressing the "-- " (dash-dash-space) delimiter for NNTP
(newsgroup) messages, no RFC addresses this for E-mail messages.  Thus, making
the delimiter optional for E-mail messages would not violate any standard.  

Contrary to prior comments, there is no such thing as a "de-facto standard". 
All standards are formally documented after a consensus is reached by both
developers and users.  Standards do not result from the decree of a single
developer or from some user asserting that it is "common sense".  

The closest thing to a "de-facto standard" would be a convention, for which a
lack of compliance is not considered an error.  Defaulting to a convention with
an option not to use the convention does not affect compliance with standards.  

I urge those interested in this discussion to read the Description of bug
425963, which was Resolved as a Duplicate of this bug.  
David,
This has caused me more grief than the developer seem to understand since 2004 when I first posted on this bug report. The bug report has been open since 2000 and although T'bird has come a long way, this has never been addressed. All I can take from that is that the developers consider their opinion gospel and will not change it. All we have asked for during the many years was a option to turn it off. We never even asked that the default be 'off'. Somebody likes playing god over everybody else in this matter and until that somebody either leaves the T'bird development or dies, I don't expect this to change.
Bryan, re: comment 60 - you have an enterprise wiki, meta, tickler or flag?

Plunging into the abyss with  => wanted-thunderbird3?

I'm not going to pretend I read all this or understand all the nuances, but at the very least, seems to me we should seeking a solution or set of solutions, rather than arriving at an intractable "No" this won't be done. Additionally, 
do we need to hear from more of those who are negatively impacted? Or is sufficient to list all the ways this impacts usage (I don't see such a list)


(In reply to comment #63)
> (In reply to comment #61)
> > OK, just suppose, for the sake of discussion (!)
> 
> Well, I've seen this "discussion" (<sarcastic comment snipped>) for over a
> decade now, and the "arguments" pretty much don't change...

that seems to be true for "both sides"
Flags: wanted-thunderbird3?
A list of reasons why an option for the signature delimiter would be appropriate for E-mail:  

1.  There is no standard or RFC specifying such a delimiter for E-mail.  The only RFC -- RFC 3676 -- addressing the delimiter is for NNTP messages and not for E-mail.  

2.  The "-- " delimiter becomes useless when E-mail is digitally signed per the OpenPGP RFC 4480.  This is a result of a specification in that RFC that traces back to RFC 2440, which is older than (and thus has priority over) the original documentation for the delimiter in RFC 2646 (ancestor of RFC 3676).  

3.  There are indeed E-mail applications (e.g., AOL) that do not use the delimiter.  Any purpose served by the delimiter is thus limited.  

4.  There are users whose text signatures contain caveats that they definitely do not want removed.  Admittedly, confidentiality notices are of little value in messages that are not encrypted; however, this does not eliminate the insistence of users that such notices not be stripped from messages.  

5.  At least one potential commercial deployment of Thunderbird within a company is at risk because there is no option to suppress the delimiter in E-mail.  See the <news://news.mozilla.org:119/mozilla.support.thunderbird> thread with
the subject "Signatures and "Double Dashes".  

Note that the above list supports an option for E-mail without saying there should be such an option for NNTP messages.  


I don't think think we need a list here (though most of the listed ones are more or less moot imo). 

What we do know is that some users do not want to use it (for whatever reasons). The summary per say doesn't make sense, there is no choice of "what" the delimiter is if there is one. I'm not personally opposed to making it optional though, perhaps just a hidden pref, or recommend using it in the UI similar to bottom posting.
Ok, I've spent a bit of time trying to organize thoughts on this, however this and many others like it are very long bugs so please let me know if I missed something.

The double dash isn't a standard and I do believe people should have the choice of using something else because of that.  However using the double dash seems like something we can at least encourage since it may become a standard in the future and certainly makes sig processing easier.

So my plan requires a couple pieces to come together, but goes like this.

1) We need a signature editor which saves signatures (something like attachment 237618 [details] [diff] [review] in bug 324495)
2) We create a default signature for every account, built from the person's name and organization (maybe more?)
3) This default signature also contains the double dash at the top as specified in RFC 3676 but not implemented in the code.

This set of steps makes the double dash part of the default signature and present in the signature editor and therefore can be removed by people not wanting to conform to what may become a standard.  By making this a default we're promoting the standard system, but also allowing people the freedom and flexibility to divert.

I think this is a pretty fair compromise on the RFC and a good system for our users at the same time.

Here's the wiki page with my design plan for message signatures for MN/TB.
http://wiki.mozilla.org/Thunderbird:Message_Signatures
I really think you are complicating the whole thing. All the issues (in this bug) can be handled with one simple flag:
RFC_3676={NO|YES}
   NO - '-- ' is not inserted into email prior to the signature and no striping of lines following a '-- ' is performed when replying to an email.
   YES - '-- ' is inserted into the email prior to the signature. When '-- ' is found when quoting an email, the '-- ' line and all lines following are removed. This is the default.

The problem for me is that your proposal does not address the problem of the signature being stripped out when replying to an email. In a corporate environment, the signature is important to document who said what. The "From:" included in the quote only says who sent it, not who wrote it. These fields can be different because in the corporate world, the executive assistants (secretaries) respond to email for their boss.

I was unable to get a corporation to even consider deploying T-bird (30,000+ seats) due to the removal of the sig information.
Another issue to consider here has to do with extensions (such as "Signature Switch") which allow the user to choose or change the signature on a message being composed.  If there isn't a specific, known text value being used as a signature separator, a signature extension wouldn't be able to identify the existing signature in the message being composed in order to replace it reliably with something else.

I mentioned this issue previously (see my earlier comments on this bug), but I wanted to bring it up again so that my earlier comments wouldn't be forgotten.

I brought up this problem some time ago with the author of the "Signature Switch" extension, but he turned out to be a strong proponent of viewing the "two dashes and a space" string as an Internet standard and refused to have anything at all to do with any change along the lines I was proposing.

I agree, though, that an option does need to be added to Thunderbird to allow users to turn off the separator, even if this does break Signature Switch.
Rich: I actually don't think it's as difficult as you might think to do what you propse with Signature Switch or other similar extensions.  When I was looking through the thunderbird.exe binary to remove the sig dashes (if you're not sure what I'm referring to, see comment #31), I found that the signature appears to be wrapped in a div tag called "mozilla-signature".  I can't be certain of this, because I don't believe it's possible to look at the source of a message prior to sending it, but I don't see why it wouldn't be possible to rewrite an extension to look for this, rather than the sig dashes.
Does this wrapping of the signature happen even when mail is being composed as plain text (not HTML)?
Regardless of the div-tag-wrapping question, it simply must be the case that an application can remove what it itself has inserted.

Thunderbird, or any signature extension, should simply remember where it inserted what. Or it can do a search for the full text of the signature, rather than for '-- '. This will also end the annoying fact that when changing signature, a quoted email that comes under your signature gets deleted. 

It will be more neat and more exact.
> Does this wrapping of the signature happen even when mail is being
> composed as plain text (not HTML)?

I BELIEVE so.  There's only one location in the executable file where the
signature is located, so I believe that the convention is the same regardless. 
After all, the email composer in TB is the same whether you're writing in HTML
or plaintext.  As I said before, I can't be sure one way or the other on this.

Regardless, I don't see why it can't be possible to do something similar to
what Outlook does in this sense (Outlook sets a "bookmark" at the location of
the signature in Wordmail's composer, which is essentially the same as a meta
tag that could be put into TB).

Not being a programmer, I really don't have the knowledge to be able to make
definitive statements on this, though.

BvdG has a point as well: the program should simply be able to remember where it inserts certain text.
I had almost forgot about the quotes disapearing on reply. The site with the 30,000 seats also required that replies go at the top of the email and quotes in backwards order. The sig processing in T-bird would jsometimes delete the quotes after any new sig. I no longer work for that company, but T-bird lost the chance at 30,000+ seats over just these three little characters.
(In reply to comment #86)
> The double dash isn't a standard

It is, and has been forever, see comment #75. (Just not one everyone uses.)

> So my plan requires a couple pieces to come together, but goes like this.

> 3) This default signature also contains the double dash at the top as specified
> in RFC 3676 but not implemented in the code.

I expect saving the delimiter in the signature file is problematic. For top postings it shouldn't be (isn't) inserted at all. That, and a lot of people would inadvertently make it not a real signature. It's "-- "linebreak and nothing else. 

That doesn't necessarily rule out having the "-- " in the editor text of course. Could perhaps also be some kind of marker above, possibly right-clickable + warning to turn it off.

----
Re comment #93 on missing out on large corporations: anyone making decisions based on a thing like this is perfectly capable of coming up with another million other reasons too not to choose moz mail. For companies of that size it's pocket money paying someone to implement this for them if it they really seriously wanted it. They'd probably even have someone in house that could do it for them.
Re comment 94 about my comment 93.
30,000 seats does not mean large PC programming staff. The IT programmers staff was busy doing programming on their business systems that were located on a mainframe. They were using COBOL and RPG. They were not staffed for PC programming.
Are you suggesting that if the programming for the sig line had been done by someone, it would have been included with future versions of T-Bird? That is not the feeling I get when I read this thread.
Re comment #94:  

I will repeat:  ALL standards are formally documented as such.  Further, they reach standard status only after consensus from both users and developers.  

Even conventions are formally documented, although they might not have the consensus necessary for standards.  

If, as you assert, there is a standard for "-- " to delimit E-mail text signatures, please provide a reference to the documentation.  RFC 3676 is NOT the appropriate documentation because that RFC (1) describes "-- " as a convention, not a standard, and (2) addresses NNTP messages (including in its title "Usenet Signature Convention").  

-1
It seems the only reason for this RFE are from people trying to put ‘Yours Sincerely’ in a signature and wondering why it doesn’t work to their impressions…
It has been an e–mail pattern for over a decade and no amount of NNTP RFC waving should claim that a common convention (de facto whether OE uses it or not) isn’t worth it.

If people believe it’s really needed, comment #86 would be the way to go imo.
Just wondering...
What email clients, other than Mozilla based, enforce the use of '-- '?
(In reply to comment #94)
> That doesn't necessarily rule out having the "-- " in the editor text of
> course. Could perhaps also be some kind of marker above, possibly
> right-clickable + warning to turn it off.

Lets try to give this "--[space]" a try as the default delimiter inserted at the top of generated signatures.  Like you wrote, there should be a way of creating a marker or something for this delimiter inside the compose window.  With the proper delimiter offered by default I think we're doing the right thing and giving people the freedom necessary.
(In reply to comment #97)
> It seems the only reason for this RFE are from people trying to put ‘Yours
> Sincerely’ in a signature and wondering why it doesn’t work to their
> impressions…

Right, how dare people expect Thunderbird to be convenient and easy to use! Those lazy bastards should learn to type "Yours sincerely" by hand every single time.

Please try to understand that an email application and its system of standards and defaults exists for the benefit of the users. The users don't exist for the sake of maintaining some silly arbitrary "standards".
I just registered, merely to leave this comment here. In my opinion Rich Wales pointed out the most important aspect earlier on:

(In reply to comment #72)
> In general, I would rather not use the "-- " sig separator, and I definitely
> resent being FORCED to use it.

Users shouldn't be forced into what the developer thinks is right. 
but why not simply give them the option to select if they want a sig separator, and what they want it to be...
There seems to be two main arguments for keeping the "--" signature separator:

1) When mails are received with a "--" separator and I reply, my mail client is able to extract the signature from the response.

2) If I start writing an email with a given signature, then decide to change the signature or account, Thunderbird is able to maintain the message body and replace just the signature.

In response to these two arguments:

1) Although historical standards may dictate that "--" should be used to separate signatures and that replies should follow the original message, it seems that very few mail clients adhere to this behavior these days. I certainly do not recall recently receiving any mail adhering to either of these conventions. I see the inability to disable this separator as something that would potentially reduce the adoption of what would otherwise be a fantastic email client (especially once os x address book integration comes in v3). It's certainly one factor that is causing me to hold off installing Thunderbird.

2) There are smarter ways to replace the signature portion of a partially completed message when changing the "from" account or active signature. For example, when a signature needs to change, the application could scan the partially complete message for an exact match of the previous signature and remove this, replacing with the new signature. If the user has selected the option to add replies at the top of the message when replying, then the process would search for the first occurrence of the signature from the top, otherwise it would search from the bottom of the message up. Of course, if the user has modified the signature within the message this would not work, but then again if the user has manually removed the "--", the current method won't work either.

This seems to be a great product, however I feel end users would feel a little more comforted knowing that their needs and requirements are being taken to heart by the developers. The fact that this simple request has been in discussion for nearly ten years does not convey this.
Product: Core → MailNews Core
I just want to put an extra line break before it. Please don't argue me against that. Can anyone direct me as to how I might be able to achieve that goal (without hacking the binary)?
Thanks to "bkennelly" for pointing out how I could place a line break before the signature separator:

"Include the blank lines at the beginning your your signature file, followed by the separator "-- " (be sure to include the space). Thunderbird will recognise the separator, and not add another."

from: http://forums.mozillazine.org/viewtopic.php?f=39&t=859865&p=4515585

***Additionally, I have determined the obvious next step (solution to this discussion). You can hide or change the *apparent* signature separator by adding the following to the top of your *HTML* signature file (the <br> is only necessary if you want the extra line, like me):


<br><span style="display:none;">
-- 
</span>
It seems adding the separator "-- " (with a space) doesn't prevent TB from adding it's own duplicate separator.  Pretty annoying.  I'm not sure why the separator has to be part of TB and not just left for the user to configure in their sig file.
A simple option defaulted to keep the current behavior in the prefs would be great. I do not communicate with anybody that follows the bottom-post/"-- " behavior. So, why must I be forced into a a behavior that runs counter to the current trend of email clients. Most of  my emailing is done at work (where most e-mailing takes place over all) and top-post saves me time. The signature is completely aesthetic, but is the next move going to be that I am forced to format my mail to to certain way because somebody I never e-mail says it is the best way?

One other thing, if we do not us "-- " in top-post reply, then we have broken the "standard" already. I think it is reasonable to allow the user to decide if they follow this etiquette or not.
I can't believe the TB developers haven't taken care of this.  Providing an option to turn off the "standard" separator should be a very simple thing to do, and it's clearly something that a number of users want.  Do the developers really want the reputation of ignoring the desires of users?

If the developers feel strongly that the "-- " separator should be there, then it's reasonable for them to make that the DEFAULT.  But to REQUIRE it to be there isn't reasonable.
ditto the option to turn on/off
Adding my little voice of assent to the cries for an option.

(In reply to comment #108)
> Do the developers really want the reputation of ignoring the
> desires of users?
Harry, I do not think the *developers* in the discussion are in fact ignoring anyone. I could be wrong (I've only been following T-bird bugs for a year or so now, so I'm not too familiar with the old-school developers from the time this bug was opened), but it looks like most of the opposition to adding an option actually comes not from developers, but from advanced users that like standards.
Even "standards" that aren't.

There seem to be three main questions left to answer before this bug (RFE) can be fixed:
1. Is this important enough? I submit that it is of some importance, and although it is true that most users probably don't notice this, the number of duplicate bugs filed and comments left is a good clue as to its popularity; OTOH, hardly anyone would mind if the option was added (off-hand guess: 17 people would mind, and 16 of them are CC'ed to this bug ;-).)
2. What design should be chosen? The very nice generalized solution clarkbw put forward, or the simpler toggle switch that Tony prefers?
3. Who has time to work on this?
If I was familiar with the TB codebase (and C++; yeah, that'd be useful too), I might be able to, but unfortunately I am not.

P.S. I find it ludicrous that the only current work-around (apparently) involves hex-editing the TB binary.
9 years later... Is this option a bigger problem than I'm imagining?
This bug is really annoying if you want to add the "Yours sincerely, [name]" lines (and nothing else) automatically below all your mails. Of course I do NOT want them to be separated. While I can place a signature separator at the end of my sig file to avoid the separator being placed in front of the above lines, I still will have an unnecessary separator (i.e. an empty signature) at the end of the mail. Unless there is another easy way to achieve this, I would suggest a hidden pref so normal users won't change it, but users who know what they are doing can change this behavior without any hassle. This can't be more than 2 lines of code, can it? Instead of "insert separator" putting "if !pref('noseparator)) insert separator"...

(I am only talking about inserting the signature separator - the remaining signature functions like automatic removal in quotations should still work using the original "-- " separator.)
Ugh this is absolutely typical of opensource development - 9 years of pointless arguing and no action. 

There are lots of perfectly valid reasons why we may not want to have the -- separator. If you're concerned about breaking some "standard", just make it a hidden config option - ie, one which cannot be changed via the GUI. I shouldn't have to start hacking code to do something so basic!
Doing something non-standard results in **** like Microsoft does. Mails sent from Outlook are horribly broken. One is not able to quote then reasonably.
Yes but there's a big difference between breaking the standard by default, and allowing users to break the standard if they so choose.
And if they choose to do so I am actually punished with since I have to cut the sig myself when I reply such an email. Why should I? Sometimes simply stop replying because this is just a waste of _my_ time correcting their mistakes.
Sometimes I wish opensource geeks would just stop and listen to themselves for a minute.
please observe proper protocol in bug comments. These comments are contributing nothing toward gaining a solution
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

better, would be to draft a solution for review
The solution is to add a hidden config option which can only be changed by manually editing a config file. Thus only someone who knows what they're doing can break the standard.
I'm sick and tired of this.  Everyone, please STOP calling this "the standard" for e-mail -- RIGHT NOW!!! -- unless you can cite an official Internet standards document (STD or RFC) that explicitly backs you up.

Section 4.3 of RFC 3676 (http://www.faqs.org/rfcs/rfc3676.html) says:

    There is a long-standing convention in Usenet news which also
    commonly appears in Internet mail of using "-- " as the separator
    line between the body and the signature of a message.

But this is NOT the same as claiming (as some are doing here) that this particular separator is MANDATED in e-mail and is REQUIRED for Internet standards compliance.

It's perfectly OK for Thunderbird to encourage the use of "-- " as a signature separator in e-mail by making it a default.  It is NOT, however, OK for Thunderbird to FORCE the use of this separator, or for us to brush aside nine years' worth of requests for this separator to be made optional via a spurious claim that it's supposedly mandated by a standards requirement that does not in fact apply to e-mail.

This comment is not intended as a personal attack on anyone who has honestly been defending the "-- " signature separator in the sincerely held belief that it is an Internet standards issue.  I am simply trying to clear the air regarding this claim (which I believe to be inaccurate) and get people to return to the question of how to make this feature optional (as I believe it needs to be).

I will be more than happy to withdraw my comments and join the "signature separator should be mandatory" camp if and when someone can cite a current, official Internet standard which says that "-- " MUST be used as a signature separator in all standards-compliant electronic mail.
You could make the argument that the double-dash separator is a *de-facto* standard because many MUAs support it. Doing so actually puts your position closer to Microsoft's - Microsoft have always placed more emphasis on de-facto standards than de-jure standards (ie RFCs and STDs).
(In reply to comment #114)
> Doing something non-standard results in **** like Microsoft does.

Allow me to expand that statement for you. I just checked, and neither Gmail nor iPhone Mail put the "-- \n" in front of the signature. Thus, it should be:

> Doing something non-standard results in **** like Microsoft, Google and Apple do.

I agree with #120: it's time to stop calling this request 'something non-standard'. Calling something that the three largest IT companies do 'non-standard' reminds me of that joke about the car driver who heard a warning on the radio that there was someone on the wrong side of the highway, and exclaimed: "Someone? There are thousands!"
So basically the conclusion is that '--' is not a standard of any kind and none of the other major players implement it. Come on guys, please can we have a way to disable this? Should be a no-brainer.
(In reply to comment #122)
> (In reply to comment #114)
> > Doing something non-standard results in **** like Microsoft does.
> 
> Allow me to expand that statement for you. I just checked, and neither Gmail
> nor iPhone Mail put the "-- \n" in front of the signature. Thus, it should be:
> 
> > Doing something non-standard results in **** like Microsoft, Google and Apple do.
> 
> I agree with #120: it's time to stop calling this request 'something
> non-standard'. Calling something that the three largest IT companies do
> 'non-standard' reminds me of that joke about the car driver who heard a warning
> on the radio that there was someone on the wrong side of the highway, and
> exclaimed: "Someone? There are thousands!"

Who ever said that a big company does all things right? Most don't. I've rarely seen microsoft implemenenting someting reasonable except Kerberos or other RFC stuff.

Besides, Apple is a niche player with highly proprietary stuff using open source parts.
The point is; there is no official standard mandating the use of "-- \n" as a signature separator, and none of the other players are doing it. Why should Thunderbird be the only MUA to force this feature on its users?
Simply because stripping the signature is good point since it is *not* part of the conversation itself. It is annoying background noise. More over some people even abuse it though and attach a 8 line signature. Are you willing to strip it manually? It's about common handiness.
But, again, there is a big difference between promoting this separator as a default vs. FORCING it on people.  All people are asking for here is that it should be made optional.
If you feel that strongly, submit an amendment to the RFCs and get it codified as a standard. Don't just force your personal preferences on everyone who uses Thunderbird - that's as bad as Microsoft!
Call to order, guys!
Bugzilla is NOT a discussion forum!
Please only post here if you have something _new_ to tell.
(And also see my comments #63 and #75, if you like.)
(In reply to comment #129)
> Bugzilla is NOT a discussion forum!

No, it's not, but the reason this has turned into a discussion is because no conclusion has been reached. No new information is going to be presented because there is no new information to present, it's all opinion. Someone with the authority to do so needs to make a decision about how to proceed and close this bug. 

In my opinion the answer is clear - the signature separator is not required by any standard, it is not even implemented by many MUAs. The only logical conclusion to draw from this is that forcing it upon users is incorrect behaviour and should be fixed.
A certain amount of "discussion" is really inevitable here, since there is a serious disagreement about whether or not the requested change ought to be made or not.

I'll stick to my earlier comments -- namely, that I'm fine with having a double-dash signature separator as a default option, but (as far as I'm aware) this separator is NOT any sort of mandated Internet e-mail standard, and unless someone can demonstrate that it IS a mandatory standard, it's wrong for us to force it on Thunderbird users, and it's our responsibility to provide a reasonable way for users to turn it off if they wish.
(In reply to comment #131)
> unless
> someone can demonstrate that it IS a mandatory standard, it's wrong for us to
> force it on Thunderbird users, and it's our responsibility to provide a
> reasonable way for users to turn it off if they wish.

Can we agree on this as a course of action then? Let's allow a reasonable amount of time for anyone interested to search the RFCs, and if no mandatory requirement can be found; some method of disabling the separator should be added.
I too would like this feature to be added, but Karsten is right: Bugzilla is not designed or intended for long discussions about _whether_ to fix a given bug/RFE -- only about _how_ the fix should play out. I believe the arguments pro and con have been thoroughly made, and until someone decides to take up actual work on the RFE, no further progress can be made.

(In reply to comment #132)
> Can we agree on this as a course of action then? Let's allow a reasonable
> amount of time for anyone interested to search the RFCs, and if no mandatory
> requirement can be found; some method of disabling the separator should be
> added.
Unfortunately, this isn't how development works (open-source or not, actually): the developers are *always* perfectly free to decide which bugs and feature enhancements they will work on, although this is (in every case, open-source and otherwise) influenced more or less by customer demand.
While there is certainly customer demand here, it appears that the official Thunderbird developers take a largely neutral or even somewhat opposed stance toward this RFE, partly for technical reasons -- and polemics on why this RFE would be so cool to fix are not going to change that. Only a careful and detailed technical explanation of how to resolve all the issues raised will do anything. (See also Comment #86 for an example of what I mean -- ironically, by one of Thunderbird's main UI engineers.)
As a side note, I am personally a developer (although I have never touched the Mozilla codebase) and I would not be particularly thrilled at the thought of tackling this particular bug, what with all the comments to and fro to wade through. That is: polemics probably actually *discourage* any eligible developers from deciding to take this on.

Finally, this discussion should definitely be taken to a more suitable forum, if there are in fact any more things to say (besides the "detailed technical explanation", of course). I suggest http://forums.mozillazine.org/viewforum.php?f=30 as a possible spot, or perhaps mozilla.dev.apps.thunderbird.

Please don't argue any more on this bug's comments about whether it's valid or not.
Ugh screw it, I'll do it myself.
If you can implement it as an add-on, then people will *really* be free to decide if they want the option or want nothing to do with it.
I'm afraid I haven't got time to do that, it's going to be a dirty hack in the probably in form of a commented-out line and a patch to the source. I'll post the patch here when I'm done.
There you go guys, I just commented out the lines that add the offending double-dash and their linebreaks. All it would take to turn this into an actual fix would be to add a conditional check on a config file instead of just commenting the lines out. It's a 10 second job.

> Unfortunately, this isn't how development works (open-source or not, actually)

Please don't tell me how development works, I'm an experienced software developer and I know how it works. You can't seriously be suggesting that taking 9 years to reach a decision is the correct way of doing things?
(In reply to comment #138)
> All it would take to turn this into an actual
> fix would be to add a conditional check on a config file instead of just
> commenting the lines out. It's a 10 second job.

It's a 10 second job for someone who already has a build environment set up and knows how to get prefs, but a 10 hour job for someone who doesn't. I think the code for getting boolean prefs is:

PRBool doNotAddSigSeparator = PR_FALSE;
if (prefBranch)
  prefBranch->GetBoolPref("mail.suppress_signature_separator", &doNotAddSigSeparator);


       if (!(firstFourChars.EqualsLiteral("-- \n") ||
             firstFourChars.EqualsLiteral("-- \r") ||
             doNotAddSigSeparator))


Would you (or anyone) mind turning that into a (working) patch that sticks to Mozilla's rules (https://developer.mozilla.org/en/Creating_a_patch), test it and submit it?
Sure I'll give it a go
Here's my patch to add the suppress_signature_separator config option. I've added it to the identity part of the config tree because looking at the code, that seemed like the most logical place to add it. Obviously it also means you can change the option on a per-account basis. 

I've tested thoroughly and I'm pretty confident I haven't caused any regressions. I don't believe any additional automated tests are required as the change is fairly trivial. 

Looking forward to your feedback.
Attachment #419758 - Attachment is obsolete: true
Forgot to say this - I'd just like to be clear; my patch doesn't change the default behaviour in any way - all it does is add a hidden config option named suppress_signature_separator so that those of us who would rather not have the double dash separator have the freedom to disable it.
thanks a lot in the name of many tb users.
Attached patch Fix a typo in a comment (obsolete) — — Splinter Review 
Spelled suppress wrong in a comment - might as well be correct :)
Attachment #419790 - Attachment is obsolete: true
Comment on attachment 419792 [details] [diff] [review]
Fix a typo in a comment

David, could you review patch?
Attachment #419792 - Flags: review?(bienvenu)
If I'm the David cited in comment #145, I've been away from code too long to start reviewing patches.  

However, I must comment on the design in comment #139.  It's too simplistic.  Because of RFC 3676, the patch must distinguish between E-mail messages and newsgroup messages.  It should apply only to the former; there should be no option for the latter.  

Also, I strongly believe there is no such thing as a de facto standard; there are only de jure standards.  Unlike conventions, standards are officially documented.  This is equally true for the specifications of the threads on the bolts and nuts holding an automobile together, the definition of a second of time in terms of counting subatomic vibrations, the glyphs used in the Unicode character set, and the format of X.501 certificates (the last two being very important for Mozilla products).  Since there is no documented standard for E-mail signature delimiters, I think the patch should also include a user interface (not merely a hidden preference).
(In reply to comment #146)
> If I'm the David cited in comment #145, I've been away from code too long to
> start reviewing patches.  

No, the patch is flagged with a review request for David Bienvenu.
Can someone please tell me (us) how to enable this?  Do I need to download the source code and re-compile?

(In reply to comment #141)
> Created an attachment (id=419790) [details]
> Patch to add config option mail.identity.id?.suppress_signature_separator
> 
> Here's my patch to add the suppress_signature_separator config option. I've
> added it to the identity part of the config tree because looking at the code,
> that seemed like the most logical place to add it. Obviously it also means you
> can change the option on a per-account basis. 
> 
> I've tested thoroughly and I'm pretty confident I haven't caused any
> regressions. I don't believe any additional automated tests are required as the
> change is fairly trivial. 
> 
> Looking forward to your feedback.
(In reply to comment #148)
> Can someone please tell me (us) how to enable this?  Do I need to download the
> source code and re-compile?

Until the patch is approved and merged into the source tree; yes, you will have to download the source yourself, apply the patch and then recompile. 

(In reply to comment #146)
> However, I must comment on the design in comment #139.  It's too simplistic. 
> Because of RFC 3676, the patch must distinguish between E-mail messages and
> newsgroup messages.  It should apply only to the former; there should be no
> option for the latter.  

You are correct, my mistake; I'm just making this change now and will submit an updated patch shortly. 

> Also, I strongly believe there is no such thing as a de facto standard; there
> are only de jure standards.  Unlike conventions, standards are officially
> documented.  

That's an issue of definition - 'de-facto standard' is really just another way of saying 'convention'. I'll think you'll find 'de-facto standard' means exactly that - a convention rather than an officially documented standard. You can still argue that a de-facto standard is not a true standard, and I would agree with you.
(In reply to comment #146)
> Since there is no documented standard for
> E-mail signature delimiters, I think the patch should also include a user
> interface (not merely a hidden preference).

I would tend to agree with you - however, getting agreement to add it as a hidden preference has been enough of a struggle (and enough hard work for me thanks) - I suspect any attempt to get it added as a visible option in the config screen would be met with fierce resistance, and I for one am done arguing over it.

        Attachment #419792 -
        Attachment is obsolete: true

        Attachment #419792 -
        Flags: review?(bienvenu)

    
  

        Attachment #419827 -
        Flags: review?(bienvenu)

    
    

    
  
I've actually just had a read of RFC 3676 and the keywords MUST, SHOULD, REQUIRED and SHALL are never actually applied to the usenet signature separator, so an implementation that allows you to disable it doesn't break this particular standard. 

Oh well, you've now got two versions of the patch - one in which the suppress_signature_separator option applies to all new messages (attachment id 419790), and one in which it does not apply to nntp posts (attachment id 419827). It's now up to the Moz developers to choose which one they prefer.

    
    

    
  
As the setting is a per-identity and a hidden one, I think we should allow it for news too, so the user decides if he wants to use it or not.

In Comment #112, I explained an use case where it would be useful even if it violated some standard (using the sig to automatically insert the greeting line) - in the given example, the resulting mails/posts would be no different than if the user wrote the greeting by hand, every time.

A user changing a hidden property will usually not do so without knowing what he does, so I would say that a SHOULD-standard, if one existed, could be overriden by such a pref. Given that no standard seems to exist, why not give the user the ability to choose? Its just a hidden pref.

    
    

    
  


  
this would be a pretty simple per-account UI change that should work for defaulting to having the -- be the signature separator but allows people to turn it off when editing the signature itself.

    
    

    
  
(In reply to comment #154)
> this would be a pretty simple per-account UI change that should work for
> defaulting to having the -- be the signature separator but allows people to
> turn it off when editing the signature itself.

I don't think we want UI for that in SeaMonkey. 
(Just in case someone feels like implementing that.)

    
    

    
  
(In reply to comment #155)

> I don't think we want UI for that in SeaMonkey. 
> (Just in case someone feels like implementing that.)

Why not? If we commit to having this feature, we might as well have a UI for it. "We don't want people to use it, so we hide it as good as we can" doesn't seem a valid approach.

    
    

    
  
(In reply to comment #156)
> Why not? If we commit to having this feature, we might as well have a UI for
> it. "We don't want people to use it, so we hide it as good as we can" doesn't
> seem a valid approach.

It's a perfectly valid approach, in fact it's good application design. The ideal application is both simple to use for beginners, but powerful to use for professionals. Hiding functionality away from the novice user who may not be aware of all of the implications of using is the right thing to do, so long as the person who is aware of those implications still has an 'easy enough' way to get at it. I define googling for "disable thunderbird signature separator" and then reading the results to be 'easy enough'.

    
    

    
  
I must agree with comment #154 and comment #156.  I would want to suppress the separator for mail accounts but not for news accounts.  But I don't want to keep going into the Config Editor to switch the preference variable back and forth.

    
    

    
  
David, any chance you could review this soon?
Whiteboard: [has patch][needs review]

    
    

    
  
Unfortunately, I'm still on dial-up.  Thus, I don't download nightlies, alphas, or betas and only occasionally release candidates.  Further, having retired as a software engineer more than six years ago, my ability to read code is now rusty.

    
    

    
  
Once again David E. Ross, I was asking David Bienvenu. You maybe miss comment 147 from Chris :)

    
  

        Attachment #419827 -
        Flags: review?(bienvenu) → review-

    
    

    
  
Comment on attachment 419827 [details] [diff] [review]
To satisfy RFC 3676, the suppress_signature_separator option should not apply to news posts

this patch looks reasonable, but it doesn't seem to apply; can you un-bitrot it and attach a newer version?

    
  
URL: http://gsfn.us/t/np5b
Whiteboard: [has patch][needs review] → [has patch][needs review] [gs]

    
    

    
  
I'll update the patch to work with the new version, on the assurance that somebody will actually review it this time. I don't really appreciate giving up my free time to solve a problem only to have my work ignored and left to rot. 

Can I get word that there is someone with commit privileges willing to look at my patch and approve it sometime in a timescale of days rather than months? I will do this only once more.

    
    

    
  
Kieran, your patch almost still applies, just a single hunk is failing:

> patch --dry-run -p1 < suppressSigSep.2.patch
> (Stripping trailing CRs from patch.)
> patching file mailnews/base/public/nsIMsgIdentity.idl
> (Stripping trailing CRs from patch.)
> patching file mailnews/base/util/nsMsgIdentity.cpp
> Hunk #1 FAILED at 193.
> Hunk #2 succeeded at 576 (offset 3 lines).
> 1 out of 2 hunks FAILED -- saving rejects to file mailnews/base/util/nsMsgIdentity.cpp.rej
> (Stripping trailing CRs from patch.)
> patching file mailnews/compose/src/nsMsgCompose.cpp
> Hunk #1 succeeded at 4110 (offset 70 lines).
> Hunk #2 succeeded at 4191 (offset 70 lines).
> Hunk #3 succeeded at 4278 (offset 70 lines).

The problem with Hunk #1 in nsMsgIdentity.cpp appears to be the addition of two more lines for DoCc and DoCcList at the same spot where you wanted to add your new preference, so that should be fixable as long as the rest still works.

I don't know which MailNews Core reviewer has time to perform the review, maybe someone (if not bienvenu) with the appropriate status volunteers?
Whiteboard: [has patch][needs review] [gs] → [needs new patch] [gs]

    
    

    
  
rsx11m,
That's encouraging thanks, I should be able to get it working again fairly easily. I'm just setting up an ubuntu build environment now so I'll get the updated patch submitted shortly.

I've got a couple of hours today to sort this but once I submit the patch I need the assistance of anyone else who wants to see this feature added to keep up the pressure on the developers to get the patch reviewed and approved.

    
    

    
  


  
This patch now applies successfully to the latest source tree - please review.

        Attachment #466749 -
        Flags: review+

    
    

    
  
Comment on attachment 466749 [details] [diff] [review]
Patch updated to work with latest source tree

I'm assigning this to bienvenu again as he had already a closer look at the previous patch, judging from comment #162.

        Attachment #466749 -
        Flags: review+ → review?(bienvenu)

    
  
Whiteboard: [needs new patch] [gs] → [needs review bienvenu][gs]

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Finished version of the patch (obsolete)
        — 
          — Splinter Review
      

    


  
Forgot to include the update to make the option only apply to mail messages (for RFC compliance). This patch now includes that change and successfully applies to the current source tree. This is the finished patch for review.

        Attachment #419827 -
        Attachment is obsolete: true

        Attachment #466749 -
        Attachment is obsolete: true

        Attachment #466749 -
        Flags: review?(bienvenu)

    
  

        Attachment #466770 -
        Flags: review?(bienvenu)

    
    

    
  
Comment on attachment 466770 [details] [diff] [review]
Finished version of the patch

thx for the patch.

You need a new uuid for nsIMsgIdentity since the interface changed.

I think we need a default in mailnews.js for mail.identity.default.suppress_signature_separator

Also, we try to keep lines < 80 chars or so, so a couple of the lines you changed need wrapping.

        Attachment #466770 -
        Flags: review?(bienvenu) → review-

    
    

    
  
Thanks for the feedback, shouldn't be a problem to fix these - I'll get a new patch submitted shortly.

    
    

    
  


  
Corrected in response to feedback from David Bienvenu

        Attachment #466770 -
        Attachment is obsolete: true

    
    

    
  


  
Correct version following feedback from David Bienvenu

        Attachment #466833 -
        Attachment is obsolete: true

    
    

    
  


  
Just some tweaks to clean up the formatting - this should be the final version.

        Attachment #466836 -
        Attachment is obsolete: true

    
    

    
  
Okay I've made all the changes requested by David. I've reformatted a couple of 'if' statements to make them more legible and sorted out the formatting so it doesn't go over 80 cols. Let me know if there's any other changes needed before approval.

    
    

    
  
Comment on attachment 466837 [details] [diff] [review]
Clean up formatting and legibility

Kieran, the updated patch looks good to me.

BTW: You can request reviews yourself by switching the "review" selector to '?' and copy-paste the e-mail address of whom you want to review the patch into the box next to it, then submit.

        Attachment #466837 -
        Flags: review?(bienvenu)

    
    

    
  
(In reply to comment #169)
> You need a new uuid for nsIMsgIdentity since the interface changed.

Does this imply that his patch needs superreview by the revised mailnews rules?

    
    

    
  
I think all patches also need to include tests these days.

Later,
Blake.

    
    

    
  
Comment on attachment 466837 [details] [diff] [review]
Clean up formatting and legibility

can you add parens around the clause after the && so it's clear exactly what the condition is? Same thing for the second if clause later in the patch.
+      if ((mType == nsIMsgCompType::NewsPost || !suppressSigSep) && 
+           reply_on_top != 1 || sig_bottom || !aQuoted) {

r=me with that fixed.

We already have a mozmill test for signature handling, and this patch doesn't regress that. If we had a UI for suppressing signatures, I'd want that mozmill test to be extended to handle this pref.

        Attachment #466837 -
        Flags: superreview?(bugzilla)

        Attachment #466837 -
        Flags: review?(bienvenu)

        Attachment #466837 -
        Flags: review+

    
  
Assignee: nobody → kieran
Flags: in-testsuite-
Whiteboard: [needs review bienvenu][gs] → [gs]

    
    

    
  


  

        Attachment #466837 -
        Attachment is obsolete: true

        Attachment #467490 -
        Flags: superreview?(bugzilla)

        Attachment #467490 -
        Flags: review+

        Attachment #466837 -
        Flags: superreview?(bugzilla)

    
    

    
  
The UI is a task I'll leave for another developer - I've put the config option there, so someone more familiar with the UI code should be able to add a checkbox fairly easy. That is of course if it's decided that one is even needed.

I've done some GTK stuff in Python and found it thoroughly unpleasant, I should imagine I'd find it equally unpleasant in C++, so while it is tempting to go one step further and do the UI change as well, I think I'll stick to UI design in HTML+Javascript thanks :)

    
    

    
  
Hi all,

Are there any news about the review? I really would like to see this feature in the next thunderbird release.

    
    

    
  
Since David is one of the MailNews module owners, and he's "r=me"d, the next step should be:
https://developer.mozilla.org/En/Developer_Guide/How_to_Submit_a_Patch#Committing_the_Patch

    
  
Keywords: checkin-needed

    
    

    
  
I've added "checkin-needed" to the keywords, hopefully someone with commit access will pick it up.

    
    

    
  
In my opinion, it would really be a shame if this issue were to be closed before its 10th birthday. After all, we don´t want to be hasty, do we?

    
    

    
  
(In reply to comment #182)
> Since David is one of the MailNews module owners, and he's "r=me"d, the next
> step should be:
> https://developer.mozilla.org/En/Developer_Guide/How_to_Submit_a_Patch#Committing_the_Patch

Actually, this patch needs sr as indicated on the patch status, so its not quite ready for check in yet.
Keywords: checkin-needed

    
    

    
  
(and I hope to get to it today or tomorrow)

    
    

    
  
Any news on this superreview?

    
    

    
  
Sorry for the delay, I'll get to it early this week.

    
    

    
  
Just a friendly reminder, any chance you could look at this soon? 

It's a relatively trivial change so it shouldn't really take long to look at, the only thing that needs any real scrutiny is the changes I've made to two conditional blocks at the end of the patch (they're the only things that change program flow in any way).

    
    

    
  
Comment on attachment 467490 [details] [diff] [review]
Added parens around conditional as requested

Sorry for the delay, I was going to do it yesterday, but got tied up with releases.

This patch looks fine sr=Standard8.

I would definitely like to get a unit test for this - hidden options can easily get broken and not picked up for quite a while.

There is an example test for signatures here:

http://mxr.mozilla.org/comm-central/source/mail/test/mozmill/composition/test-signature-updating.js

and there's information on our MozMill test suite here:

https://developer.mozilla.org/en/Thunderbird/Thunderbird_MozMill_Testing

If you're not going to take this on, please let us know so that we can make sure we get test coverage.

        Attachment #467490 -
        Flags: superreview?(bugzilla) → superreview+

    
    

    
  
To be honest I think the unit test is going to take me quite a while to figure out - if there's anyone who knows MozMill and can whip up a test fairly quickly, please volunteer. If nobody speaks up I will put the time in to figure out MozMill, but it's pretty unlike anything I've done before so this bug may yet see it's 10th birthday.

    
    

    
  
ok, that's fine, I'll do it early next week.

    
    

    
  
1.
Seeing as how you all have wandered into this...recently....Another solution to the standards issue is to allow a series of auto-inserted line breaks between the email text, and the two dashes.

2.
The solution suggested way above: [using span with nodisplay] works...except...

When I reply to an incoming email using that method, TBird DOES NOT attach my HTML signature above or below the quoted text.

If I reply to an incoming email from my other account, which uses a text signature [and TBird prepends the "--"], on that account, the signature DOES appear

I wonder if this case testing will turn up a bug, on the proposed patch, or if I will be bag filing a bug...

3a.
Some of my alluded to issues, above, and the many many issues above me, are solved by allowing the user-defined auto-insertion of characters at the end of an eMail.   Most users will -call- THAT a "Signature", and won't care if it is not an RFC signature.
3b.
Does the proposed patch effectively do this?

4.
Re-urging #3, above.

    
    

    
  
(In reply to comment #193)
> 3b.
> Does the proposed patch effectively do this?

I think so yes. It basically stops the -- ever being added to the message body. As I understand it, no mail RFC mandates the use of the -- separator so there's no compliance issue. With the option enabled, a signature just becomes a string of text or HTML to be appended to the message body, this is the behaviour of pretty much every other desktop and web-based e-mail client - I think is what most people expect it to be by default to be honest.

    
    

    
  
Is anybody working on the unit tests?

    
    

    
  
Per comment #192, Mark promised to take care of the tests as he requested them.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Unit test
        — 
          — Splinter Review
      

    


  
I took a look at the unit test for this, and here it is.

However I did notice that in suppressing the signature separator on plain text composition, there is a bug -  if you have more than one identity defined and you swap between identities, then the old signature does not get removed.

On HTML composition this is fine, as we can detect the start of the signature via a class name on an html node. With plain text composition, we were detecting the "-- " as the start of the signature.

I think that this can be handled in a follow-up bug, the potential solution would be to look for the whole signature and remove that.

Requesting review from David to review the test case and get his opinion on covering the remaining issue in a follow-up bug.

        Attachment #481789 -
        Flags: review?(bienvenu)

    
    

    
  
(In reply to comment #198)
> However I did notice that in suppressing the signature separator on plain text
> composition, there is a bug -  if you have more than one identity defined and
> you swap between identities, then the old signature does not get removed.

That's basically bug 218346, where removing the "-- " now also with the
signature at the bottom makes this issue visible for anybody selecting to
opt out of the signature delimiter.

    
    

    
  
I didn't read this bug completely, but David, is there anything I can help with here?

    
  

        Attachment #481789 -
        Flags: review?(bienvenu) → review+

    
    

    
  
Ehsan, thx, I think we're good. 

Standard8, yes, I think we can handle the remaining issue in a follow-up bug, and it sounds like bug 218346 is a good candidate.

    
    

    
  
Kieran, unless David or Mark checks both patches in, you should set the "checkin-needed" keyword as all necessary reviews now have been approved.

    
  
Keywords: checkin-needed

    
    

    
  
Checked in:

Patch: http://hg.mozilla.org/comm-central/rev/02c02a7eeed8
Unit test: http://hg.mozilla.org/comm-central/rev/6bf6e5d776c2
Status: NEW → RESOLVED
Closed: 14 years ago
Flags: wanted-thunderbird3?
Flags: in-testsuite-
Flags: in-testsuite+
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.3a1

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
  
Thanks for everyone's assistance in getting this patch checked in - it's gratifying to see this issue finally resolved.

    
    

    
  
Unfortunately, I can't find a reason to reopen this so that the bug can celebrate its 10th birthday. ;-) No tests are broken and the new preference
works fine in the nightlies [verified fixed Mozilla/5.0 (X11; Linux x86_64; rv:2.0b8pre) Gecko/20101026 Thunderbird/3.3a1pre, Win32 tinderbox builds].

Given the number of posts and requests in MozillaZine and GetSatisfaction
for this feature, I'm nominating the bug for TB 3.2 to keep it on the radar
if that version indeed comes from comm-1.9.2.
Status: RESOLVED → VERIFIED

          status-thunderbird3.2:
          --- → ?

    
    

    
  
Is this fixed in a end-user release of Thunderbird?  Or it is planned for a version not yet released?

    
    

    
  
(In reply to David E. Ross from comment #212)
> Is this fixed in a end-user release of Thunderbird?  Or it is planned for a
> version not yet released?

Generally look at the milestone: 3.3a1. So this would have been incorporated into 3.3 alpha 1 (which later became 5). As it is already released for quite a while, if you're seeing an issue still I suggest you file a new bug.

          status-thunderbird3.2:
          ? → ---

    
    

    
  
(In reply to David E. Ross from comment #212)
> Is this fixed in a end-user release of Thunderbird?  Or it is planned for a
> version not yet released?

(In reply to Mark Banner (:standard8) from comment #213)
> Generally look at the milestone: 3.3a1. So this would have been incorporated
> into 3.3 alpha 1 (which later became 5).

I can confirm that the setting works in Thunderbird 5. I guess the bug actually *did* make it's 10th birthday before the fix was released to the public.

    
    

    
  
Now that this setting has been added to Thunderbird, it would be good if the Signature Switch add-on could be modified to look for the "mail.identity.default.suppress_signature_separator" flag and act properly if the flag is set.

I'm concerned, though, because the last time I checked, the author of "Signature Switch" was a firmly committed advocate of the dashes separator -- which he considered to be a mandatory standard -- and when I asked him some time ago to modify his add-on to allow users to suppress the separator, he flatly refused.

Perhaps now that a flag to suppress the separator has been added to TB5, someone might have better success getting the Signature Switch author to take a more expansive view of the issue that I had.

    
    

    
  
It may be needed for the same reason as bug 218346 occurs with the separator removed. Either way, you'll have to discuss this with the add-on's author.

    
    

    
  
I have submitted RFE bug #679797 to have a user interface for setting the preference variable mail.identity.default.suppress_signature_separator.

    
  
Blocks: 679797

    
    

    
  
For what it may be worth, I e-mailed the author of the Signature Switch add-on, referring him to this bug report and asking him to reconsider adding support for suppressing the signature separator.  It's been about three months, and I haven't heard back.

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: