New: Native DKIM capability for emails

[krisznet]

What does it do?

Adding native DKIM capabilities to MODX without creating a custom email script. After setting up the correct values in system settings, all mail sent by MODx will be signed.

Why is it needed?

More and more companies moving to DKIM and also using 2-factor authentication for email accounts, so even secure SMTP is not an option for those. SPF record is often not enough to be able to deliver email reliably.

How to test

Regular mail and SMTP should work like before. If you add DKIM details in settings the Emailer should use it and the email should be signed with the correct key.

Related issue(s)/PR(s)

Resolves #16396

[zaigham]

@krisznet You just need to commit translations in core/lexicon/en/* folder, the translations will be handled via Crowdin.

[Bruno17]

Had that same issue and got this answers on slack: https://modxcommunity.slack.com/archives/C042Q4YS7/p1681303237481139?thread_ts=1678262173.500949&cid=C042Q4YS7 I could solve it then by setting up SMTP and DNS correctly

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 21.59%. Comparing base (69a7d6d) to head (5f138ae). Report is 134 commits behind head on 3.x.

Additional details and impacted files

@@             Coverage Diff              @@
##                3.x   #16421      +/-   ##
============================================
- Coverage     21.75%   21.59%   -0.17%     
- Complexity    10478    10566      +88     
============================================
  Files           561      561              
  Lines         31590    31946     +356     
============================================
+ Hits           6872     6898      +26     
- Misses        24718    25048     +330     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[krisznet]

Had that same issue and got this answers on slack: https://modxcommunity.slack.com/archives/C042Q4YS7/p1681303237481139?thread_ts=1678262173.500949&cid=C042Q4YS7 I could solve it then by setting up SMTP and DNS correctly

@Bruno17 The problem is that some company has strict email policy and 2FA for emails, so the SMTP not an option. And it is 2023, DKIM and DMARC is essential.

[Omeryl]

Huh? In what case is the company completely fine with you setting a random DKIM key in the DNS, but won't provide you with SMTP credentials for an account authorized to send for the domain? Storing these in a web application is a terrifying prospect, the mail server is a much better place to be signing emails. Furthermore, if an email fails to send one time with mail(), it won't be retried. Mail servers retry every so often on an exponential back off. This is better for the internet, sometimes receiving mail servers go down (even Google!).

[krisznet]

Huh? In what case is the company completely fine with you setting a random DKIM key in the DNS, but won't provide you with SMTP credentials for an account authorized to send for the domain? Storing these in a web application is a terrifying prospect, the mail server is a much better place to be signing emails. Furthermore, if an email fails to send one time with mail(), it won't be retried. Mail servers retry every so often on an exponential back off. This is better for the internet, sometimes receiving mail servers go down (even Google!).

@Omeryl I agree that SMTP is more reliable but sometimes you can't use it because of the technical limitations. If 2FA is required for emails SMTP is not an option. You can set up DKIM selectors, so you can just create a key solely for this purpose. If it is compromised, you can delete it and set up a new one. The private key can be stored in a file or DB and can be encrypted. If your database and/or filesystem are compromised, you are already in big trouble.

[JoshuaLuckers]

@opengeek @Mark-H i would love to get your opinion on this, to me it seems like a great addition even if it’s not the preferred solution (to have it as option in the CMS).

[Bruno17]

my idea was to add a plugin event to modPHPMailer::send 'onMailerSend' or something like that, where we could hook in and add for example this DKIM stuff, if needed.

[opengeek]

my idea was to add a plugin event to modPHPMailer::send 'onMailerSend' or something like that, where we could hook in and add for example this DKIM stuff, if needed.

I guess my question is why wouldn't this be settings of an extra that installs this plugin?

[Bruno17]

my idea was to add a plugin event to modPHPMailer::send 'onMailerSend' or something like that, where we could hook in and add for example this DKIM stuff, if needed.

I guess my question is why wouldn't this be settings of an extra that installs this plugin?

Yeah. But thats currently not possible, because there isn't an event like that.

[opengeek]

my idea was to add a plugin event to modPHPMailer::send 'onMailerSend' or something like that, where we could hook in and add for example this DKIM stuff, if needed.

I guess my question is why wouldn't this be settings of an extra that installs this plugin?

Yeah. But thats currently not possible, because there isn't an event like that.

But this PR does not add an event. I guess I'm still confused how this is supposed to work as is in the PR.

[Bruno17]

my idea was to add a plugin event to modPHPMailer::send 'onMailerSend' or something like that, where we could hook in and add for example this DKIM stuff, if needed.

I guess my question is why wouldn't this be settings of an extra that installs this plugin?

Yeah. But thats currently not possible, because there isn't an event like that.

But this PR does not add an event. I guess I'm still confused how this is supposed to work as is in the PR.

oh.. its not my PR. The Opener has added his new systemsettings as default attributes into modMail https://github.com/modxcms/revolution/pull/16421/files#diff-919cb7414fac156184fcd82007638be9e5946883c0348c3c6957ea355060d390

[opengeek]

From what I can see, all of these "settings" are part of modPHPMailer. modMail is an interface that is intended to define common settings for any mailer implementation. In order to set the modPHPMailer settings, those entries can be manually added to system settings when needed, and they will just work. So I'm not sure of the actual necessity of this core change.

[krisznet]

my idea was to add a plugin event to modPHPMailer::send 'onMailerSend' or something like that, where we could hook in and add for example this DKIM stuff, if needed.

I guess my question is why wouldn't this be settings of an extra that installs this plugin?

Yeah. But thats currently not possible, because there isn't an event like that.

But this PR does not add an event. I guess I'm still confused how this is supposed to work as is in the PR.

oh.. its not my PR. The Opener has added his new systemsettings as default attributes into modMail https://github.com/modxcms/revolution/pull/16421/files#diff-919cb7414fac156184fcd82007638be9e5946883c0348c3c6957ea355060d390

Hey guys, if you read the original PR and the Issue it is described clearly. DKIM capability is already in modPHPMailer but you can't use it through modMail with any existing extension like FormIt. I added the settings and also modified modMail, so it uses those settings. That is it. It is much easier than creating a plugin and it is not much code and also not a difficult change.

[krisznet]

From what I can see, all of these "settings" are part of modPHPMailer. modMail is an interface that is intended to define common settings for any mailer implementation. In order to set the modPHPMailer settings, those entries can be manually added to system settings when needed, and they will just work. So I'm not sure of the actual necessity of this core change.

@opengeek You are right but not 100% right. You can use DKIM if you write a custom snippet but can't use it with emails sent by modX itself or an extra like FormIt.

[opengeek]

From what I can see, all of these "settings" are part of modPHPMailer. modMail is an interface that is intended to define common settings for any mailer implementation. In order to set the modPHPMailer settings, those entries can be manually added to system settings when needed, and they will just work. So I'm not sure of the actual necessity of this core change.

@opengeek You are right but not 100% right. You can use DKIM if you write a custom snippet but can't use it with emails sent by modX itself or an extra like FormIt.

I see now. If the default attributes are not set, the initialization does not look for those attributes in the settings. Let me think on this. It would, in my opinion, be better if we modified the initialization of modPHPMailer to look for attributes from MODX settings in all cases. Otherwise, we will run into other options in this mailer—or in any mailer implementation—that would have to manually be added to the modMail interface. And this is not really the job of an interface.

[krisznet]

From what I can see, all of these "settings" are part of modPHPMailer. modMail is an interface that is intended to define common settings for any mailer implementation. In order to set the modPHPMailer settings, those entries can be manually added to system settings when needed, and they will just work. So I'm not sure of the actual necessity of this core change.

@opengeek You are right but not 100% right. You can use DKIM if you write a custom snippet but can't use it with emails sent by modX itself or an extra like FormIt.

I see now. If the default attributes are not set, the initialization does not look for those attributes in the settings. Let me think on this. It would, in my opinion, be better if we modified the initialization of modPHPMailer to look for attributes from MODX settings in all cases. Otherwise, we will run into other options in this mailer—or in any mailer implementation—that would have to manually be added to the modMail interface. And this is not really the job of an interface.

All other settings are in the modMail interface as well like SMTP settings and charset, etc. That is why I put it there.

[cla-bot[bot]]

Thank you for your contribution! Before your pull request can be reviewed, please sign the MODX Contributor License Agreement (CLA). This is to make sure MODX has your written permission to distribute projects containing your contributions under the appropriate license.

Please make sure the CLA has been signed for GitHub user(s): @krisznet

Once you've signed, please reply with @cla-bot check to verify and update the status of this pull request.

[krisznet]

All lexicon entries other than the en/ sources must be removed from this PR.

I'm also not clear on how this works by just setting some options.

@opengeek I removed the unwanted lexicon changes.

[opengeek]

@krisznet — can you sign the CLA and make sure you add your GitHub username when doing so?

[krisznet]

@krisznet — can you sign the CLA and make sure you add your GitHub username when doing so?

@opengeek I did it yesterday.

[opengeek]

@cla-bot check

[cla-bot[bot]]

The cla-bot has been summoned, and re-checked this pull request!