Re: RFC3030

Sam Varshavchik <[email protected]> Sun, 03 Aug 2025 11:05:44 -0400
Newsgroups	gmane.mail.imap.courier.general
Message-ID	<[email protected]>
JLX2 writes:

> but no reference about RFC3030, BINARYMIME and more I find too bad that there  
> is an "automatic convertion" : is the conversion performed even if the remote  
> relay/final SMTP server support RFC3030 and BINARYMIME?

Correct. But it would be somewhat strange if such a server does not  
advertize 8BITMIME, which will forego the need for Courier to do any  
conversion.

> one of the things that I find more problematic on today email is the base64  
> overhead : it consume lot of bandwidth, quota on imap servers and on disk,  
> without possibility to reduce the overhead (compression) on most part of  
> transmission/storage (only local copy can be compressed, imap shall not be so  
> consuming quota, transmission neither)

I don't hear many discussions about insufficient bandwidth or storage. In  
fact this is the first time in decades this is mentioned, to my  
recollection. Bandwidth and storage get cheaper every year, and every year  
it's generally becomes less and less of an issue.

> RFC1830 was published in 1995, obsoleted in 2000 by rfc3030, so it's 20 years  
> that emails should be transferred in binary form and should have dropped the  
> base64, and that smtp server should be able to revert the base64 when  
> communicating with rfc3030 compliant server (with the only exception of PGP  
> signed/encrypted messages, since they enforced that the signing occurs AFTER  
> 7bit conversion) 

Courier is somewhat older than 20 years, and mail servers are only one link  
in the chain of agents that handle E-mail. To be served via POP3 or IMAP the  
mail has to be presented in its classical, text-only form. There might be an  
equivalent alternative in IMAP4rev2, but I haven't bothered to investigate.  
Everyone and their mother speaks IMAP4rev1, and it's good enough for  
everyone.

Furthermore, on Linux everything else also expects mail to be formatted in  
its classical RFC 2?822 format. Try pointing Thunderbird at some binary goo,  
you're not going to get very far. procmail or maildrop will just laugh at  
you. There is no binary goo to be found in mboxes or maildirs.  
Realistically, end-to-end binary E-mail content is only feasible with an E- 
mail equivalent of systemd. One beast handling mail from start to finish.  
From RFC 2?821 to IMAP4 only (pretty sure there's no binary-only version of  
POP3).

> my question is was is done/supported on courrier-mta? regarding BINARYMIME?

There is none at this time, and it's not on my immediate roadmap. I have  
nothing against it, and if someone were to write a high quality patch I'll  
certainly look at it and give it a fair shake, but it's simply not worth any  
of my own time to hack at it. I see absolutely no cost/value benefit to  
something like this, at all. Courier's internal mail queue is a simple set  
of flat files, with a message in a single file, and pushing it to a SMTP  
peer is a no-brainer. That leaves two stark choices. Either rewrite the  
internal mail queue handling code entirely, and for what solely for the  
possible benefit of, what? Just possible binary SMTP delivery, but still  
have to reassemble everything into a single MIME message otherwise, or when  
delivering to a local mailbox? Or keep everything the way it's now and  
convert between to/from binary when talking 8BITMIME? I just don't see it  
being worth it.

It's time to be realistic. I've yet to see any real world benchmarking that  
shows BINARYMIME to make any material difference. And, servers that brag  
about having BINARYMIME are forced to support classical MIME, too. If they  
refuse they have no reason to expect to succesfully deliver all email to:

mx.google.com (Gmail)
yahoo.com
icloud.com

and so on. That wouldn't be a useful mail server.

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