Re: RFC3030

Sam Varshavchik <[email protected]> Sun, 03 Aug 2025 20:35:28 -0400
Newsgroups	gmane.mail.imap.courier.general
Message-ID	<[email protected]>
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.

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

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

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

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

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.

> 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%
 
> 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"?

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.

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