Multipart emails with empty multiline text part break DKIM

[GioPan04]

This is a similar issue to #411, although much specific.
I've noticed that If a multipart email (text and html) is sent and the text part contains more than 5 empty lines (both \r\n and \n) the email won't get correctly signed.

• This message contains 5 empty lines and gets correctly signed working.txt

• This message contains 6 empty lines and is not correctly signed fail.txt

I've also noticed that if a message is not correctly signed one empty line gets removed from the text part (this maybe the reason for the failing DKIM).

• This is the message downloaded from gmail (the receiving server) which was sent with 5 empty new lines: pass-gmail.txt

• This is the message downloaded from gmail which was sent with 6 empty new lines: fail-gmail.txt

[andris9]

Yes, the current DKIM signing implementation is buggy. I plan to replace it with https://github.com/postalsys/mailauth which has a better, more tested implementation

[GioPan04]

Is there any ETA on this?

[andris9]

Try v 3.10.0

[GioPan04]

I'm still experiencing this issue.
A line between the multiparts is deleted after the dkim is calculated, breaking the previous body hash altogether.

I'm using Zone-MTA 3.10.0

[GioPan04]

I was able to isolate the issue.
It seems like that if I connect using TLS or STARTTLS the DKIM is incorrectly calculated. When I connect to the raw 25 port the DKIM is valid.

[andris9]

I seem to be unable to reproduce this issue.

I use STARTTLS and send fail.txt and pass.txt to a Gmail address through my ZoneMTA instance. Both messages are signed correctly, and Gmail shows that everything is correct. Do you have, for example, a ZoneMTA plugin that somehow modifes the email and is triggered for the STARTLS interface but not for the cleartext interface?

[GioPan04]

Thanks for reopening the issue!

Do you have, for example, a ZoneMTA plugin that somehow modifes the email and is triggered for the STARTLS interface but not for the cleartext interface?

I don't think so, I'm testing this with a clean installation of zonemta using the template. I just edited the config files for the interfaces and the example-dkim plugin with a custom dkim key.

I did some more digging and I wasn't able to replicate this with the same example I provided, but I was able to replicate the issue in another way.

It seems that ONLY using PHPMailer (or Symfony Mailer) with the 465/587 port and sending original.txt, zonemta fails to correctly sign the email, but sending the same email with another client, the issue doesn't occur.
Note: the file is a stripped out version of an email generated by Symfony, here I'm using PHPMailer for ease of debugging.

The culprit seems to be this part, in fact by removing it from the text part the email is also correctly signed:

=C2=A0

=

For reference, this is the small script I made for testing with PHPMailer:

<?php

use PHPMailer\PHPMailer\PHPMailer;
use PHPMailer\PHPMailer\SMTP;
use PHPMailer\PHPMailer\Exception;

require __DIR__ . "/vendor/autoload.php";

$mail = new PHPMailer(true);

try {
  //Server settings
  $mail->SMTPDebug = SMTP::DEBUG_SERVER;
  $mail->isSMTP(); //Send using SMTP

  $mail->Helo = "127.0.0.1";
  $mail->Host = "stg-zmta.emailvlt.net";

  // $mail->SMTPSecure = PHPMailer::ENCRYPTION_STARTTLS;
  $mail->SMTPSecure = PHPMailer::ENCRYPTION_SMTPS;
  $mail->Port = 465;

  $mail->smtpConnect();
  $smtp = $mail->getSMTPInstance();
  $smtp->do_debug = true;
  $smtp->mail("test@emailvlt.net");
  $smtp->recipient("example@gmail.com");
  $smtp->data(file_get_contents("/.../original.eml"));

  echo "Message has been sent";
} catch (Exception $e) {
  echo "Message could not be sent. Mailer Error: {$mail->ErrorInfo}";
}

[NickOvt]

Hello!

I tried to send an email using your provided php script and original.txt file contents as the data and indeed the dkim breaks in that case (can't verify body hash). The culprit (highly likely) is the single = in the middle of the content. Will investigate and take this issue into work.

[NickOvt]

@GioPan04 The issue was very likely due to incorrect message splitting in MailSplit's MessageSplitter.
Please view zone-eu/mailsplit#31
You can try to test the email sending with the new splitter. But as far as I have tested it - seems the issue has been resolved.

I'll close this issue when that PR is merged.

[GioPan04]

@NickOvt Sorry for the late response, I was on vacation.
I just tried this with the fix in mailsplit and it seems to work perfectly. I'll keep testing with other examples and if I see anything strange I'll update this issue.
In any case, thanks for fixing this!

[GioPan04]

Hi, sorry for another ping.
This issue should be reopened as zone-eu/mailsplit#31 was reverted back in July.
This is a somewhat important problem as most PHPMailer and other email sending libs are affected.