Automatically detecting if plain text is flowed or fixed

[Tblue]

Hello,

I'm using AquaMail Pro 1.7.1-88 (from the Play Store) and like it a lot. I miss a small thing, though:

Currently, I can force AquaMail to either decode all plain text mails as flowed plain text or to decode all plain text mails as fixed, non-flowed text (see Settings -> Mail, other -> Flowed text). This also affects composing.

Would it be possible to get an option to let AquaMail automatically determine whether a plain-text mail should be decoded as flowed plain text or as fixed plain text? This could be done by inspecting the Content-Type header: If the content type is text/plain and the format=flowed parameter is present, then decode as flowed plain text, otherwise (if the format parameter is not present or set to fixed) decode as fixed (non-flowed) plain text.

Additionally, it would be useful to have an option that makes AquaMail encode all text as flowed plain text when composing a plain-text mail.

Use case: I get plain-text notifications that are encoded as fixed plain text (actually Content-Type: text/plain without a format parameter). Forcibly decoding them as flowed text makes them hard to read (since e. g. leading spaces in a line are wrongly interpreted as "space stuffing"). I can switch off the "Flowed text" option mentioned above, but then not even plain-text messages with a format=flowed parameter in the Content-Type header are decoded as flowed text. Also, with the "Flowed text" option disabled, plain-text mails I send don't look very good on large screens since they get encoded as fixed plain text and thus their lines forcibly get "hard-wrapped" at 72 characters or so.

To sum it up, I would find it very useful if there were separate options to make AquaMail...

• ...respect the Content-Type header when deciding whether to decode plain text mails as flowed or fixed plain text.
• ...always encode plain-text mails I compose as flowed text.

Or is this maybe even already possible and I have just overlooked the relevant option(s)?

Thanks for any comments! 

[Kostya Vasilyev]

Re: Use case: I get plain-text notifications that are encoded as fixed plain text

Those messages must also have trailing spaces (for the stuffing logic to trigger).

Sorry there is no setting like this right now, I'm also not sure if all mail servers (IMAP, and especially Exchange) would be able to return the additional "flowed" parameter to the app (Aqua Mail does not fetch messages in the original MIME format except when using POP3 where it's the only option).

I'll write it down to investigate.

[Tblue]

Re: Use case: I get plain-text notifications that are encoded as fixed plain text

Those messages must also have trailing spaces (for the stuffing logic to trigger).

Ah, interesting. I will look into that -- maybe I can format the notification in a way that does not trigger that logic, then.

Sorry there is no setting like this right now, I'm also not sure if all mail servers (IMAP, and especially Exchange) would be able to return the additional "flowed" parameter to the app (Aqua Mail does not fetch messages in the original MIME format except when using POP3 where it's the only option).

I don't know about Exchange, but I'm using IMAP and can see the Content-Type header with the format=flowed parameter when I view the message headers in AquaMail; that's why I thought that AquaMail could just check that header.

I'll write it down to investigate.

Thanks!

[Tblue]

Re: Use case: I get plain-text notifications that are encoded as fixed plain text

Those messages must also have trailing spaces (for the stuffing logic to trigger).

Ah, interesting. I will look into that -- maybe I can format the notification in a way that does not trigger that logic, then.

All right, the relevant (raw/undecoded) part of the problematic message I was talking about looks like this:

Pakete, von denen ein Upgrade durchgef=C3=BChrt wurde:
 apt apt-utils libapt-inst1.5 libapt-pkg4.12 php5-cgi php5-cli=20
 php5-common php5-curl php5-fpm php5-gd php5-imap php5-intl=20
 php5-mcrypt php5-mysqlnd php5-pgsql=20

As one can see, three of the lines do actually end with a ("quoted-printable"-encoded) space character. I removed those space characters, but that did not help -- the spaces at the beginnings of the three lines still get removed by AquaMail when the "Flowed text" option is enabled. According to RFC 3676, section 4.1 (I would link it, but I don't seem to have made enough posts yet in order to include external links in my messages), this is actually the correct behaviour:

If the first character of a line is a space, the line has been space-stuffed (see Section 4.4). Logically, this leading space is deleted before examining the line further (that is, before checking for flowed).

If the line ends in a space, the line is flowed. [...]

So it looks like AquaMail does the right thing -- it's just that it indeed treats all plain-text messages as flowed plain text when the "Flowed text" option is enabled, even if they are not.

[Kostya Vasilyev]

Re: the spaces at the beginnings of the three lines still get removed by AquaMail when the "Flowed text" option is enabled.

Um, sorry, It's been a while since I look at that code, might have forgotten.

Checked it now, yes, the leading space is removed regardless.

I believe you're right, it is supposed to work this way -- it has to do with encoding, but I can't remember the exact reason.

---

I have written it down to see if it's possible to get the "flowed" header marker and only do flowed decoding then.

[Tblue]

I have written it down to see if it's possible to get the "flowed" header marker and only do flowed decoding then.

Thank you.