Sig delimiter malformed for quoted printable

VERIFIED FIXED

Status

()

P3
normal
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: BenB, Assigned: rhp)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3+])

(Reporter)

Description

18 years ago
Reproduction:
1. Check Prefs|Mailnews|Composer|quoted-printable (i.e. not "as-is")
2. Set your account preffs to use a plaintext signature with only one normal
line, e.g. "foo", as content
3. Compose a new msg using the HTML composer with 8bit-chars, e.g. "дьц".
4. Send
5. Look at the source

Actual result:
The sig reads
<example>
-- =

foo
</example>.

Expected result:
The sig reads
<example>
-- 
foo
</example> (with a space after "--").

Relevance:
This is kind-of a "standards-conformance" bug. IIRC, the sig delimiter is
somewhere standardized in a news RFC. If it is only slightly wrong, software
(including Mozilla) won't recognize it anymore. nsbeta3 nomination for this
reason.

Additional comments:
Not sure, if this is a HTML->TXT, Editor or libmime bug. Guessing HTML->TXT
first.
(Reporter)

Updated

18 years ago
Keywords: nsbeta3

Comment 1

18 years ago
I'm definitely not the one adding the "=".  Guessing libmime.
Assignee: akkana → rhp
(Assignee)

Comment 2

18 years ago
So the problem is looking at quoted printable source and seeing the "="?

Comment 3

18 years ago
Looks like a quoted printable trailing space. If this is a bug, it's probably in 
the quoted printable encoder or in the use of that encoder.

The same problem exists with format=flowed mails which is why RFC 2646 
specifically says that QP shouldn't be used.
(Reporter)

Comment 4

18 years ago
akk, sure :). This is quoted-pritable for a flowed line, just like the trailing
space in format=flowed. So, anything thinks, the sig delimiter were a flowed
line.

Not very surprisingly, Debug|OutputText in the editor doesn't show the "=".
Could this have the same source as bug 33492: an odd data path during send?

