Issue Emails forwarded by Plesk fail DKIM checks with certain attachments

[Bobbbb]

Hello,

I didn't notice any long lines but I tried setting "smtp_line_length_limit = 0" anyway. There was no change so I believe my issue isn't related to long lines.

Perhaps someone could try to reproduce my issue using the steps further below? I'm using Plesk 18.0.58 Update #2 on CentOS 7 (for a little longer). I'm using Postfix and Warden.

I'm troubleshooting this because certain forwarded messages have broken DKIM signatures which causes DMARC failures.

I'm finding that the body of emails that contain 8bit characters, such as an ñ (Enyay), and are sent by the MUA (Thunderbird in my tests) using

Content-Transfer-Encoding: 8bit

are converted to

Content-Transfer-Encoding: base64

when forwarded (and only when forwarded). The forwarding can be to another mailbox on the same Plesk server, or to an external server.

The same message, if sent to a mailbox, on the Plesk server, without forwarding, is received as expected with

Content-Transfer-Encoding: 8bit

.

Steps to reproduce...

1. Create a mailbox in Plesk ([email protected]) such that mail is delivered to that mailbox and also forwarded. Set the forwarding locations to include another mailbox on the same Plesk server ([email protected]) and some other email address not located on the Plesk server (perhaps a Gmail address).
2. Using an external email account (different from any of the others) that signs outgoing messages with DKIM, compose a message, in Thunderbird, containing a single ñ (Enyay) in the body of the message and sent it to [email protected].
3. Check the mail for [email protected] and examine the source of the message received. You should see

   Content-Transfer-Encoding: 8bit

   and the DKIM signature should remain valid.
4. Check the mail for [email protected] and examine the source of the message received. Do you see, as I do,

   Content-Transfer-Encoding: base64

   and the DKIM is broken because the body was converted to BASE64 for an unknown reason.
5. Check the mail for the external email address and see the same thing.

   Content-Transfer-Encoding: base64

   and the DKIM is broken.

Best Regards,
Bob

 

[Alex Presland]

This evening my co-Administrator spotted a number of email validation fixes listed in the changelog to Plesk Obsidian 18.0.59:


I repeated the test which I originally reported above, while still on Plesk Obsidian 18.0.58 Update #2 and these failed DKIM tests.

I then upgraded to Plesk Obsidian 18.0.59 Update #2 and repeated the test.

I am delighted to report that the email made it through Plesk and to the email servers beyond.
This issue is therefore fixed in Plesk Obsidian 18.0.59

(Compare this image with the image shared further up this thread)

What kind of explanation does a "it does not work" need? Sometimes it is a good idea to accept things as they are.

Peter - I am glad that your developer colleagues had a different perspective to you. They didn't "accept things as they are" [were]. They investigated, found the issue, and developed a solution. Your blunt (rude?) comment above shot me down and made me not formally report this issue as a bug. I'll never know whether that delayed this fix... or maybe you and your colleagues knew about this already and were deliberately trying to supress reports while a fix was developed?

The only public reference to PPPM-14166 is on Change Log for Plesk Obsidian
Are there any more details that you can share on this issue... like the date that the ticket was opened; other known use cases which triggered this issue; etc.?