Matomo uses a copy of Zend Mail that has last been updated in 2011 (in https://github.com/matomo-org/matomo/issues/2581)
While SMTP isn't the fastest developing protocol, a lot has changed in that time.
So instead of keeping an outdated library or reinventing the wheel, I'd recommend replacing it with a maintained, popular PHP library like PHPmailer or swiftmailer.
Bonus side effect: We would get proper error messages for hard to debug errors instead of things like
fwrite(): send of 6 bytes failed with errno=32 Broken pipe.
Any issue w/ using swiftmailer over PHPMailer? It seems more used.
@diosmosis It doesn't really matter as both are very popular and maintained (last update in the last few days)
I always thought PHPMailer was more popular, but that might be countered by very popular applications like Nextcloud using Swiftmailer
Can I put https://github.com/symfony/mailer as a consideration, it's basically the successor to swiftmailer and if matomo is looking to move forward with new PHP version maybe the solution to use. Any devs available to show me where mail is controlled, happy to look into integrating
also as matomo using a few symfony components it might be good to use the new mailer component
@limitstudios the main class dealing with mail is: https://github.com/matomo-org/matomo/blob/3.x-dev/core/Mail.php
Anything maintained by symfony would be acceptable IMO, the only real consideration would be whether it added too much weight to the matomo or matomo for wordpress packages (ie, if it had too many files that were too large).
@limitstudios The issue with symphony components seems to be that they depend on many other modules:
- Installing psr/container (1.0.0): Loading from cache - Installing symfony/service-contracts (v2.0.1): Loading from cache - Installing symfony/polyfill-mbstring (v1.13.1): Loading from cache - Installing symfony/polyfill-php72 (v1.13.1): Loading from cache - Installing symfony/polyfill-intl-idn (v1.13.1): Loading from cache - Installing symfony/mime (v5.0.3): Downloading (100%) - Installing psr/event-dispatcher (1.0.0): Loading from cache - Installing symfony/event-dispatcher-contracts (v2.0.1): Loading from cache - Installing symfony/event-dispatcher (v5.0.3): Downloading (100%) - Installing psr/log (1.1.2): Loading from cache - Installing doctrine/lexer (1.2.0): Downloading (100%) - Installing egulias/email-validator (2.1.15): Downloading (100%) - Installing symfony/mailer (v5.0.3): Downloading (100%)
➜ ~/tmp du -h vendor --max-depth=0 1,5M vendor
compared to phpmailer which has no dependencies and only 560KB (of which 204KB are just translation strings)
Be good to rather not use
symfony/mailer because of how many files and storage it adds. I think PHPMailer the zip has like around 100KB and swiftmailer around 200KB and be a bit more appropriate. Either should do the job I reckon as we have quite basic needs.
Btw isn't swiftmailer also from symfony? Seeing https://symfony.com/doc/current/email.html
In Symfony 4.3, the Mailer component was introduced and can be used instead of Swift Mailer.
Not sure they will for a long time support both mailers? Haven't looked what their plans are. Hoping they won't deprecate support.
that's interesting what php version was the composer install against? as polyfills should only really pull down if required. I know the Symfony devs are doing quite a big of work to reduce dependencies.
I'll do some comparisions, etc.. on feature set and dependency file size.
that's interesting what php version was the composer install against?
Interestingly PHP 7.3. I was also confused why it installed an "unused" polyfill.