Rich, the problem is that is it there in the first place. It shouldn't. "-- " is
not a flowed line. I have no idea why it thinks it is. I guess, we're using the
libmime TXT->HTML conversion (precisely mimetpfl) somewhere during the send
process (and we shouldn't of course).
(Reporter)

Comment 5

18 years ago
> I guess, we're using the
> libmime TXT->HTML conversion (precisely mimetpfl) somewhere during the send
> process (and we shouldn't of course).

Wait, even mimetpfl knows that "-- " is a fixed line, right? Odd.
(Assignee)

Comment 6

18 years ago
If you are looking at quoted printable source, you will see the "=" as the 
delimiter at the end of the line.

I'm still not sure I see the bug here?

- rhp
(Reporter)

Comment 7

18 years ago
Rich, sorry, I don't see your problem. "-- " must be one its own line *in the
msg source*. It isn't. That's a bug.

Turns out we do that for every line. Type a paragraph > 80 chars (incl. 8bit
chars). Send. View Source. You'll see e.g.
<example>
tzuitzuizui=FC=E4=FC=F6=E4ertzertz zzzzzzzzzzzz zzzzzzzzzzzz =

zzzzzrtzzzzzzzzzzzzzzz zzzzzzzzzzzzzzzzz zzzzzz zzzzzzzzzzzzzz =

zzzzzzzzzzzzzz zzrtzzzzzzzz zzzzzzzzzzzz

-- =

<http://www.bucksch.org>
</example>
(Assignee)

Comment 8

18 years ago
Well, I can look at this if I have time, but this doesn't really feel beta3 to 
me.

- rhp
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → M19

Comment 9

18 years ago
But all this quoted printable things should be removed from the mail before it 
reaches anything/anyone in the mail program, right? Isn't that done now? That QP 
sucks, we already now, but at least it's not the default anymore.
(Assignee)

Comment 10

18 years ago
Quoted printable data lives in the file until rendered. It should not be 
removed until the rendering stage. Yes, this stuff should not be seen by the 
user (unless they want to look at the source of the message). This is why I say 
this isn't a beta3 type issue. 

- rhp
(Reporter)

Comment 11

18 years ago
> Yes, this stuff should not be seen by the 
> user (unless they want to look at the source of the message).

But it breaks the sig. And the user (the recipient in this case) will surely see
*that*. In Mozilla, we render thesig differently and remove it during reply. All
this breaks. And not only for us, for *all* recipients. That's why this is a
standards-conformance bug.

Comment 12

18 years ago
But it shouldn't. For instance, I think the quoted printable is removed before 
the text is coming to mimetpfl.cpp. Has you checked what mimetpfl.cpp sees?

(Reporter)

Comment 13

18 years ago
No, I didn't. But if you reply to such a msg, the sig is not removed.

(Completely OFFTOPIC: Daniel, did you get my msg to idasys? My mail to your
lysator account bounces, because the server doesn't accept mail directly from
dynamic IP addresses. :-( )

Comment 14

18 years ago
The quoted printable encoder treats trailing spaces wrongly. See 
<http://lxr.mozilla.org/seamonkey/source/mailnews/mime/src/mimeenc.cpp#888>. A 
trailing space shouldn't (generally at least) be encoded as a soft line break, 
but with =20 which is the code for SPACE. If it is treated as a soft line break 
by the receiver we could very well get the behaviour that Ben describes.

Comment 15

18 years ago
Wait, I see what it does now. I trailing space followed by a soft line break 
followed by an empty line should theoretically cause the correct string when 
decoded. But I still think that we should encode the space as =20 (or =09 if 
it's a tab). That means back up one step in the out string and overwrite the 
SPACE (TAB) with the code. 

Rich, is there special reason to do what we do right now?
(Assignee)

Comment 16

18 years ago
Probably no special reason aside from the fact that its been working for years 
so I'm always very cautious making changes to code like this as we approach the 
next beta.

- rhp
(Reporter)

Comment 17

18 years ago
> its been working for years

But then, we had no format=flowed and caused unreadable mails. Not everybody has
a QP-aware mailer.

> a soft line break followed by an empty line should theoretically cause the
> correct string when decoded.

This makes assumption about the idea of a paragraph (that it equals a line) in
the recieving mailers, which we must not make. If the assumption is wrong, the
sig won't be recognized.

Anyway, *we* break. We don't recognize the sig we put out.
(Assignee)

Comment 18

18 years ago
> > its been working for years

> But then, we had no format=flowed and caused unreadable mails. Not everybody 
> has a QP-aware mailer.

The code is at:
    http://lxr.mozilla.org/seamonkey/source/mailnews/mime/src/mimeenc.cpp#888

Feel free to hack away.

- rhp
Assignee: rhp → mozilla
Status: ASSIGNED → NEW
(Reporter)

Comment 19

18 years ago
Over to Daniel, you said he might be looking at it anyway.
Assignee: mozilla → bratell
(Reporter)

Comment 20

18 years ago
s/you/who

Updated

18 years ago
Assignee: bratell → mozilla

Comment 21

18 years ago
What? I did that before today. See my comments as of 2000-07-26 02:51 and 
2000-07-26 02:57. I didn't attach the patch though so here it comes. I won't do 
any extensive testing of how good the patch is though. I works for me. I get sig 
removal when replying.

Index: src/mimeenc.cpp
===================================================================
RCS file: /cvsroot/mozilla/mailnews/mime/src/mimeenc.cpp,v
retrieving revision 1.8
diff -u -r1.8 mimeenc.cpp
--- src/mimeenc.cpp     1999/11/06 03:32:39     1.8
+++ src/mimeenc.cpp     2000/07/26 18:45:30
@@ -887,15 +887,17 @@
        {
          if (*in == CR || *in == LF)
                {
-                 /* Whitespace cannot be allowed to occur at the end of the lin
e.
-                        So we encode " \n" as " =\n\n", that is, the whitespace
, a
-                        soft line break, and then a hard line break.
-                  */
-                 if (white)
-                       {
-                         *out++ = '=';
-                         *out++ = CR;
-                         *out++ = LF;
+          /* Whitespace cannot be allowed to occur at the end of
+             the line, so we backup and replace the whitespace with
+             it's code.
+          */
+          if (white)
+            {
+              out--;
+              char whitespace_char = *out;
+              *out++ = '=';
+              *out++ = hexdigits[whitespace_char >> 4];
+              *out++ = hexdigits[whitespace_char & 0xF];
                        }

                  /* Now write out the newline. */


Back to Ben. You may play with this and check it in if Rich thinks it's good. 
The M17/nsbeta2 branch is today so I guess the tree will be open to a little 
more risky checkins again tonight or tomorrow.
(Assignee)

Comment 22

18 years ago
Fine with me guys...just make sure it doesn't go into the tree until after we 
branch.

- rhp
(Reporter)

Comment 23

18 years ago
Daniel, then, this was a misunderstanding.

Just because I report a bug doesn't mean I am willing to fix it. I have too many
bugs on my plate already. Back to Rich.
Assignee: mozilla → rhp
(Assignee)

Comment 24

18 years ago
Guys, this is getting stupid. I'll take care of this (THIS TIME), but in the 
future, can we have less crap filling my inbox (i.e. just email each other)..

- rhp
(Reporter)

Comment 25

18 years ago
Rich, I have problems to follow you. Shouldn't I file bugs?
(Assignee)

Comment 26

18 years ago
Filing bugs is ok. But bouncing them back and forth, marking them as beta 
stoppers and commenting on every statement I make is not productive at this 
point in the process. I don't need all the distractions and if you have time to 
do all of the bugzilla work, you would have as much time as me to apply the 
patch and test it.

- rhp
Status: NEW → ASSIGNED
(Assignee)

Comment 27

18 years ago
I will get this into the tree when it opens for beta 3.

- rhp
Summary: Sig delimiter malformed for quoted printable → [FIXED] Sig delimiter malformed for quoted printable
Whiteboard: [FIXED]
(Assignee)

Comment 28

18 years ago
per selmer and mail/news PDT.
Whiteboard: [FIXED] → [FIXED] [nsbeta3+]
(Assignee)

Comment 29

18 years ago
Just checked in a fix.

- rhp
Summary: [FIXED] Sig delimiter malformed for quoted printable → Sig delimiter malformed for quoted printable
Whiteboard: [FIXED] [nsbeta3+] → [nsbeta3+]
(Assignee)

Comment 30

18 years ago
one more time...
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 31

18 years ago
marking verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.