Re: RFC3030

Le 04/08/2025 à 02:35, Sam Varshavchik a écrit :
> JLX2 writes:
>
>> « HTML content follows
>>
>>
>> »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)
>
> The "Correct" is in response that there is automatic convertion if the 
> remote server does not advertise 8BITMIME, and mail has unencoded 
> 8-bit content. Without 8BITMIME as far as the sending server is 
> concerned, when it does not implement the other SMTP extensions, the 
> receiving server only understand 7-bit content, so the 8-bit content 
> will get automatially converted. And it is, for that reason, why it is 
> very unlikely that a server that implements BINARYMIME will not 
> implement 8BITMIME. It only creates more work for itself.
OK nice
>
>>> 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....
>
> 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?

https://datatracker.ietf.org/doc/html/rfc3501#section-4.3.1

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)

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

>
>> 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
>
> You are referring to the fact that if maildrop detects that the 
> message is not piped in, but redirected from a file it won't bother 
> reading it into memory or temporary file. This has nothing to do, 
> whatsoever, with binary MIME attachments.
true...
>
>>> 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...
>
> I strongly doubted that they motivated by inability to download binary 
> attachments from messages in their INBOX.

going back 10 or more years ago (I don't remember) at this time I begun 
dancing courses... whatsapp was not widely used, almost nobody knew 
about it... A tango lesson... I hadn't my smartphone so I couldn't film 
the summary at the end, I asked one that could film if it could send me 
the video :

  * ok no problem, I send it you with whatsapp
  * whatsapp? what's that?
  * it's a phone app
  * I don't have it, can't you send it to me by email?
  * that's too big
  * why not a online drive or a WeTransfert? it's easy, you just upload
    it and enter my email, I can get it
  * you should install whatsapp, it more easier
  * blablabla

I tried everything, and at the end, I had to install whatsapp, because 
even if it was easy to do a WeTransfert and even more faster... people 
are stu... after that they created a group to share the videos, and 
there was only videos, then tons of groups, just to share files... some 
photo, no conversation... at this time there was already chat 
application, jabber, and the like, but that couldn't send binary 
files... and whatsapp didn't even provided video call and other phone 
call, while other client did (but were dedicated to phone and video 
call, not file sharing)

on this group and all the group I was in for years I used whatsapp, the 
only thing that was used is just video transfert, some text and photos, 
but that you could do with email... and that's it... it was... just... 
more... integrated than going to a website and upload a file.

I got tired and privacy issue of whatsapp bothered me, so I dropped 
it... but for years, I used it, there was no video call, no phone call, 
just file sharing and some chitchat.. but the fact was, that if they 
could have sent their video files by mail, they would, they just found a 
way to do it, and this way at this time was called whatsapp

even latter, in covid times, there was no phone call, no video call... 
people used zoom...

so yes, all the people I know that gone to whatsapp, signal and others 
messenger done it to send video, photos, because at this time, there was 
no limitation on attachement, and because 3 photos encoded in base64 did 
reached the email's server limits, while on whatsapp, they could send 10 
photos, 3 videos... and that's it...

>
>> 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
>
> Of course they don't. They make one email with ten recipients, upload 
> the message from their client to their mail server, and it'll handle 
> the rest. And if five of those ten recipients are on the same domain – 
> which is highly likely, the mail server (if it is sane) will send 
> exactly one message to those five recipients, too.
you miss read : ONE recipient TEN emails, not one email for ten recipient.
>
> This is not the reason for the overall decline of email.
>
>> 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.
>
> 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? video 
call? nobody do it, in more than 10 years, I only saw it used 3 or 4 
times... phone call? same... even when I was on trip... chitchat? well 
you could do it by email... reception and reading notifications? same... 
threading? same... email group? same... in fact, there is nothing you 
can do with watsapp that you can't do with email...

the only thing you can't do, is sending big files.

>
>> 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
>
> No, it does not. It increases the content by approximately 33%

you should add "AVERAGE" because it's 30 to 37% overhead "officially" 
(like the CPI index is officially less than 3%)... it's statistic, I 
don't remember the US president that said "there is 3 level in lying : 
lying, perjure, and statistics", according to my tests done on the files 
I send to almost all clients, my overhead is around 36,4% and some file 
(and not the smallest) are going nearly the 45% overhead (and I'm 
FRENCH, so nowhere the CJK overhead), because the file has almost none 
bit content in the 7bit plane and even less in the a-zA-Z1-0 and other 
64 char that are used... on 256 char, base64 only have 1/4 handled...

BUT of course, if you are an English user, and on some way a West 
European speaker, you are less impacted... it's the same as UTF-8 : 
designed by western people for western people.... even before the 
unicode begun, most used glyphes in the world were CJK, Idian, russian 
(because of URSS sphere) on par with western (because of the OTAN 
sphere) and don't know about arabic, but since it's "nearly" the begin 
of unicode, it's somewhat less impacted... and looks : CJK :  U+2E80 
to U+9FFF.... requiring 60% average overhead... and before that, you 
find mongolian, limbu (what's that???) Runic (sure, I often 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?

the true is, that people that designed base64 and Unicode are western 
people that don't care about the rest of the world (if they had, they 
would have made unicode with European (because of ASCII compatibility 
requirements) followed by CJK...). They done statistics using the files 
they had, that were mostly western based, and ending saying "there not 
so much overhead"....

it's the same as the STUPID writter of SMTP, enforcing 7bit at a time 
where 8bit processors where already the standard... instead of creating 
a "fallback" for 7bit smtp old server, and making the 8bit the 
standard.... how yes I forgot, it's an US people that done it, and even 
other than english western european languages were not even worth the 
effort....

same for photo, videos... it's and AVERAGE... some are fine, others 
terrible...

you thinks that japaneses and chinese write their emails in english? 
lol, just go to japan, outside tokyo and kyoto, find someone that speak 
english... good luck!

>
>> 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
>
> So, it's not "double the content size"?
depends of the content... but yes, on pdf I send to the clients, most of 
them are nearly doubled... and well you play on words... because 37% is 
almost 40% and this is AVERAGE and this is far from you 33%. so some 
files are nice, and have 10% average, others are not... and I done tests 
on single files, not taking all into account, like the fact the most 
impacted files are amongst the biggest one... so yes, I have 25MB email 
quota, and for some email I only send 2 files taking less than 10MB on 
drive...
>
> Anyway, I am not arguing that eliminating the overhead of base64 
> encoding is not a worthwhile endeavor. In fact I have actually 
> implemented something like that a long time ago, in a sort of a 
> skunkworks project. But having done so, I also agree that the 
> cost/benefit analysis just does not look good.

well, me, on some project, I said me "I will be portable, going to 
base64, json, xml...." and rapidly gone back to binary even with 
endianess problematic and having to write some doc to describe the 
binary content

so yes, the fact that people are dropping emails is just linked to the 
7bit stupid compatibility of SMTP and servers that stayed at 
stone-age... obliging emails providers to limit the sizes, because of 
storage, because of bandwidth, and even today, while most of emails 
servers could have dropped single email quotas (not account quota) it's 
still there....

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