mstpan 15 - Email
In which EHLO implies something worse than teletubbies
Net::SMTP
People think "I want to send mail via SMTP", and then they find Net::SMTP.
And now they have 200 OK problems.
Firstly, you probably didn't want to send directly via SMTP - it's almost always better to have a local mail system that ships things off to a smarthost, and you can use something like ssmtp if you don't want a local queue.
Secondly, even if that isn't an option, you're much better off with something higher level that can call Net::SMTP for you.
File under "slightly better than opening a pipe to sendmail in the middle of your code, but only slightly".
Email::Send
This was the previous generation of high level wrapper. It's perfectly usable, there's no reason to panic if you already have code using this, but it's been superceded by Email::Sender so don't expect any new features to appear.
Note that for a while Email::Sender wasn't widely adopted by lightweight codebases due to using Moose, but it got ported to Moo some time ago because a bunch of us decided we'd rather do that than keep dealing with Email::Send.
Email::Sender
Unless you have a specific reason to be using something else, you should be using Email::Sender. It has pluggable backends, including the incredibly handy Email::Sender::Transport::Test for doing dry runs, is actively maintained, and is gradually accruing an extremely respectable ecosystem.
You should generally be able to use it via Email::Sender::Simple, but see also Email::Sender::Manual and Email::Sender::Manual::QuickStart for more information.
Email::Stuffer
A fluent OO interface for building an email and passing it to Email::Sender - supercedes Email::Stuff which was based on Email::Send.
This is pretty much my default for simple things, unless I'm doing straight up scripting, in which case Emailesque provides a less OO-heavy, super sugary wrapper around it.
If you need in-script templating, to go with it, String::TT is neat.
Email::MIME
This is a subclass of Email::Simple with full MIME handling built-in. If you're trying to parse and process an email, this is pretty much the standard way to do it.
It is, admittedly, exceedingly old code ... but on the other hand, given how many crazy things people do in email, 'old and battle-tested' is really, really important. Also, it's becoming gradually less insane code over time, so (assuming you don't try and depend on the internals) things are only going to get better.
Email::MIME::Kit
Email::MIME::Kit allows you to have a directory tree of files, templates and configuration, which it then assembles into an email for you. It has pluggable renderers so you can use whatever templating system you need,
If you're building templated emails in an application, this is almost always the best answer - since it can live independently of the code deciding to call it, rather than ending up (like e.g. Catalyst::View::Email) getting tied into your web templating.
Alternatives
The above basically constitute the common options, but I thought I'd briefly mention a couple of uncommon ones as well.
Mail::Box
The incredibly comprehensive Mail::Box package provides a Mail::Message class that can do, well, pretty much anything if you can figure out where in the documentation the method is. Written by the same author as XML::Compile, and similarly brilliant, insane and baroque - but also powerful and comprehensive. If nothing else is a big enough hammer, see here.
Courriel
An alternative parsing system which also comes with Courriel::Builder, which is sort of like a prettier Emailesque but without the sending code. It's a new build piece of code, though I believe the author put it into production pretty quickly, and uses Moose, which may be an issue if you want a platform wide solution - but if it works for you, you may find it more elegant than the more standard stuff.
-- mst, out.