Re: RFC3030

On Mon 04/Aug/2025 02:35:28 +0200 Sam Varshavchik wrote:
> JLX2 writes:
>>>
>>>> but no reference about RFC3030, BINARYMIME and more I find too bad that 
>>>> there is an "automatic conversion" : 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 conversion 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 automatically 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.


Let me just recall that on-the-fly conversions break any signature that had 
been made at enqueue time.  DKIM would have been more resilient if it were 
MIME-aware.  However, that's not where future developments seem to point to 
(see below).


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


In this regard, the IETF's DKIM working group is evaluating sending five copies 
of that message, in five different transactions, even if the five recipients 
are on the same MX.  Astonishing as this may seem, they argue that this would 
be simpler than handling multiple recipients.  See, for example, this:
https://mailarchive.ietf.org/arch/msg/ietf-dkim/qE4Yl2iJHD4eC1iQ3eJFH4cwboc


Best
Ale
-- 







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