Headers spilling into the message (1.5.5.34)

[StR]

Kostya,

It is the first time that I see it happening like this.
I don't know if it is just a coincidence or the newer version is at fault (it happened after I updated to 1.5.5.34 from Google Play).

Synopsis: a message has a few partial headers at the top of the message body:

tatus: O
X-Status: X-Keywords: X-UID: 29749

(exactly like that, without the "S" at the beginning, and without line breaks between the rest.)


On the server side I can see the "raw" message (with a less command), and there is nothing wrong there.
Also, other e-mail programs (alpine) doesn't have any problem with this message.

Here are the headers that appear at the bottom of the headers:

X-Mailer: iPhone Mail (10B350)
In-Reply-To: <alpine.BSF.2.00.1505090140350.93404@MYHOST>
Message-Id: <NUMBER@gmail.com>
Date: Sat, 9 May 2015 21:13:21 +0500
To: NAME <MY ACCOUNT>
Mime-Version: 1.0 (1.0)
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
        RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on MYHOST
X-Virus-Scanned: clamav-milter 0.98.1 at MYHOST
X-Virus-Status: Clean
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by MYHOST id t49GIT2c055457
Status: O
X-Status:
X-Keywords:
X-UID: 29749

When in in Aquamail I do "View -> Headers", it shows all the headers up to "X-MIM-Autoconverted..." line, including it.


Since this is a single occurrence so far, I can just disregard it as a glitch for now.
But if you want me to do something that might help you debugging it, let me know.

One thing that I thought about it is what would be the way to force Aquamail to re-download all [within the age period] e-mails in this (incoming) mailbox for this account without deleting and resetting the account? I would be curious to see if upon rereading messages, Aquamail would treat this message correctly. (Something that is similar to Thunderbird's "repair" the mailbox.)


PS. Just in case: UW-imap is running on the server.

[Kostya Vasilyev]

Sounds like a server bug wrt. message parsing.

AquaMail uses (a standard) IMAP feature where a mail app can ask the server to break a message down into parts, and then ask for specific MIME parts.

Not all mail apps are like that -- many will download full messages and then break them into parts themselves (this of course makes it impossible to download just message text and not attachments, if so desired by the user).

If you'd like to investigate:

- Enable logging with "raw session data"
- Open this message
- Menu -> "Diag: reload"

The above will capture what the server returns for message structure and message data.

You can send the log to kmansoft / gmail. Thanks.

[StR]

Yes, it makes sense.
I don't know why the server started doing this all of a sudden, but I suspect it might be somehow related how UW-imap server deals with the locking for the concurrently connecting clients.

I just had yet another message showing up exactly in the same way.
So, I decided to enable logging and did diag:reload.
The message reloaded without a problem. And I looked through the logs and didn't find anything abnormal.

However, I encountered a minor bug in the process: even though the message has reloaded, the information about the message, namely the first line, in the message list has not refreshed.
(That line actually contains: "tatus: O  X-Status: ...
You might want to fix that in one of the subsequent releases.


Also, if I may suggest the following functionality: to be able to re-download a particular mailbox (folder), including INBOX. (Something that is similar to Thunderbird's "Repair Folder" (under Folder Properties -> General Information [tab]).)
This would allow people to refresh the inbox in case there was a previous glitch (with the message index, corrupted mailbox or whatever).

Reloading of an individual message (similar to diag:reload, but without enabling debug/logging) might also be helpful, even if used very infrequently.

[Kostya Vasilyev]

Reloading is for debugging, really...