216728 - Let delimiter behaviour with position of signature be overridden

Status: RESOLVED WONTFIX

(MailNews Core :: Composition, enhancement)

Description

[Ian Neal]

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

Comment 1

[Peter Lairo]

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*.

Comment 2

[Chuck Harkness]

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.

Comment 3

[guanxi]

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 4

[Ben Bucksch (:BenB)]

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 5

[guanxi]

> 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.