Once the patch for bug 62429 gets checked in there will be no delimiter inserted when the signature is placed between the reply and above the quoted text. This bug is for the implementation of a hidden pref that will let the user change the delimiter's behaviour. I propose the choices for this pref would be: 0 - follow default behaviour 1 - always use a delimiter 2 - never use a delimiter

I don't see the usefullness of this bug. If top-reply+top-sign, then using a delimiter would cause: CASE: "always use delimiter" A) all quoted text to be treated as a signature (yuk) B) all quoted text to be truncated on ech reply CASE: "never use delimiter": A) no signature would ever get removed, whether top or bottom sig is used Could this adversely affect the *recipient* of a mozilla e-mail? That would be unacceptable. :-\ Ah well, perhaps there could be people that would want this, and why take that possibility away from them - after all, it would be a *conscious choice and effort*.

I think this would be a very good pref to have. For instance if I were converting a group of people over to Mozilla/Tbird, I would set the pref to never delimit. If certain experienced people wanted to have the delimiter they could change the pref or just include the "-- " line as part of their signature. Then later after people got used to Mozilla/Tbird, and if it seemed appropriate, I could spend the time explaining to people about the delimiter and what it was for and see if they wanted to start using it.

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 2 is not very convincing. The signature delimiter is for the recipient, not the sender. The clueness of the sender is irrelevant. Esp. novices should have the correct delimiter, so that their overly lenghtly and boring signatures are not so annoying for the experienced users. Comment 3 talks about problems while processing *received* signatures, typically from other, broken mailers. It has nothing to do with making *us* send correct signature delimiters. There's no problem here. If Mozilla added the signature, we are sure it's a signature, and that's all the delimiter says. WONTFIX

> Comment 3 talks about problems while processing *received* > signatures Agreed; good point. That should be covered in the other bugs. >There's no problem here. Here we part ways: I actually like sending e-mails with it in, but that's not the point. Why do we have it? 1) It's not a standard, even an obscure one: No RFC mentions it for e-mail (2646 & 1036 recommend but don't require it for Usenet, not mail) ... AFAIK. 2) It's not a de facto standard: The only messages I see with this delimiter are from Mozilla clients. 3) It's aesthetically ugly and unprofessional looking (unless you're a unix sysadmin or developer). Aesthetics count. 4) Users don't like it (based on anecdotal experience, of course): For reason #3, and because they don't understand it, and it modifies their e-mails without their knowledge. 5) It's meant to benefit recipients, but very few know what it is, much less desire it. Most probably respond like my users do. It's not standard, very few people want it (again, one is me), far more people don't want it, the benefit is minor and there are drawbacks. It sounds like it belongs in an extension; it's a needless complication for 99% of users. But, at least two major contributors want it. Given that it's already there and that they contribute so much to Mozilla (not that it's rational to pick features that way), I'd be willing to support leaving it in, but there's no reason we can't allow it to be disabled.