On Wed, 5 Jun 2024, Tobias Fiebig wrote:
If you're not sending SMTPUTF8 mail, the DKIM signature headers
should be ASCII with no encoding needed. But if you are ending
SMTPUTF8 mail, you can put UTF-8 directly in the header and it
doesn't need any futher encoding either.
Yeah, even more odd, the actual data did not contain any UTF-8 anyway.
Meta now also fixed this.
Can you give an example of the signature headers that caused a
problem? They just sound wrong.
See attached. dkimpy/dkimverify failed on the original mail with:
I wouldn't verify that either. It's just wrong. You're not allowed to
MIME encode strings in a DKIM-Signature header.*
Unfortunately there is a lot of badly written mail processing code that
tries to be helpful by MIME encoding headers without checking whether the
headers allow it.
My understanding, though, is that encoding _should_ be permissible
here, as it would be needed, e.g., when receiving a message from a
server with SMTPUTF8 which then must be forwarded via a server that
does not support it.
Nope. You cannot downgrade a SMTUTF8 message to an ASCII message. The
experimental versions of EAI tried to do that and it never worked so they
took it out of the standards track EAI RFCs.
You can wrap one as a message/global MIME part and send it as an
attachment, but you can't "translate" the message..
R's,
John
* - I'm pretty sure that if you asked the author of RFC 8616, he'd say the
same thing.
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
