Re: RFC3030

Sam Varshavchik <[email protected]> Thu, 07 Aug 2025 18:51:55 -0400
Newsgroups	gmane.mail.imap.courier.general
Message-ID	<[email protected]>
JLX2 writes:

>> Well, I don't know what you checked, but there's nothing in IMAP4rev1 that  
>> implements MIME decoding on the server side, to permit binary downloads of  
>> decoded MIME attachments. What did you check, specifically? 
>
>  
> <URL:https://datatracker.ietf.org/doc/html/rfc3501#section-4.3.1>https://data 
> tracker.ietf.org/doc/html/rfc3501#section-4.3.1

I direct your attention to the first sentence of the second paragraph.

"Although a BINARY body encoding is defined, unencoded binary strings are  
not permitted.", followed by a few immaterial clarifications.

This effectively prohibits the IMAP server from decoding binary base64  
content, and transmitting it, decoded.

It is not allowed.

Period.

Full stop.

It is not going to happen.

> no there is nothing that says that the imap server HAS TO decode the message  
> on the server side, but nothing that says that it CAN NOT. (even if it's more  
> something that should be done on reception of the SMTP server) 

Yes, it does. See above.

> the imap protocol permit binary transmission from roots, not like the smtp  
> protocol that enforced 7 bit ascii

Sorry, you're mistaken. All references to 8-bit content in RFC 3501 refer to  
text, not binary.

>> I'm sorry, but I find this very, very hard to agree with: that email is  
>> dying because of the need to base64-encode binary attachments. 
>
> so tell, me, what is inconvenience in email that whatsapp has?

One word: idiocracy.

Any email client on has to install must have at least some level of  
configuration and setup. This is not needed with whatapp, facebook, and the  
rest. And idiocracy takes care of the rest.

> write email or documents in old no more written runic...) NKo.... ok, the  
> most used char are... at the end of unicode... I wonder what it do going  
> through base64? so 60% overhead introduced by UTF-8, that maps nowhere inside  
> the base64 range, so adding 33% overhead because recoded into base64...  
> LOL....  112.8% overhead... LOL versus 0 if sent in 16bit content... nice,  
> you don't find, don't you?

Nobody in their right mind will base64-encode UTF-8 text. That's utterly  
dumb. It gets declared as "Content-Transfer-Encoding: 8bit", and everyone's  
happy.

I have occasionally seen some Microsoft client being trigger happy and  
base64-encoding regular plain text content, for no good reason, but that's  
an exception to the rule.

And nothing stops anyone from declaring, say, "charset=koi8-r" or  
"charset=iso-2022-jp", and together with Content-Transfer-Encoding: 8bit get  
the best of both worlds.

_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
signature.asc (application/pgp-signature, 228 B)