Reply-to-all not created correctly for mail in IMAP folder, if mail has no null-line, no mail-body-line

NEW
Unassigned

Status

MailNews Core
Networking: IMAP
--
major
8 years ago
2 years ago

People

(Reporter: Simon Toth, Unassigned)

Tracking

({testcase})

1.9.1 Branch
x86_64
Linux
testcase

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/532.2 (KHTML, like Gecko) Chrome/4.0.222.2 Safari/532.2
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; cs-CZ; rv:1.9.1.5) Gecko/20091122 SUSE/3.0.0-4.1 Thunderbird/3.0

Thunderbird 2 works just fine, but all versions of Thunderbird 3 have problems parsing 8bit emails.

Only the sender is added to the reply. See the attached email.

Reproducible: Always

Steps to Reproduce:
1. select reply to all

Actual Results:  
only sender is included

Expected Results:  
both sender and the mailing list address should be included
(Reporter)

Comment 1

8 years ago
Created attachment 415599 [details]
8bit email example
(Reporter)

Updated

8 years ago
Version: unspecified → 3.0
Keywords: testcase
Attachment #415599 - Attachment mime type: application/x-mimearchive → text/plain
(In reply to comment #0)
> Only the sender is added to the reply. See the attached email.
> Expected Results:  
> both sender and the mailing list address should be included

I can't find other than next headers for candidate of To: or CC: upon reply in mail data you attached.
> Return-Path: <325140@mail.muni.cz>
> From: Jakub =?UTF-8?Q?Holot=C3=ADk?= <325140@mail.muni.cz>
Which mail header(s) do you mean by your "both sender and the mailing list address"? Received: header?
(Reporter)

Comment 3

8 years ago
> I can't find other than next headers for candidate of To: or CC: upon reply in
> mail data you attached.
> > Return-Path: <325140@mail.muni.cz>
> > From: Jakub =?UTF-8?Q?Holot=C3=ADk?= <325140@mail.muni.cz>
> Which mail header(s) do you mean by your "both sender and the mailing list
> address"? Received: header?

The Reply-To-All email should be addressed to both 325140@mail.muni.cz and pb161extra@fi.muni.cz (actually not mailing list but a group address).

It always works correctly if the email is 7bit encoded. 325140@mail.muni.cz is selected as To: and pb161extra@fi.muni.cz as CC:.
(Reporter)

Comment 4

8 years ago
To clarify.

I have 75 people sending approx. 2 emails each week to this address (pb161extra@fi.muni.cz). Some of these emails are coming from the Masaryk university information system (like this one) which sends emails in 8bit encoding.

As far as I can tell, this problem ONLY appears when the email is sent 8bit encoding (I'm sure I had this problem with one or two emails in 8bit encoding not sent by the IS, but can't find them right now, almost all other clients send emails in 7bit or BASE64). All other reply-to-all emails are formed correctly.

KMail and mutt are forming the reply-to-all emails correctly as well (even on the 8bit encoded ones).
(In reply to comment #3)
> The Reply-To-All email should be addressed to both 325140@mail.muni.cz and
> pb161extra@fi.muni.cz (actually not mailing list but a group address).

Which mail header(s) are you talking about?
I can see next headers only which has string of "pb161extra@fi.muni.cz".
Are you talking about "To: pb161extra@fi.muni.cz"?
> X-Original-To: pb161extra@fi.muni.cz
> Received: from minas.ics.muni.cz (minas.ics.muni.cz [147.251.4.40])
>  by anxur.fi.muni.cz (Postfix) with ESMTP id A78604940BF
>  for <pb161extra@fi.muni.cz>; Wed,  2 Dec 2009 11:05:55 +0100 (CET)
> Received: from arethusa1.fi.muni.cz (arethusa1.fi.muni.cz [147.251.49.6])
>  by minas.ics.muni.cz (8.13.8/8.13.8/SuSE Linux 0.8) with ESMTP id nB2A5sIR023954
>  for <pb161extra@fi.muni.cz>; Wed, 2 Dec 2009 11:05:55 +0100
> Received: by sender-daemon@arethusa1.fi.muni.cz
>  PID 19719 for pb161extra@fi.muni.cz@mail.muni.cz; Wed, 02 Dec 2009 11:05:54 +0100
> To: pb161extra@fi.muni.cz
> Message-ID: <1259748290-325140-659.455758656204-19319@mail.muni.cz>

> pb161extra@fi.muni.cz (actually not mailing list but a group address).

What syntax/sematics do you mean by your "mailing list" and/or "group address"?
Both 325140@mail.muni.cz and pb161extra@fi.muni.cz look for me ordinal/traditonal mail address...
(Reporter)

Comment 6

8 years ago
pb161extra@fi.muni.cz is an email alias, all emails sent to this address will be received by everyone in the group, its not a mailing list technically because its not processed by some daemon that adds mailing-list id and manages subscriptions.

Its like those global email addresses that almost every company has (like staff@organization.org, or techsupport@organization.org).
(In reply to comment #6)
> pb161extra@fi.muni.cz is an email alias, all emails sent to this address will
> be received by everyone in the group, its not a mailing list technically
> because its not processed by some daemon that adds mailing-list id and manages
> subscriptions.
> Its like those global email addresses that almost every company has (like
> staff@organization.org, or techsupport@organization.org).

How can an MUA(mail user agent==mail cilent, Tb is an MUA) know string of "pb161extra@fi.muni.cz" in some mail headers is "email alias, group address, mailing-list id, etc." you are talking, only by provided mail header(s) and string in provided mail header(s)?
(Reporter)

Comment 8

8 years ago
> How can an MUA(mail user agent==mail cilent, Tb is an MUA) know string of
> "pb161extra@fi.muni.cz" in some mail headers is "email alias, group address,
> mailing-list id, etc." you are talking, only by provided mail header(s) and
> string in provided mail header(s)?

Why should he? This fact is completely irrelevant. I don't really understand why are you so obsessed with the email address.

The problem is that Thunderbird is incorrectly parsing 8bit email headers (or at least some 8bit email headers) and does not form a correct Reply-To-All email. When the email is 7bit it works just fine.
(In reply to comment #8)
> Why should he? This fact is completely irrelevant. I don't really understand
> why are you so obsessed with the email address.

I'm tryng to know what do you mean by "the mailing list address should be included" in your next comment first.
> Expected Results:  
> both sender and the mailing list address should be included
What field in which mail header of mail you attaced is "the mailing list address" you are talking? 

> The problem is that Thunderbird is incorrectly parsing 8bit email headers
> (or at least some 8bit email headers)

Where can we see 8bit mail header?
All mail headers including following header consists of 7bit ascii only, 
> From: Jakub =?UTF-8?Q?Holot=C3=ADk?= <325140@mail.muni.cz>
although the mail has "Content-Transfer-Encoding: 8bit" and can have 8bit mail body data because the mail is written in UTF-8. 
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: 8bit

What phenomenon do you mean by "Thunderbird is incorrectly parsing"?
For which mail header in the mail you attached? 

> and does not form a correct Reply-To-All email. 
> When the email is 7bit it works just fine.

Decoded From: is as follows.
> Jakub Holotík <325140@mail.muni.cz>
Do you mean "Jakub Holotík" part doesn't appear in To: field upon Reply-All?
Or do you mean "Jakub Holotík" part is garbled?
(Reporter)

Comment 10

8 years ago
OK, my English is not my first language, so sorry if I'm being confusing. I will try again:

I'm part of the pb161extra mail group, therefore if anyone sends an email "To:" pb161extra@... I will receive it. The email will contain headers "From: someone@someplace.org" and "To: pb161extra@fi.muni.cz".

Now, when I hit reply-to-all, it is correctly formed with "To: someone@someplace.org" and "Cc: pb161extra@fi.muni.cz" UNLESS the email is in 8bit encoding in which case it fails, and only creates the reply-to-all with the "To: someone@someplace.org" field and ignores the "pb161extra@fi".

I'm talking about parsing problem of 8bit emails (the attachment is a complete email), because it ONLY happens with 8bit emails. This problem never appears when the email is 7bit or BASE64 (and I do get a lot of emails from different email clients).

And just to add the UTF-8 name is decoded correctly (even with 8bit emails).
(In reply to comment #10)
> The email will contain headers "From: someone@someplace.org" and "To: pb161extra@fi.muni.cz".
> 
> Now, when I hit reply-to-all, it is correctly formed with
> "To: someone@someplace.org" and "Cc: pb161extra@fi.muni.cz"
> UNLESS the email is in 8bit encoding in which case it fails,
> and only creates the reply-to-all with the "To: someone@someplace.org" field and ignores the "pb161extra@fi".

Why "Cc: pb161extra@fi.muni.cz" is put by Reply-All, even though your mail address of pb161extra@fi.muni.cz is placed in To: of received mail?
Mail in which account's folder you defined on Tb?
In which identitiy of which account is the tpb161extra@fi.muni.cz defined?
(Reporter)

Comment 12

8 years ago
> Why "Cc: pb161extra@fi.muni.cz" is put by Reply-All, even though your mail
> address of pb161extra@fi.muni.cz is placed in To: of received mail?

Maybe I was living on some other planet until now, but this is how reply-to-all always worked.

Put it in super simple terms:
Fred creates an email to Adam, Linda and me (Simon). The email will have the following headers: From: Fred, To: Adam, To: Linda, To: Simon.

If I hit reply-to-all the email should look like:
From: Simon, To: Fred, Cc: Adam, Cc: Linda

If you don't agree, then all email clients I have ever used are doing it wrong.

Put into specifics, someone creates an email to pb161extra. The email will have the following headers: From: Someone, To: pb161extra

If I hit reply-to-all the email should look like:
From: Simon, To: Someone, Cc: pb161extra

> In which identitiy of which account is the tpb161extra@fi.muni.cz defined?

In no identity, pb161extra is a an email alias/group address, I just receive emails sent to it.
(Reporter)

Comment 13

8 years ago
Btw, if you don't agree, then you should fix it, because this is how Thunderbird creates reply-to-all emails (unless they are 8bit, which is the whole point of this bug).
(Reporter)

Comment 14

8 years ago
So what? Are you finally willing to admit that it's not behaving as it should?
(In reply to comment #14)
> So what?

I can't still understand next in your comment #13.
> (unless they are 8bit, which is the whole point of this bug).

Pre-set From: of reply/reply-to-all is affected by X-Account-Key: header written by Tb if POP3. (See bug 327713 for this issue.)
Pre-set To: of reply/reply-to-all is affected by other headers such as Reply-to:.
Pre-set To:/CC: of reply-to-all is also affected by by other headers such as Reply-To:.
Pre-set From:/To:/CC: of reply/reply-to-all is affected by your Identity definition, because Tb has "reply-to-self" feature which is always enabled;
  If (A) From:your-mail-addr-2/To:your-mail-addr-1,
  (B) From:your-mail-addr-1/To:your-mail-addr-2 is pre-set by Tb upon reply.
  This feature is implemented by request from users who send mail like (A)
  to oneself frequently for house keeping.

All above is absolutely irrelevant to 8bit or 7bit, unless you use add-on which is relavant to From:/To:/CC: handling and Content-Transfer-Encoding: handling upon reply-all.

Merely next, isn't it?
  Mail header such as From:/To:/CC:, X-Account-Key:, Reply-To:, Sender:
  is different between;
      mails sent in UTF-8(Content-Transfer-Encoding:8bit)
  and mails sent in ISO-8859-1 etc.(Content-Transfer-Encoding:7bit).

(For From:/To:/CC: upon reply-all)
I can say say nothing about "what should be" and "Tb's implemented behaviour".
I can say next only;
  Tb's implemented behaviour is frequently different from user's thought.
  It's produced by "reply-to-self" and bug 327713 in many cases.

Can you attach mail data generated by reply-all for mail you attached?
 1. Reply-all to the mail, then "Send Later".
 2. Save generated mail in Outbox of Local Folders as .eml file.
 3. Attache the .eml file to this bug.
And, describe your expectation of From:/To:/CC: by reply-to-all, with explanation of "which mail-addr is defined as identity of which account and which mail-addr is not defined as identity", please.
(Reporter)

Comment 16

8 years ago
Created attachment 416517 [details]
Email generated by reply-to-all
(Reporter)

Comment 17

8 years ago
Created attachment 416518 [details]
7bit email example
(Reporter)

Comment 18

8 years ago
Created attachment 416519 [details]
Email generated by reply-to-all for the 7bit email
(Reporter)

Comment 19

8 years ago
I attached a reply generated for the 8bit email and a 7bit email that Thunderbird actually handles correctly and a reply to that one so you can hopefully finally believe that Thunderbird actually does generate reply-to-all as I described it.

My expectations are that if an email that I received contains another address then mine in the To: or Cc: field this address will be included in the Reply-To-All email in the header Cc:. I already described this in the post https://bugzilla.mozilla.org/show_bug.cgi?id=532360#c12

The account email addr. is simont@mail.muni.cz (which should be completely irrelevant) and once again pb161extra@fi.muni.cz is not defined in any identity as I already said in this post https://bugzilla.mozilla.org/show_bug.cgi?id=532360#c12
(Reporter)

Comment 20

8 years ago
Just to avoid further pointless posts.

I don't care if the problem is not actually caused by the 8bit encoding.Thats my observation (only 8bit email have this problem). And because it is just an observation I included the full email that causes the problem so it can be easily analyzed.

Is the problem caused by some header in the 8bit email?
Fine! Tel me which one, I will contact the Information System development team and request that they remove it.

Is it caused by something else, but its still a bug?
Fine, I don't care what's the cause, just fix it!
Affected by next difference in your environment?
> (attached 8bit mail => no CC: is generated)
> From: Jakub =?UTF-8?Q?Holot=C3=ADk?= <325140@mail.muni.cz>
> (attached 7bit mail => CC: is generated)
> From: =?ISO-8859-2?Q?Igor_Krn=E1=E8?= <igor.krnac@mail.muni.cz>

Can you check next 3 cases?
> From: =?UTF-8?Q?Jakub=20Holot=C3=ADk?= <325140@mail.muni.cz>
> From: =?UTF-8?B?SmFrdWIgSG9sb3TDrWs=?= <325140@mail.muni.cz>
> From: "Jakub =?UTF-8?Q?Holot=C3=ADk?=" <325140@mail.muni.cz>
(copy the mail to local mail folder, edit mail folder file, restart Tb, rebuild-index)

Do you use add-on? If yes, what?
Can you reproduce your problem with -safe-mode or new profile?

Another concern.
Your test mail doesn't have null-line after mail heder lines and mail body line. This may affect on your test. Test with normal mail data, even though manually crafted mail data.
And, check with minimum mail headers(Received: header, X-... header, ..., can be removed) to make problem isolation easier.
(In reply to comment #20)
> I don't care if the problem is not actually caused by the 8bit encoding.

I see. I call mail that produces your problem "8bit" and mail that doesn't produce your problem "7bit", as you call so, because what is cuase/difference is still not found.
(Reporter)

Comment 23

8 years ago
> Your test mail doesn't have null-line after mail heder lines and mail body
> line. This may affect on your test. Test with normal mail data, even though
> manually crafted mail data.

This is normal mail data. The mail is exactly as I received it and stored using Thunderbird. Does that mean that the email is malformed?
(In reply to comment #23)
> > Your test mail doesn't have null-line after mail heder lines and mail body
> > line. This may affect on your test. Test with normal mail data, even though
> > manually crafted mail data.
> This is normal mail data. The mail is exactly as I received it and stored using Thunderbird.
> Does that mean that the email is malformed?

I can't say "malformed mail", because I don't know RFC or spec of software well. But, it may be relevant to your problem, because you look to check with IMAP mail folder(no X-Mozilla-Status:/X-Mozilla-Status2: in the attached 8bit mail).
I tested by next, so null line after mail headers is added by Tb as required,
  1. Save the attached 8bit mail as ...eml.
  2. Drag&Drop the .eml file to a local mail folder by Tb 3.
    (Tb3 nightly supports import of .eml by Drag&Drop of .eml on mail folder.)
and I can't reproduce your problem with Tb3 nightly on MS-Win-XP, with no add-on.
(In reply to comment #24)
> (In reply to comment #23)
> > > Your test mail doesn't have null-line after mail heder lines and mail body
> > > line. This may affect on your test. Test with normal mail data, even though
> > > manually crafted mail data.
> > This is normal mail data. The mail is exactly as I received it and stored using Thunderbird.
> > Does that mean that the email is malformed?
> 
> I can't say "malformed mail", because I don't know RFC or spec of software
> well. But, it may be relevant to your problem, because you look to check with

RFC says (see http://tools.ietf.org/html/rfc2822#section-2.1) : 
"   A message consists of header fields (collectively called "the header
   of the message") followed, optionally, by a body.  The header is a
   sequence of lines of characters with special syntax as defined in
   this standard. The body is simply a sequence of characters that
   follows the header and is separated from the header by an empty line
   (i.e., a line with nothing preceding the CRLF).
"
(In reply to comment #25)
> RFC says (see http://tools.ietf.org/html/rfc2822#section-2.1) : (snip)

Ludovic, thanks for pointing RFC. Mail data itself never violates RFC 2022, but I don't know behavior of Mail server and Tb when next case...
  Last mail header doesn't have following [CRLF],
  or mail server doesn't send [CRLF] after last mail header.
  (AFAIR, I saw a bug report for such case, I'm not sure though.)
As Tb uses Unix Mbox format for local mail folder, offline-store file of IMAP folder, and Disk-Cache for IMAP mail by Tb 3(perhaps), and as Unix Mbox file handling is affected by existence of [CRLF] at special position, I can say nothing about "no null line or no [CRLF] after last mail header" case.

Simon Toth(bug opener), can you check "local mail folder" case with no add-on(difference from my test is SUSE or MS-Win only) with sufficient null line([CRLF]) in local mail folder?
(Reporter)

Comment 27

8 years ago
Very interesting.

* if I move the email around IMAP folders, the reply keeps being created incorrectly
* if I move or copy the email to local folders the copy generates a correct reply
* if I move the email back to IMAP from the local folder, the reply is still being created correctly
* even if I erase the local cache of the folder
* there is a new empty line on the end of the mail (after the copy/move)

Btw. from the RFC IMHO it means that the newline needs to be there only when body is present, and body is optional. Therefore I think this is still a Thunderbird bug.
Simon Toth, can you check next.

Create an IMAP folder of same account. At folder properties, disable offline use(Synchronization setting). Copy the 8bit mail to the new folder.
(Q1) Is problem reproduced at the new mail folder?
     (you stated "problem persisted after move".)

Enable offline use of the folder, copy another mail to the folder, rebuild-index(force re-download), click other folder then click the folder again to show thread pane. 
Check offline store file(file of folder name, not ...msf) content.
Two mails are separated by "From " line in offline store file.
(Q2) Is there null line before second "From " line for second mail?
(Q3) Does problem occur with first 8bit mail?

> Therefore I think this is still a Thunderbird bug. 

When local mail folder(unix mbox), if null line after last mail header(and all mail body lines) is manually removed, Tb ignores mail data of no null line.
  From - ...[CRLF]
  Subject: mail-1[CRLF]
  From - ...[CRLF]
  Subject: mail-2[CRLF]
  [CRLF] <= null line
Only "mail-2" is displayed as living mail.
Null line is probably required in unix mbox hadling by Tb. So Tb always adds null line if no null line, when adding mail data to an unix mbox file.
IMAP mail handing may be affected by such null line handling by Tb.
Summary: Reply-to-all not created correctly for 8bit encoded emails → Reply-to-all not created correctly for mail in IMAP folder, if mail has no null-line, no mail-body-line
(Reporter)

Comment 29

8 years ago
(Q1) Yes, still the same.
(Q2) Yes
(Q3) After reselecting download, re-indexing, and switching the folders, reply-to-all works correctly

Interestingly, reselecting download and re-indexing does not help the original folder. It seems that emails are only fixed if they are manually copied.
(Reporter)

Comment 30

8 years ago
And the original folder does not contain null lines between emails. The original mailbox on the server does contain newlines between emails.
(In reply to comment #30)
> And the original folder does not contain null lines between emails. The
> original mailbox on the server does contain newlines between emails.

What kind of server are you talking to ?
Component: Message Compose Window → Networking: IMAP
Product: Thunderbird → MailNews Core
QA Contact: message-compose → networking.imap
Version: 3.0 → 1.9.1 Branch
(Reporter)

Comment 32

8 years ago
Procmail for mail delivery and I think dovecot 1.1.20 for IMAP? I have only a user shell on the system.
(Reporter)

Comment 33

8 years ago
I think this is the same issue that I'm experiencing with another Gmail, where it manifests itself by creating huge offline files that cannot be compacted.

See: https://bugzilla.mozilla.org/process_bug.cgi

I can confirm that Gmail folders have no newlines between emails as well.
(Reporter)

Comment 34

8 years ago
It seems, that my description for this bug was unclear. Thunderbird only adds the null-line when the email is moved to a local folder, not an offline imap folder on the same account! If the mail is moved between folders of the account, no null-line is added (and this is true for any email, including those with body).
(In reply to comment #34)

Simon Toth, we are not talking about null line at end of mail body. We are not talking about mail with mail body. 
We are talking about null line after last message header line(separator of mail header and mail payload). We are talking about message header only mail(no null line as separator of mail header and mail payload, no mail payload/mail body).
(Reporter)

Comment 36

8 years ago
OK, but then its not true, because the null line is missing between emails, not after header. OK, if the mail is only header with no body, there will be now null line after header, because there is no null line between emails.
(Reporter)

Comment 37

8 years ago
Still present in the latest stable (and its extremely annoying).

What I do now to prevent this bug from manifesting is to move all the mail from the folder I'm going to work with to a local folder and then back again (this adds the required null line between emails), I would be very grateful for a more elegant and permanent solution.
(In reply to comment #37)
> Still present in the latest stable (and its extremely annoying).

What is your purpose of mail header only mail(Subject: only)?
> Subject: [cpp][cvic09][xholotik][odevzdani]
Shortest mail from mobile phone?
Or you are victim of special spam? (DoS like attack to Tb...) If so, why Reply-All is required...
Or a kind of alert or notification from system to you? (next Received: is seen)
> Received: by sender-daemon@arethusa1.fi.muni.cz

By the way, as you already knew by comment #29, "offline use=on" is a workaround, if mail folder size is far smaller than 2GB limit.
(Read bug 532323 and bug 537498, please.)
Summary: Reply-to-all not created correctly for mail in IMAP folder, if mail has no null-line, no mail-body-line → Reply-to-all not created correctly for mail in IMAP folder, if mail has no null-line, no mail-body-line (IMAP folder of offline use=off only)
(Reporter)

Comment 39

8 years ago
> Or a kind of alert or notification

You could say its a notification, but not machine generated, those emails are sent by students. They are homework check requests. We require all the information we need in the subject line, so we can easily sort and process these emails.

Plus I do send header only emails to myself from various sources (mobile, command line, etc...), mostly reminders.

> By the way, as you already knew by comment #29, 
> "offline use=on" is a workaround

It's not. Emails have to be moved to a local folder (non-imap) to be fixed. As soon as they are moved to a local folder a new empty line is appended and kept even when they are moved back to the imap folder. Setting offline, or moving the emails to a folder with offline enabled (in the same account) does not work.

The mail folder size doesn't even approach GB sizes. Its usually somewhere around 1-10MB.
(In reply to comment #39)
> those emails are sent by students. They are homework check requests.

Gotcha. Instant messaging like use of E-mail...

> > By the way, as you already knew by comment #29, 
> > "offline use=on" is a workaround
> It's not. Emails have to be moved to a local folder (non-imap) to be fixed.

You said that problem didn't occur when you did next in comment #29, didn't you?
  copy the mail from IMAP Inbox to IMAP folder of offline use=on.
  (rebuild-index was for forcing download of whole mail data to offline-store,)
  (in order not to misunderstand test results.) 
I misunderstood?
You alreay set "offline use=on" for Inbox? (Folder Properties/Synchronization)
(upon upgrade to Tb3, "offline use=on" of all IMAP folder is set by Tb3.)
Or your IMAP server puts null line upon "uid xxx copy Target-folder"?
(Reporter)

Comment 41

8 years ago
> Gotcha. Instant messaging like use of E-mail...

What? I fail to see the parallel. Or you just imply short email=>IM?

> You said that problem didn't occur when you did next in comment #29, 
> didn't you?

No. By "and switching the folders" I meant "move mail to local folder, move back".

> copy the mail from IMAP Inbox to IMAP folder of offline use=on.

I completely lost in this bug. Now moving to another folder within the same account seems to work. The original folder does have offline use selected, but new emails still contain this bug.

I will try to determine if just using reindex on the original folder helps.

Anyway It would still be nice if I wouldn't have to use email moving (or reindex) and emails would be simply downloaded correctly in the first place.
(In reply to comment #41)
> What? I fail to see the parallel. Or you just imply short email=>IM?

I wanted to say by IM; 
  very short text exchange like "pager message by telephone carrier",
  on "E-mail system based on Internet, using SMTP, POP3, IMAP".
  Other than From: and Subject: is not needed for you.

Do you use Gmail IMAP? Does your problem occur with Gmail IMAP?
If yes, can you(or your student) send header only mail to me?
   To: yatter.one@gmail.com
(I'm unable to send such mail using Mozilla family, Tb/Sm.)
(Reporter)

Comment 43

8 years ago
> Do you use Gmail IMAP? Does your problem occur with Gmail IMAP?

No this is not GMail. This is Masaryk university IMAP server.

If you want an email without body, just create a plaintext email in TB with no signature, etc... It will have no body, only header. The difference is that TB does add the empty line to every email even if it doesn't have a body.

I'm not sure if not having an empty line after headers is OK (the RFC requests it as a separator between body [which is optional] and the headers).

I would like to get some final statement regarding the missing empty line. Either you consider it valid and it will be fixed, or no, and then I will point my hand at you and go complaining to the university information system developers.
(Reporter)

Comment 44

8 years ago
> If yes, can you(or your student) send header only mail to me?
>    To: yatter.one@gmail.com

I did send it anyway Subj: "Header only email"
(In reply to comment #43)
> I'm not sure if not having an empty line after headers is OK
> (the RFC requests it as a separator between body [which is optional] and the headers).

As written by RFC pasted in Comment #25, "separator"(null line) is not included in "header", and "body" is optional. I believe interpretation like next is correct.
  If optional "body" is attached, the body should be separated by
  "separator"(null line) from "header".
  i.e. If no optional "body", there is no need of null line after "header". 
If not, I think many IMAP/POP3 servers rejected such mail.
(In reply to comment #44)
> I did send it anyway Subj: "Header only email"

Last part of arrived header-only-mail at Gmail.
> Date: Mon, 15 Mar 2010 11:07:17 +0100[CRLF]
> X-ISMU-Expires: 2011-03-15[CRLF]
> [CRLF]
Gmail/Gmail IMAP passed null line after mail header to Tb, so it's impossible to reproduce problem using Gmail IMAP. Behaviour of your IMAP server is relevant.
If "Inbox of your IMAP server" only issue, move/copy by message filter is a workaround.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Reply-to-all not created correctly for mail in IMAP folder, if mail has no null-line, no mail-body-line (IMAP folder of offline use=off only) → Reply-to-all not created correctly for mail in IMAP folder, if mail has no null-line, no mail-body-line

Comment 47

7 years ago
no activity for a long time, should be closed
You need to log in before you can comment on or make changes to this bug.