Re: RFC3030

Le 04/08/2025 à 13:05, Alessandro Vesely a écrit :
> 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

don't know if I should laugh or cry...

      I am pretty sure my reading of that discussions is accurate, which
    simplifies to:  the number of cases that currently use multiple
    recipients is vanishingly small, and so such support is not essential.

yes of course, small... at work it's 90% of emails that are 
multirecipents, at personal I would say 50/50.... maybe it's best that 
people drops emails...

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