Re: Why rewrite QP-encoded messages when the receiver cannot take 8BITMIME?

On Sat 29/Jun/2024 14:37:04 +0200 Sam Varshavchik wrote:
> Alessandro Vesely writes:
> 
>> Sam,
>>
>> if you thought 8BITMIME was globally implemented, it's not.  There is a 
>> mail-checking service at https://aboutmy.email/ whose server doesn't 
>> advertise it.  Consequently, Courier rewrites messages, thereby breaking 
>> signatures. What is puzzling is that messages are rewritten even if they are 
>> encoded.  Why?
>>
>> Hanno pointed me to the following code in rfc2045acprep.c:
>>
>>     case qpseeneqh:
>>         curstate=quotedprint;
>>         if ( (unsigned char)
>>             ( (h2nyb(statechar) << 4) + h2nyb(*p) ) >= 127
>>             ) currwp->has8bitchars=1;
>>
>> It sets has8bitchars if a char is 8 bit /after decoding it/!  Is there a 
>> reason for doing so?  How about base64 encoded 8bit chars?
> 
> This was originally done to "correct" mailers that always used quoted-printable 
> at the same time that there are mailer readers that did not implement 
> quoted-printable, and just dumped plain text mail. This logic was used to 
> figure out, when talking to a remote mail server, how the message can be 
> transcoded.


Aren't they two different problems?


> Of course, message signatures came along, and blew up everything with a broken 
> design. So, there we are. I'm open to proposals and patches, for a reasonable 
> compromise. Note that this code serves dual purpose – to determine whether 
> something needs to be mime-transcoded, or not, and then when push comes to 
> shove to actually figure out how to transcode each MIME part.


Until there are MTAs that accept messages with no valid signatures, it makes 
sense to rewrite messages on-the-fly, at the cost of breaking signatures made 
before queuing.  Although the trend is to require domain authentication, MTAs 
which don't even accept 8BITMIME don't seem to me to be in the position to 
enforce the bleeding edge.  Since 8BITMIME is almost universal and SMTPUTF8 
doesn't want rewriting, signing works well before queuing, in most cases.


> So, probably any changes would not be here, but in the code that uses this 
> logic. This specific piece of code is correct – it determines whether the given 
> MIME section contains 8-bit content or not (after applying content transfer 
> encoding). So, any logical changes would be elsewhere, where this information 
> is used.


Hm... That code uses the same flag, has8bitchars, for both aspects.  A vain 
QP-encoding, which could be undone, and an unencoded message, which must be 
rewritten if the receiver doesn't take 8bit.  Thus, the meaning of that flag, 
at the entity level, depends on the entity's declared encoding, assuming that 
it's congruous.  At the message level, it becomes a riddle.

Hanno reported that QP-encoded messages are routinely rewritten.  I don't have 
a non-8BITMIME server to test, and the above one doesn't allow access to the 
messages sent, so I just believe what he said.


Best
Ale
-- 





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