Subject: Folding of Subjects Date: Tue, 06 Apr 1999 00:00:19 -0400 From: John Moreno <phenix@interpath.com> Organization: . Newsgroups: netscape.public.mozilla.mail-news A recent thread in nl.newsgroups uncovered a problem with NSC 4.5 -- it folds the Subject header at ~80 chars, but when it does so it doesn't /replace/ the SP (space) with CRLFSP, instead it simply /inserts/ CRLFSP. This means that when another program (like Agent) unfolds the header a extra space may be present. This messes up sorting by Subject. I'm going to be updating the GNKSA evaluation to reflect this (this causes it to fail 5b, and I'm adding a comment to explain why).

This looks like a 4.5 bug. Shouldn't it be assigned to someone on the escalation team?

I doubt that bug is important enough to fix in a 4.5x maintenance release. I entered it here to get it looked at in 5.0.

moving to m6. I'll take a look at it then, and make sure 5.0 does the right thing.

The routine to look into is xp_word_wrap() in mozilla/mailnews/mime/src/compi18n.cpp.

moving to m9

re-assign to rhp. this sounds like a back end msg compose bug.

This is fine tuning...moving out.

I don't think this needs to be fixed for PR1

reassigning to ducarroz

This is a GNKSA absolute requirement. Adding bug #76449.

Test message:<030520011436309733%planb@newsreaders.com>. Previously the rules for folding were a bit loose, RFC2822 (the replacement of 822) tightens them up: folding is done by /inserting/ CRLF before a white space character, unfolding is done by removing the CRLF. The RFC doesn't say so, but IMO it would also be good to do this to the earliest possible WSP character (i.e. if there are two spaces next to each other, insert the CRLF before the first space, not after).

Looking at article <3AF2E239.3020500@nowhere.net>, it doesn't look like Mozilla folds the Subject at all, should this be marked "Fixed"?

Accepting

It looks like mozilla folds only mime encoded subjects. It wraps it by inserting \t\n, which, per RFC<don't recall the number> must be ignored between encoded words. I'm not quite sure why mozilla doesn't folds ascii subjects, but at least, it doesn't insert any additional SPs

> It looks like mozilla folds only mime encoded subjects. It wraps it by > inserting \t\n, which, per RFC<don't recall the number> must be ignored between > encoded words. I have Moz 0.9.7 on W2K. I have moz talking to Exchange via POP (Not my choice, this is at work). Exchange tends to make ASCII emails into text/html multi-part mime emails. Thus ascii text or text/html multi-part mime emails arrive as multi-part mime. The problem with this is that the Subject: field looks like this Subject: lkasjdhlkasd flksahlfkdhal kfdhasdf laksjdfh lkjsadhflkj aldfkjhl ksfh akjfdh asdfh lkjadshf lkahsdflk jahkjfdh ajdfhlaksjdhf lkajdhsflk ja lfdkj hkjfdh ahfd lkashfd lkjahsdfkljalfkjhdsalkfjh lkjfdshasldkjf hlfd That's a TAB character that's been inserted at the start of every line (except the first). Strangely, this doesn't happen if I send HTML-only email. Moreover, Mozilla doesn't seem to remove the tab characters. The window title, the subject field of the mailbox display, and most annoyingly, the text that goes in the subject when you reply or forward the email are affected. In the window title and mailbox display, I see is a small square where the TAB is. In replys or forwards, I end up TAB characters part-way through the subject line. So is Exchange doing something wrong, or is Mozilla doing something wrong? If it's Exchange, is it possible (or even likely) to get Mozilla to work around the problem?

*** This bug has been marked as a duplicate of 73403 ***

v