> On 21 Oct 2024, at 15:40, Florian Effenberger <flor...@effenberger.org> wrote:
>
> Steve Atkins wrote on 21.10.24 at 16:28:
>
>> If you’re sending 8BITMIME payloads to aboutmy.email that’s probably your
>> problem. We don’t currently advertise 8BITMIME, and flag any non-ascii
>> character in the transaction as a problem.
>> A lot of MXs advertise 8BITMIME, and many others will accept non-ascii
>> payloads even if they don’t, so violating it is a fairly common mistake that
>> doesn’t get noticed right away.
>> But at that point you’re not sending email, so you’re outside the scope of
>> what DKIM promises to do.
>
> I configured smtputf8_enable = no in my main.cf (and nothing that overrides
> it elsewhere), so in theory I should not be sending any 8BITMIME content, or
> is there any other setting that I miss?
I think that’s just for support of i18n headers and email addresses, nothing to
do with non-ascii in the body of the message, so probably a red herring here.
If you’re sending purely ascii payloads then everything will be fine. If you’re
sending non-ascii payloads to servers that don’t announce 8BITMIME that could
cause problems.
I don’t know for sure but if using a content-transfer-encoding other than 8bit
fixed things I’m suspicious. I’d check whether the mail you’re sending as 8bit
has non-ascii in it anywhere (aboutmy.email flags that on the payload tab, I
think). If it does then that’s your problem. If not … your problem is much more
interesting. :)
Cheers,
Steve
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
