Use SMTP to send reports

[justdave]

Ironically, the reports emailed by summary_report.php are getting flagged as non-aligned for me because they're using the built-in PHP mailer which goes out through the hosting server, which I don't have control over on shared hosting, and therefore I can't configure it to sign using my DKIM key. :-) This came up as I was trying to chase down legitimate sources of non-aligned mail.

This could be avoided if it knew how to use SMTP (via the same account it's using for IMAP in my case)

I'm happy to submit a PR for this, but I have questions first to make sure I don't submit something you're not going to like. :-)

It seems like the accepted way to send mail via SMTP from PHP is to use PHPMailer (or another mailer library - I'm open if you have a preference). While you can just drop a copy of PHPMailer into your source, the easiest way to get it is to use composer to install it. Using composer actually gets you security benefits on GitHub: if PHPMailer ever has a security issue, GitHub will automatically file a ticket (and sometimes even a PR) against your project to update the dependency to the fixed version.

So with that said, are you willing for me to add a composer dependency to your project?

Here's what the patch will entail if I do it this way:

1. Add a .gitignore file that will ignore /vendor because that's where composer will download to, and you don't want the dependencies included in your source control. (Should probably add /config/conf.php to this as well so someone doesn't accidentally commit their production config file)
2. Add composer.json and composer.lock files to the project. composer.json will describe what the desired dependencies are (i.e. PHPMailer > some version). composer.lock will contain specific references to the version(s) last tested with so that chasing bugs is easier (everyone gets the same version).
3. End users who check out from source would need to run composer install to pull in PHPMailer.
4. A GitHub Action can be put in place to generate a zip file or tarball or both on your releases which already contains the results of composer install so the end user doesn't have to do it. I can supply that as part of the PR if you want.
5. config options for SMTP would be added to the sample config file
6. summary_report.php will check a) whether those config options are present, and b) whether PHPMailer is installed (in case they installed from source and didn't do composer install), and fall back on the existing mail() code if either check fails. This would ensure an update won't break people in case someone is auto-updating from git and not reading the changelog.

Thoughts?

[liuch]

Hi justdave,

I agree with you that it is necessary to expand number of ways to send the emails. But I don't want to use Composer for this, sorry. This is an explicit dependence, I try to avoid this in my project, especially since there is a ready-made package called libphp-phpmailer, at least for Debian. Moreover, I do not use Composer at all and it will be difficult for me to support this dependence.

I think it will be enough to expand $mailer option in the configuration file: add parameters method, username, password, and maybe encryption to it. Keep in mind that credentials for SMTP may differ from the IMAP ones. Of course, it makes sense to add a comment to the sample configuration file and add some checks in the script. By default I would use the old method of sending emails.

I already thought of sending reports via phpmailer as an option, but it will take time for me, because I'm not familiar with this library. If you do this work without Composer, I will gladly accept your PR.

Any way, thank you for your attention to my project!

[justdave]

I've never used a system-wide PHPMailer before, and had to do a little research to figure out how to do it... and discovered that PHPMailer officially no longer supports being used system-wide as of version 6.0, and using composer (or embedding the entire package in your project manually) is their only supported installation method.

However, poking around at the Ubuntu packages, it looks like the Debian folks ported the system-wide autoload feature from version 5 back into version 6, so you can still do that on Debian and Ubuntu systems, even though PHPMailer upstream doesn't actually support it.

My shared hosting provider is running Debian. But they don't have libphp-phpmailer installed, so using composer will be my only (easy) way to get it. I can get it on my Ubuntu laptop to play with it though. So I guess the answer here is to have the path to the autoload file for phpmailer in the config file, and have the default for the Debian/Ubuntu package and the default for composer both there and commented out. And that'll let the user install it wherever they want and be able to tell it where it lives, with usable examples if they're in either common scenario.

[liuch]

I thought It might be better to just allow to specify a command to be run when the email is sent and pass it the target email address and message text. This would allow to configure any program to send messages as an alternative to the built-in function. How do you think?

[justdave]

It'll probably work on mine, but some hosting providers have exec and friends disabled in PHP.

[liuch]

Yes, you're right, I didn't think about that. Any way, I'm going to add the ability to output the text of the summary dmarc report to stdout. So you may run your own script in cron, get a summary report in it, and then send the report wherever you want.

[mbsouth]

The possibility to send reports directly via SMTP would also be very advantageous for me! A simple SMTP PHP class (single file) can be found here: https://github.com/halojoy/PHP-SMTP-Mailer. MIT licensed, none dependencies! The necessary credentials (MTA) could also be stored in the database (constructor must be adapted).

Jm2c mbsouth

[liuch]

I'm going to make it possible to use alternative libraries for sending mail.

[liuch]

Implemented with 8f76c135f2b5e5d66596c695b4a5fbeb97176a1e