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

Status: NEW

(MailNews Core :: Networking: IMAP, defect)

Description

[Simon Toth]

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

Comment 1

[Simon Toth]

Attachment: 8bit email example

Comment 2

[WADA:World Anti-bad-Duping Agency]

(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: <[e-mail]>
> From: Jakub =?UTF-8?Q?Holot=C3=ADk?= <[e-mail]>
Which mail header(s) do you mean by your "both sender and the mailing list address"? Received: header?

Comment 3

[Simon Toth]

> I can't find other than next headers for candidate of To: or CC: upon reply in
> mail data you attached.
> > Return-Path: <[e-mail]>
> > From: Jakub =?UTF-8?Q?Holot=C3=ADk?= <[e-mail]>
> 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 [e-mail] and [e-mail] (actually not mailing list but a group address).

It always works correctly if the email is 7bit encoded. [e-mail] is selected as To: and [e-mail] as CC:.

Comment 4

[Simon Toth]

To clarify.

I have 75 people sending approx. 2 emails each week to this address ([e-mail]). 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).

Comment 5

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #3)
> The Reply-To-All email should be addressed to both [e-mail] and
> [e-mail] (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 "[e-mail]".
Are you talking about "To: [e-mail]"?
> X-Original-To: [e-mail]
> 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 <[e-mail]>; 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 <[e-mail]>; Wed, 2 Dec 2009 11:05:55 +0100
> Received: by [e-mail]
>  PID 19719 for [e-mail]@mail.muni.cz; Wed, 02 Dec 2009 11:05:54 +0100
> To: [e-mail]
> Message-ID: <[e-mail]>

> [e-mail] (actually not mailing list but a group address).

What syntax/sematics do you mean by your "mailing list" and/or "group address"?
Both [e-mail] and [e-mail] look for me ordinal/traditonal mail address...

Comment 6

[Simon Toth]

[e-mail] 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 [e-mail], or [e-mail]).

Comment 7

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #6)
> [e-mail] 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
> [e-mail], or [e-mail]).

How can an MUA(mail user agent==mail cilent, Tb is an MUA) know string of "[e-mail]" 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)?

Comment 8

[Simon Toth]

> How can an MUA(mail user agent==mail cilent, Tb is an MUA) know string of
> "[e-mail]" 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.

Comment 9

[WADA:World Anti-bad-Duping Agency]

(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?= <[e-mail]>
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 <[e-mail]>
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?

Comment 10

[Simon Toth]

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: [e-mail]" and "To: [e-mail]".

Now, when I hit reply-to-all, it is correctly formed with "To: [e-mail]" and "Cc: [e-mail]" UNLESS the email is in 8bit encoding in which case it fails, and only creates the reply-to-all with the "To: [e-mail]" 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).

Comment 11

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #10)
> The email will contain headers "From: [e-mail]" and "To: [e-mail]".
> 
> Now, when I hit reply-to-all, it is correctly formed with
> "To: [e-mail]" and "Cc: [e-mail]"
> UNLESS the email is in 8bit encoding in which case it fails,
> and only creates the reply-to-all with the "To: [e-mail]" field and ignores the "pb161extra@fi".

Why "Cc: [e-mail]" is put by Reply-All, even though your mail address of [e-mail] 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 [e-mail] defined?

Comment 12

[Simon Toth]

> Why "Cc: [e-mail]" is put by Reply-All, even though your mail
> address of [e-mail] 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 [e-mail] defined?

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

Comment 13

[Simon Toth]

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

Comment 14

[Simon Toth]

So what? Are you finally willing to admit that it's not behaving as it should?

Comment 15

[WADA:World Anti-bad-Duping Agency]

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

Comment 16

[Simon Toth]

Attachment: Email generated by reply-to-all

Comment 17

[Simon Toth]

Attachment: 7bit email example

Comment 18

[Simon Toth]

Attachment: Email generated by reply-to-all for the 7bit email

Comment 19

[Simon Toth]

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 [e-mail] (which should be completely irrelevant) and once again [e-mail] is not defined in any identity as I already said in this post https://bugzilla.mozilla.org/show_bug.cgi?id=532360#c12

Comment 20

[Simon Toth]

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!

Comment 21

[WADA:World Anti-bad-Duping Agency]

Affected by next difference in your environment?
> (attached 8bit mail => no CC: is generated)
> From: Jakub =?UTF-8?Q?Holot=C3=ADk?= <[e-mail]>
> (attached 7bit mail => CC: is generated)
> From: =?ISO-8859-2?Q?Igor_Krn=E1=E8?= <[e-mail]>

Can you check next 3 cases?
> From: =?UTF-8?Q?Jakub=20Holot=C3=ADk?= <[e-mail]>
> From: =?UTF-8?B?SmFrdWIgSG9sb3TDrWs=?= <[e-mail]>
> From: "Jakub =?UTF-8?Q?Holot=C3=ADk?=" <[e-mail]>
(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.

Comment 22

[WADA:World Anti-bad-Duping Agency]

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

Comment 23

[Simon Toth]

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

Comment 24

[WADA:World Anti-bad-Duping Agency]

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

Comment 25

[Ludovic Hirlimann [:Usul]]

(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).
"

Comment 26

[WADA:World Anti-bad-Duping Agency]

(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?

Comment 27

[Simon Toth]

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.

Comment 28

[WADA:World Anti-bad-Duping Agency]

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.

Comment 29

[Simon Toth]

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

Comment 30

[Simon Toth]

And the original folder does not contain null lines between emails. The original mailbox on the server does contain newlines between emails.

Comment 31

[Ludovic Hirlimann [:Usul]]

(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 ?

Comment 32

[Simon Toth]

Procmail for mail delivery and I think dovecot 1.1.20 for IMAP? I have only a user shell on the system.

Comment 33

[Simon Toth]

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.

Comment 34

[Simon Toth]

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

Comment 35

[WADA:World Anti-bad-Duping Agency]

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

Comment 36

[Simon Toth]

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.

Comment 37

[Simon Toth]

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.

Comment 38

[WADA:World Anti-bad-Duping Agency]

(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 [e-mail]

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

Comment 39

[Simon Toth]

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

Comment 40

[WADA:World Anti-bad-Duping Agency]

(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"?

Comment 41

[Simon Toth]

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

Comment 42

[WADA:World Anti-bad-Duping Agency]

(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: [e-mail]
(I'm unable to send such mail using Mozilla family, Tb/Sm.)

Comment 43

[Simon Toth]

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

Comment 44

[Simon Toth]

> If yes, can you(or your student) send header only mail to me?
>    To: [e-mail]

I did send it anyway Subj: "Header only email"

Comment 45

[WADA:World Anti-bad-Duping Agency]

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

Comment 46

[WADA:World Anti-bad-Duping Agency]

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

Comment 47

[Thommie Rother]

no activity for a long time, should be closed

Comment 48

[gene smith]

Sound like maybe related to 8BITMIME smtp capability that tb now supports. Recent problems with it have been yahoo and maybe aol advertising it as "8 BITMIME" which is not the right string.