Re: RFC3030

Le 03/08/2025 à 17:05, Sam Varshavchik a écrit :
> 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.
sorry, but I don't understand the answer... " which will forego the need 
for Courier to do any conversion" => let me think that if the other smtp 
server advertize 8BITMIME, there won't be any conversion? (but "Correct" 
let me think that there will be conversion whatever the remote server 
features)
>
>> 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.

well for me it is... just go on some trip in some "poor" country... and 
buy a card with 1GB of data... and look how fast it goes with just 
syncing emails... and it's the same on my disk, or my storage quota... 
yes it's cheaper and cheaper, but it also require to jam your old 
working computer because the storage isn't sold anymore or at 
prohibitive price... it's not because you have supercomputer that others 
need to... just try to send some email on a 2G network, or on trip on 
some slow connection... just add a few photos (even resized) just to 
keep family informed... when it fails 10 times because the remote server 
just decide you're too slow at 50% (of course not saying, so at first 
you think that it's a connection issue, but since it reproduce each time 
at about the same size, you just try to reduce it to match the size... 
and miracle, it works...), you end saying "if there wasn't that dawn 
base64 overhead, it will have passed"

I really hate this argument, because it's just consumerism. at the end, 
we have supercomputer that go as fast as i486... and do nothing more.

>
>> 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.
IMAP handle binary, I just checked... it was designed a bit older and 
then didn't suffer the initial design of "7bit ASCII", and pop3 is less 
and less used....
>
> 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).

don't see what systemd is going in the way... with today RFC state, 
there is way to communicate and perform conversion so that it's 
efficient... any stmp server can see if the remote is able to send in 
binary, and re-encode on the fly if not, and same decode on the fly... 
don't know about the clients, but it's also because nobody try to 
improve... if someday there is BINARYMIME reaching the client, there 
will be a bug filled and a fix at a time... and step after step, it will 
the standard... even postfix implemented part of rfc3030 because email 
client tried to use BDAT commands (CHUNK) and also did PIPELINING to 
avoid slow ping-pong... they didn't handle BINARYMIME because the 
internal is line oriented (rather than file oriented)

what's strange is that if I correctly remember maildrop is proud of not 
using pipe for communication but files, so there is no need to bother 
about lines or buffer.. an mmaped file is much more efficient... and 
supported since ages on almost all system (at least UNIX, windows and 
bsd and their derivatives) so two cases

  * has to go under attachement processing => need to reverse the
    encoding to have the attachement in processable form
  * don't care about the attachement => just has to wait for boundary
    delimiter and don't care what it process byte after byte....


>
>> 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.

well it's a point, but ask yourself why people are moving from email to 
whattsapp and the like proprietary communication network...

they moved because on such network you can send images, videos, and not 
beeing refused because of space... so you don't have to make 10 emails 
to send video of vacation, photos and other stuff... today you can 
achieve the same with current stmp email restriction IF they weren't the 
base64 overhead... but since you have the overhead you can't... someday 
the email will just dye because nobody will use it anymore, just because 
of such limitation.

For work purpose, I have to be sure that the clients get manual, 
invoices, contract, in a legal way, and legal way is email. But I often 
have to send 10, 15 emails, just because the base64 overhead double the 
content size, and then I can't fill plainly the stmp email limits... for 
example if I have a limit of 10MB, and a file taking 3MB and another 
4.5MB, I can't even send the 2 in a single email, because the base64 
overhead is about 37%, and then the two of them use 10.2MB.... so I have 
to send them one by one...

I don it because I have too... but to be frank if I wasn't obliged to, I 
would have chosen a cloud storage... because they are binary... and 
that's annoy me, same for storage, because I have to keep all 
communication with a client for 10 years, and can't often store them on 
a tape and forget, because I need often to go and check what was 
exchanged at a time, because there are always clients saying "you said 
that, you have to do it..." so I need a copy of the email, with the 
attachements, the attachements in a way I can open them, the source for 
the creation... I've GB of file duplicated and GB of base64 wasted... so 
I hope that some day, it will end... and if the end means the death of 
email... it will be... and sadely, looking at today's direction, it will 
be META that will decide if you have right to write to someone, and will 
be the all mighty ruler of personal data information and ubiquitous 
"GOD" of what you communicate and with whom. And really, I don't want it.

Best Regards

_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users