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

[Gerald Galster]

> 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