A while ago I added this as a dependency in NicTool. The interface is a little different but it works quite well. Being able to replace multiple crypto modules (SHA* and MD5 for legacy and PBKFD2 for present) is a lovely feature.
I've used this module for years and years and I don't think much about it. It's just plumbing and it consistently works. The documentation is very sufficient and when I need to do anything even slightly complicated this module handles it very capably.
It took some digging, as this module doesn't pop up near the top when searching for Net::SMTP, but it's worth finding. This module is EXACTLY what I was looking for. After finding Net::SMTP::TLS (old, broken, poorly implemented, not maintained), and then Net::SMTP::TLS::ButMaintained (maintained, but still poorly implemented), and Net::SMTP::SSL (only supports the deprecated SMTPS on port 465), I finally found this module.
If you are looking for a drop-in replacement for Net::SMTP that adds STARTTLS support, this is it. Works perfectly for me. Thanks so much!
First, I offer my hearty thanks to Fayland for providing this fork, which is basically just bug fixes for Net::SMTP::TLS. For that, I offer a hearty 5 stars.
The problem with this module is its legacy of Net::SMTP::TLS, which in many important ways, does not behave at all like Net::SMTP. If you are seeking a robust and mature Net::SMTP implementation that adds STARTTLS, look to Net::SMTPS instead. The author of Net::SMTPS wrote it the right way, as a very thin subclass of Net::SMTP, so that it benefits from the very well maintained, mature, and robust Net::SMTP module.
You should NOT be use this module. It has not been maintained in 7 years. It is broken in several ways (see the RT bug reports). A successor fork called Net::SMTP::TLS::ButMaintained is available which fixes a number of the bugs in this module. While ButMaintained is better, neither module is very good.
I was hoping this module would be a drop-in replacement for Net::SMTP with TLS support. While testing, I noticed the SMTP behavior was poor (not RFC compliant in several ways) and I fixed a couple of the problems. However, this module is not programmer friendly and in quite a few ways, does not behave like Net::SMTP.
After trying to use this module, I thought to myself, "I would be better of writing myself a thin layer for Net::SMTP that adds STARTTLS support." But before I put paws to keyboard, I searched CPAN again, and found Net::SMTPS, which is exactly what I had envisioned. Consider using it instead.
This module is used by many (surely at least thousands) many users but has only 6 reviews? I guess there isn't much incentive to review this module. Shucks, most users of probably don't know it exists as it gets installed automatically by hundreds of applications and just silently works really well for years and years. I've used it in dozens of applications over the nears with nary a hiccup. Many thanks!
This is EXACTLY the right solution and a mighty fine testament to the forethought the author gave to the problem.
Last night I finally activated the qpsmtpd installation I've had sitting on my server for almost a year. As I watched mail deliveries come in, I paid special attention to all the error messages and worked the many kinks with getting qpsmtpd installed and all the plugins working. Hacking the spamassassin plugin so per-user prefs work, tweaking permissions so clamav works. Bumping up the RAM because I'm running amd64. Etc, etc, etc...
After everything was working as I expected, I started getting bounces for non-existing emails. Holy antiquated problems batman! We solved this problem a decade ago with the qmail chk-user patch. And yet qpsmtpd has no solution. :-( The qpsmtpd dist has a STATUS file mentioning adding support for check_delivery, which no longer exists at the referenced URL. So I found it on archive.org. And it's a half-baked solution that requires suidperl.
I was starting to fear having to write a solution myself, and then I found this. The docs are good, the interface is good, the architecture is excellent, and it works! Thank you, thank you, thank you!
Does exactly what one would expect. Brilliant.
I loathed integrating with RT until I figured out that my RT install (3.8.1 with lighttpd and FastCGI) wasn't playing nicely on a CentOS system. A vanilla install on FreeBSD 7 worked perfectly so we narrowed the problem down to a bug in the version of perl on CentOS 5.
That is behind me now, but that bug cost me a ton of wasted time loading RT.pm into my application and doing a lot of grep -r in the RT source tree to figure out the right incantations to get, update, and create tickets.
This afternoon I resolved the perl problem and replaced all the RT calls we had painstakingly written against RT.pm with RT::Client::REST. It is faster and far, far easier because the documentation is excellent with plenty of included samples. Great job. Great module. Thank you!
I use mail::send in a number of projects and it makes sending email from a perl script about as easy as can be. However, when needs get more elaborate, such as HTML and other attachments, I reach for MIME::Lite.