Re: RFC3030

Le 08/08/2025 à 00:51, Sam Varshavchik a écrit :
> 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://datatracker.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.
I direct your attention to the "A "binary string" is any string with NUL 
characters" that says everything... a null terminated string is C ram 
representation of a string, it NEVER appears into a file unless some 
really bad coding memory dump. it's not even legal in C and will break 
almost all program using C library... (that's might be why they added this)
>
> This effectively prohibits the IMAP server from decoding binary base64 
> content, and transmitting it, decoded.

not at all, at most, it would have just required to create an encoding 
which escape the null char... using for example the "\0" C sequence... 
(and the "\\0") the overhead would have been by far less than the 
base64, unless you send a file full of NUL Char....

and I didn't check if the imap RFC do define such escape sequence (like 
the SMTP rfc did define a procedure to allow a text file to contains 
<CR><LF>.<CR><LF> end of transmission sequence)

>
> It is not allowed.
of course it's allowed, since a string never end with a NULL char, it's 
a char added by C to be able to stop string processing, all "text 
writing/processing functions" are just dropping it... a text file never 
contains one and binary file neither, because NULL is not allowed value 
in C, it's a value that is used to trigger CPU errors.
>
> 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.

ok a 8 bit text.... what is the difference (CPU difference/network 
difference/storage difference) of a uint8_t and a 8bit char????? of an 
array of uint8_t and a string (appart the null terminator, for a C 
string, but for a C++ string or string_view?) the difference of 
processing a file doing comparison between a Byte and 'w' or 119 or 
0x77? 8bit text is same as binary, before utf-8 was handled by editors, 
utf-8 were coded using hex/decimal representation.... it's just a big 
array of BYTES. how you interpret them is just your choice.. I don't 
care when coding of what is behind, because it's more fast and portable 
(and buffer overflow injection proof) to do a memcmp(str1, str2, 
size_of(str2)) than a strcmp and the strncmp is in fact just a wrapper 
around the memcmp.... so, unless you need to interpret the data (which 
is the case for example for the eml headers) all the mime part is just 
memcmp for the boundary delimiter.

apart really old app that opens a file in text mode on 
MS-DOS/windows3.11, who use the "text" mode when opening a file? this is 
just a way to run into bugs after bugs, non portable coding, since the 
text mode process end of line char that are different depending of the 
OS... unless you WANT to code your app ONLY for one OS, and want not to 
be able to speak with other world, don't see the use of text mode (never 
used it, since I begun coding on MS-DOS computer, because the first file 
processing app coded, was not even able to parse correctly text files... 
lol... just some relics of some age that I didn't even knew 45 years 
ago.... like 8" floppy drives... And I begun with with 5"1/4 floppies 
computer... ) so... text, binary... this is the same, it's just a 
representation of bits. (and a CPU don't care, there is no ASM 
instruction for text... if you do 'A'+4, it's legal you end with 70 if 
you store it in a int, 'F' if you compare it with a char... well.... 
text... as long as you don't reduce the 8bits to something less (like 
7bits) and then forbid some values... and that's why for ages nobody got 
problem with the "ASCII" extensions used in france, deutschland, italia, 
spanish, long before someone begun to say we need to call 
them "charset=koi8-r" "CP850" ... because at the end, the underlying 
processor were performing operations on BYTES, and don't even care about 
the meaning of the 8th bit.... And because a CPU is just a big 
mathematical unit... it process numbers, what we, humans, put behind, is 
just for us...

and to be franc, unless you added special (and inefficient) code for 
checking that the binary content you send over network on a IMAP 
connection doesn't contain int(0)/char('\0') (requiring to send byte 
after byte instead of a buffer/size DMA access, and anyway 
rcvfrom/sendto berkley socket are not byte oriented, but buffer 
oriented... so unless you parse your buffer before to check that there 
is no '\0' inside, you're likely transmitting them...) there is high 
chances that you can send the char as is and that the remote will 
process them correctly... just because programmers are lazy and won't 
add some check when it will works all the time without.

anyway, it's just a false problem, and just a "human brain issue" 
something totally artificial and just a bug of mind, a limitation like 
the text opening mode of files...

I'm still amazed that it still cause issues and that people feel the 
need to enforce/specify "text"...

>
>>> 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.
not at all... it just replied to a need, and because of this need, and 
ease of use, it spreaded... my aunt send me video by email, because when 
she discovered computers, the email limits were already big enough to do 
it... so she didn't moved to whatsapp, just because they never fall into 
the size limitation. if she had, she will have asked someone, and 
depending of the first people to reply, might have gone to whatsapp, and 
she isn't stupid....
>
> 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.

well.... take a look at the configuration needed by email clients. even 
my aunt has an email client... you have to enter your email, your 
password and maybe go to some access approval for gmail and the like... 
(and this, if you don't install your email provider app, and go activate 
imap to use 3rd party client) exactly what is required for the whatsapp 
access... gmail client is provided with every phone, while whatsapp has 
to be installed by the playstore.

Even clients like thunderbird, fairemail, do provide "3 step 
configuration wizards" for 99% of users (the 1% left are the ones 
running paid/custom email server) : you choose your email provider, 
enter email and pass information, finish with the approval.... that's 
it... the "level of configuration" is handled by the programmer. And on 
android, there is no even a step to configure the gmail client... you 
register your phone using the google account, and that's it.... open the 
gmail app, you have your emails... even more simple than the whatsapp 
process!

>
>> 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.
are you sure??? really sure??? and what if your smtp server don't 
support 8bit text extensions? that's why if you look at emails lot of 
them ends beeing 100% base64, because it's the only safe way and since 
no smtp server reverse an encoding, one stupid relay not supporting 8bit 
and you're good for having a 100% base64
>
> 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.
me, I see more than often (almost 1/3 of the email I look at sources, if 
it was exception, since I rarely open email sources, I should have not 
even noticed it... not counting pgp signed, since pgp rfc found "clever" 
to enforce base64/quoted printable to be certain no re-coding occurs... 
while they could have enforced that the signature will be computed on 
the binary, unencoded, representation of the email instead... at the 
end, what count? the "format" or the "content"? you want the format not 
modified or that the other end can check that the content was not 
modified?)
>
> 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.
and again, since no SMTP server reverse an encoding, one server on the 
chain not supporting 8bit and you're doomed...


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