On 10/05/2025 14:09, Ken Biggs via Postfix-users wrote:
HI Nick,
I had cut and pasted from the "Raw Source" view in mac Mail, but double checked
in the spool file and those are the headers received in that order.
Thanks,
Ken
Thanks for confirming.
My set-up is very similar to yours, and (like Matus) I don't see any
problems with OpenDKIM in my environment. So I agree that this is more
likely a configuration/environment issue rather than a bug in OpenDKIM.
My gut feel is that the email is being 'transposed' somewhere, after the
Gmail server has generated the DKIM signature, and before your server is
performing the DKIM validation.
I tried connecting to your MX server on port 25 to see if it offered
8BITMIME and SMTPUTF8 support, and it does, so that's a good thing to
check off. And you've told us you aren't using any SMTP proxy prior to
the DKIM validation. Can you please also confirm you aren't fronting
your MX server with any type of 'security appliance' or load balancer?
(Which could also be proxying the incoming SMTP connection?)
Otherwise the only idea I have at this point is to use the process of
elimination to work out what passes and what doesn't pass DKIM checking.
There are probably tools that might help with this, e.g. SWAKS (which I
don't personally have any experience with)? Or worst case you could
resort to using a set-up like this:
raw email text file (see below) --> MUA* --> external MSA (e.g.
gmail) --> (DKIM signature added) --> your MX server (validates DKIM
signature)
* You'd need to use something that gives you complete control of the
message headers, e.g. something like sendmail which delivers to an
external MSA (so the email will be delivered using inbound SMTP to your
MX server) or even "openssl s_client"?
Then the raw email text file should be crafted to test different
scenarios - e.g. things like:
* Email containing only letters+numbers characters in the email body
along with these headers:
o Normal email headers like: From, To, Subject, Date
o Content-Type: text/plain; charset=us-ascii
* Email containing letters+numbers+equals (=) characters, encoded as
quoted printable (so equals becomes "=3D") along with these headers:
o Normal email headers like: From, To, Subject, Date
o Content-Type: text/plain; charset=us-ascii
o Content-Transfer-Encoding: quoted-printable
* Email containing letters+numbers+equals (=) characters, not encoded,
along with these headers:
o Normal email headers like: From, To, Subject, Date
o Content-Type: text/plain; charset=us-ascii
* Email containing letters+numbers+Unicode (non-ASCII) characters, not
encoded, along with these headers:
o Normal email headers like: From, To, Subject, Date
o Content-Type: text/plain; charset=utf-8
* ...
...Which is going to be tedious, but that's all I can think of right
now, to try to isolate which scenarios have the issue?
But of course if the first scenario still exhibits the issue, then that
probably disproves my theory immediately?
Nick.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
