[Rspamd-Users] rspamd DKIM, Mimecast and Content-Encoding

[Danjel Jungersen]

Thank you for the very nice explanation!

Have the best day.
(It's early morning here)

:-)
Danjel

On 22 October 2024 23:09:27 CEST, Gerald Galster <list+rspamd at gcore.biz> wrote:
>> I have been following this thread, and a large part of it is gibberish to me.
>> 
>> As I understand it, someone (postfix / rspamd) talks 8 bit, someone else talks different language.
>>  - Correct?
>
>In "ancient" times text was encoded as 7 bit ASCII, i.e. using the ASCII table
>that holds 2^7 bits = 128 codepoints, mapping bits to chars, control chars, ...
>While ASCII contains 0-9A-Za-z, it does not contain Umlauts like ä or ö whereas
>an 8 bit encoding like latin1 does include those.
>
>If you want to deliver an email with 8 bit encoded content to a mailserver that
>does not advertise 8BITMIME in EHLO (*), you would have to convert it to 7 bit
>ASCII e.g. using quoted printable encoding.
>
>  # nc localhost 25
>  220 mx1.example.com ESMTP Postfix
>  EHLO localhost
>  250-mx1.example.com
>  250-PIPELINING
>  250-SIZE 24040192
>  250-ETRN
>  250-STARTTLS
>  250-ENHANCEDSTATUSCODES
>  250 8BITMIME  <------------------ (*)
>  QUIT
>  221 2.0.0 Bye
>
>
>Given that mail had been (DKIM) signed before, the conversion will break the
>signature because the content changes.
>
>Problems can arise at different hops:
>
>- your smtp submission server will accept 8BITMIME but one of the subsequent
>  relay hops might not
>
>- your smtp submission server does not advertise 8BITMIME, that means it expects
>  7 bit encoded data, but MUAs (mail user agents / Thunderbird, Outlook, ...)
>  might ignore or not check that and send 8 bit encoded data nevertheless,
>  which may or may not be accepted by the smtp server
>
>
>> And my real question is basically:
>> 
>> Is this:
>> 
>> 1) A problem because a few ISP's use very new or still very rare setups and the problem will increase in the future.
>>  - In this case I hope postfix / rspamd maintainers will do some work before I get into trouble....
>
>No, it's a legacy problem. If I recall correctly 8BITMIME goes back to RFC 1652 
>dating to July 1994: https://datatracker.ietf.org/doc/html/rfc1652
>
>> or
>> 
>> 2) A problem because a few ISP's use very old or deprecated setups and the problem will go away by itself.
>
>Yes and no. It's a legacy/implementation problem but as Mimecast shows it can
>hit you 30 years later. Moreover a service that speaks smtp does not have to be
>a fully-fledged mailserver. Some of those ominous middleware boxes, e.g. firewalls
>with smtp content inspection, sometimes interpret standards in a creative way ...
>There had been workarounds for obsolete Cisco PIX firewalls in postfix for example.
>
>
>>>> In our case we have a second Postfix instance running for outbound delivery with 8BITMIME disabled (smtpd_discard_ehlo_keywords = 8bitmime), and it does the signing with OpenDKIM. For inbound, we accept 8BITMIME and let the Rspamd milter do the DMARC validation.
>>> thanks for sharing! This indeed seems to be one option, and actually amavisd, at least when run via the classical method instead of a milter, seems to do similar. [...]
>
>Amavisd as a contentfilter usually does not advertise 8BITMIME in that case,
>which postfix honors:
>
>  $policy_bank{'ORIGINATING'} = {  # mail originating from our users
>     originating => 1,  # indicates client is ours, allows signing
>     #
>     # force MTA to convert mail to 7-bit before DKIM signing
>     # to avoid later conversions which could destroy signature:
>     smtpd_discard_ehlo_keywords => ['8BITMIME'],
>     ...
>
>Best regards,
>Gerald
>
>-- 
>Users mailing list
>Users at lists.rspamd.com
>https://lists.rspamd.com/mailman/listinfo/users