Answers.Body: <p>According to <a href="https://github.com/civicrm/civicrm-core/pull/20933#issuecomment-885249769" rel="nofollow noreferrer">this comment</a> in the PR it has been fixed since version 5.29. Not in the codebase directly, but with a composer patch to the pear mail_mime package. It wraps the email content after 750 characters.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-07-24T20:25:02.447Z
Answers.Text: For this to work, put `"enable-patching": true` in the extra section of `composer.json`. Also don't forget to install the `patch` [tool](https://manpages.ubuntu.com/manpages/bionic/man1/patch.1.html)...
Answers.UserDisplayName: Sandor Semsey
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-07-23T10:16:09.713Z
Answers.LastActivityDate: 2021-07-23T10:16:09.713Z
Answers.UserDisplayName: akosgarai
Body: <p>We've have experienced in some cases on emails sent from CiviCRM the DKIM signatures were getting invalid. We use a self-managed email server for this, and usually DKIM is fine.</p>
  <p>After some research I found out the reason why was DKIM broken (and why not always) is that if we send an email with a line containing more than 998 characters - which can happen easily by using email template editors (Mosaico in our case) - first the message is signed by OpenDKIM, then Postfix break lines longer than 998 chars (number of chars can be configured) to conform with SMTP protocol, which doesn't allow more than 1000 chars (998 chars + <code>\r\n</code>) in a single line. Then DKIM verification will fail as there are extra characters (line breaks) in the email body.</p>
  <p>It would be best if the order could be changed (first line breaking then signing), but as far I as know milter applications (like OpenDKIM) can be plugged into Postfix only to the early stages of processing (<code>smtpd</code> or <code>cleanup</code>) and line breaking happens at the last stage (<code>smtp</code>).</p>
  <p>Further testing showed, if I send a mail with this long lines from another email client (Roundcube) to the same server, long lines are already wrapped before signature. Also tested traditional CiviMail and Flexmailer and they gave the same results as with Mosaico.</p>
  <p>This led me to think that wrapping long lines should be handled by clients (CiviCRM in this setup).
  So we wrote a simple extension to handle this (<a href="https://github.com/reflexive-communications/civalpa" rel="nofollow noreferrer">https://github.com/reflexive-communications/civalpa</a>) and the issue seems solved.</p>
  <p>My questions would be:</p>
  <ul>
  <li>Has anybody run into this issue? One thing that is very strange for me, I've not found too much material but one which seemed quite relevant (<a href="https://www.virtualmin.com/node/37021" rel="nofollow noreferrer">https://www.virtualmin.com/node/37021</a>), and that also suggested line wapping should happen before sending to the SMTP server.</li>
  <li>Lien wrapping should really be handled by clients or is this a configuration issue on the mail-server?</li>
  </ul>
  <p>Related versions:</p>
  <ul>
  <li>CiviCRM: 5.29.1</li>
  <li>Mosaico form CiviCRM: 2.5</li>
  <li>Postfix: 3.4.13</li>
  <li>OpenDKIM: 2.11.0</li>
  </ul>
  <p>Thanks</p>
  <p>UPDATE: there is now an <a href="https://lab.civicrm.org/dev/core/-/issues/2705" rel="nofollow noreferrer">issue</a> in Civi core regarding this.</p>
  <p>UPDATE2: it turned out, this is already fixed in core (as a patch). On Drupal 8 you need to enable patching for this to work. (put <code>&quot;enable-patching&quot;: true</code> to the extra section of <code>composer.json</code> and install the <code>patch</code> tool.)</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-03-29T13:48:48.843Z
Comments.Text: This is excellent sleuthing.  This should be fixed in core.  I'm surprised the mailing package doesn't enforce this.
Comments.UserDisplayName: Jon G - Megaphone Tech
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-07-21T08:30:47.267Z
Comments.Text: We did run into this issue aswell. Since DKIM also requires you to send with `7bit` or `quoted-printable` Content-Transfer-Encoding for full compatibility, we fixed both issues at once by adding a internal delivery within postfix before adding the DKIM signature.
Comments.UserDisplayName: Thomas Schüttler
Tags: <civimail><mosaico><flexmailer>
Title: Line wrapping - breaking lines longer than 998 characters - in CiviCRM (CiviMail, Flexmailer, Mosaico)
ThreadText: # Line wrapping - breaking lines longer than 998 characters - in CiviCRM (CiviMail, Flexmailer, Mosaico)
  
  (Asked by: username_0 on 2021-03-25)
  
  We've have experienced in some cases on emails sent from CiviCRM the DKIM signatures were getting invalid. We use a self-managed email server for this, and usually DKIM is fine.
  
  After some research I found out the reason why was DKIM broken (and why not always) is that if we send an email with a line containing more than 998 characters - which can happen easily by using email template editors (Mosaico in our case) - first the message is signed by OpenDKIM, then Postfix break lines longer than 998 chars (number of chars can be configured) to conform with SMTP protocol, which doesn't allow more than 1000 chars (998 chars + `\r\n`) in a single line. Then DKIM verification will fail as there are extra characters (line breaks) in the email body.
  
  It would be best if the order could be changed (first line breaking then signing), but as far I as know milter applications (like OpenDKIM) can be plugged into Postfix only to the early stages of processing (`smtpd` or `cleanup`) and line breaking happens at the last stage (`smtp`).
  
  Further testing showed, if I send a mail with this long lines from another email client (Roundcube) to the same server, long lines are already wrapped before signature. Also tested traditional CiviMail and Flexmailer and they gave the same results as with Mosaico.
  
  This led me to think that wrapping long lines should be handled by clients (CiviCRM in this setup).
  So we wrote a simple extension to handle this (<https://github.com/reflexive-communications/civalpa>) and the issue seems solved.
  
  My questions would be:
  
  * Has anybody run into this issue? One thing that is very strange for me, I've not found too much material but one which seemed quite relevant (<https://www.virtualmin.com/node/37021>), and that also suggested line wapping should happen before sending to the SMTP server.
  * Lien wrapping should really be handled by clients or is this a configuration issue on the mail-server?
  
  Related versions:
  
  * CiviCRM: 5.29.1
  * Mosaico form CiviCRM: 2.5
  * Postfix: 3.4.13
  * OpenDKIM: 2.11.0
  
  Thanks
  
  UPDATE: there is now an [issue](https://lab.civicrm.org/dev/core/-/issues/2705) in Civi core regarding this.
  
  UPDATE2: it turned out, this is already fixed in core (as a patch). On Drupal 8 you need to enable patching for this to work. (put `"enable-patching": true` to the extra section of `composer.json` and install the `patch` tool.)
  
  **Tags:** civimail, mosaico, flexmailer
  
  > **Comments:**
  > **username_1**: This is excellent sleuthing.  This should be fixed in core.  I'm surprised the mailing package doesn't enforce this.  
  > **username_2**: We did run into this issue aswell. Since DKIM also requires you to send with `7bit` or `quoted-printable` Content-Transfer-Encoding for full compatibility, we fixed both issues at once by adding a internal delivery within postfix before adding the DKIM signature.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_3 on 2021-07-23. Score: 2 | Accepted answer
  
  According to [this comment](https://github.com/civicrm/civicrm-core/pull/20933#issuecomment-885249769) in the PR it has been fixed since version 5.29. Not in the codebase directly, but with a composer patch to the pear mail\_mime package. It wraps the email content after 750 characters.
  
  > **Comments:**
  > **username_0**: For this to work, put `"enable-patching": true` in the extra section of `composer.json`. Also don't forget to install the `patch` [tool](https://manpages.ubuntu.com/manpages/bionic/man1/patch.1.html)...  
  
  ---
  
  