Closed Bug 121424 Opened 23 years ago Closed 22 years ago

Signature should be interpreted from last line to delimiter

Categories

(MailNews Core :: MIME, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: holgermetzger, Assigned: sspitzer)

Details

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7+) Gecko/20020122 BuildID: 2002012203 Right now, Mozilla interprets the signature by looking for the first "-- " and interprets all following text as signature. I think it would be better if Mozilla would check from the last line of a message up to the first "-- " it encounters. This way it is ensured, that a random "-- " within the text is not interpreted as the signature delimeter.
this is front end.
Assignee: mscott → sspitzer
Component: Mail Back End → Mail Window Front End
Would be a nice enhancement. Setting platform/os to all.
OS: Windows NT → All
Hardware: PC → All
I happen to think that the current behaviour is better. I think the spec suggests that the current behaviour is even more correct, but you could probably argue about that. In any case, what if I have a signature myself and the mailing list software adds another? Then, both should count as signature. > This way it is ensured, that a random "-- " within the text is not interpreted > as the signature delimeter. Have you ever encountered random "-- " in the body? I don't remember ever seeing that. Apart from that, given the way libmime works, this RFE would be extremely hard to implement (if possible at all). BTW: It's libmime, not front end. I vote for WONTFIX. Confirming nevertheless, because it's a valid suggestion.
Status: UNCONFIRMED → NEW
Component: Mail Window Front End → MIME
Ever confirmed: true
Some newsreaders (MT-Newswatcher on MacOS for example) look for the signature separator from bottom to "-- ". A random "-- " could happen (especially with format=flowed readers where a "--" would turn into "-- "). Maybe someone uses it for a list for separating text. Also, many Web-based mailer add a signature to any outgoing message, and if a user also adds a signature, then Mozilla interprets only the first "-- " as signature. OK, I have to admit, it's not very likely, but hey, you never know. :-)
> (especially with format=flowed readers where a "--" would turn into "-- "). No, the f=f standard knows special guards against that, IIRC. > Also, many Web-based mailer add a signature to any outgoing message, and if a > user also adds a signature, then Mozilla interprets only the first "-- " as > signature. huh? that's exactly the same case as with the mailing lists, no? If the user has a sig and the webmail app adds another at the end, then *both* are sigs. This current code would recognize both as one sig. Your proposed changes would not recognize the user sig as sig anymore. This is exactly the case why I think that the current solution is better than the suggested one.
Summary: Signature should be interpreted from last line to delimeter → Signature should be interpreted from last line to delimiter
I supmitted bug 178011 before doing the correct search to find this bug. A common way to reproduce the problem is to subscribe to a mail list digest. The digest will include a number of emails, some of which will contain sigs starting with "--". When you reply to such a digest, the digest is not completely quoted. It's truncated at the first "--" sig. I've had good luck with bottom up processing in certain mail handling systems whose job it is (among other things) to remove sigs.
Alex, it works in the case of viewing, not? Only the sigs are dimmed, not the rest of the digest, right? This works because Mozilla knows how to process these digests, and it shows that the method itself is not broken. If Reply behaves differently, that's a reply-specific bug. The sig detection method is the same in both cases. WONTFIXing.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.