Re: client support for RFC 3516 (BINARY) ?

On Friday, 19 December 2014 20:58:03 CEST, Lyndon Nerenberg wrote:
> As a purist I would argue the IMAP server should never have 
> accepted the message to begin with

At the time you do it, your users won't be able to receive mail from the 
Linux Kernel Mailing Lists. (Actually, just a random portion of these 
e-mails when the original MUA decided to use the base64 CTE. That's gonna 
be fun.)

The vger's configuration is of course broken, and unfortunately I've been 
forwarded a message where they said that they aren't going to fix this 
after 20 years of operation. I believe Linus has a word for this attitude.

>> Additionally, it might be useful to add implementation note 
>> that a client should fallback to using FETCH BODY[] if the 
>> server returns NO.  The MUA that the original reporter is using 
>> (I don't know what it is) is simply showing a blank body for 
>> these kind of messages when a FETCH BINARY[] is unsuccessful.

I'm not sure whether you received that report from the same user as I did. 
If that is the case, the MUA is Trojita and there was a bug where the error 
in FETCH operation wasn't propagated to the GUI in a clear manner, but a 
spinner was kept running. It now at least shows an error message.

> This is so stunningly obvious it doesn't deserve mentioning.

Is it? There are just two widely used CTEs which require decoding, the 
base64 and the quoted-printable, and RFC2045 contains a pretty strong 
language against developing any additional CTEs.

Is there a realistic assumption that there's an IMAP server which:

- declares support for BINARY,
- cannot decode base64 or quoted-printable encoding,
- can handle that situation gracefully, without crashing,
- and client's local decoder would be able to cope with the malformed 
content?

By all means, sure, it will improve robustness to retry with a FETCH after 
a BINARY failed. I'm just saying that it was sufficiently non-obvious at 
the time I added BINARY support, and even now I have my doubts on whether 
my local decoder is going to be any better than e.g. Dovecot's.

On a quick look at its source, the decoder library which Trojita uses (Qt's 
QByteArray::fromBase64) appears to handle garbage in base64 data in 
accordance with RFC2045 which calls for ignoring any character that cannot 
be decoded. It doesn't appear to have any special handling of the == 
padding, which is in strong constrast to Python where the base64 module 
stops decoding when it hits the first padding. I wonder which approach is 
better.

With kind regards,
Jan

-- 
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

_______________________________________________
imapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imapext