Yet Another Attempt to Simplify Sending Emails

After relaunching the ANAIO website (http://ana.io/ - shameless plug) and admiring how clean and succinct the MVC code was, I was pretty frustrated with the lengths that I needed to go through to configure and send a single email.

Now I'm aware of how we all feel about PHP, but every-time I see an app using mail(...) and it just works I get a little green with envy. So after launching the site (and completing some client work -of course-), I decided to try to reduce sending emails from an application to a single statement.

Making wild authoritarian assumptions about *most* development use-cases, I've concluded that most developers don't need to know whether an email was delivered and whether it passed of failed, we only really care about validating the message and storing it somewhere.
 

And thus the Eventual Email Delivery System sprung forth. Email::Sender::Server does what most application developers need, simply. It sends emails in non blocking fashion. It validates messages, stores them in a message queue and sends them in the order received. You also get a queryable email store and the ability to troubleshoot any problems that may have occurred sending the email(s).

Sending Email is Easy're:

By default ESS operates out of the dist's share folder but you can create a new system anywhere.

This system is still very much a work in-progress.... Feedback welcome, dickishness is not. Enjoy :)

6 Comments

You could actually make it a bit easier:

use Email::Sender::Server; # or "use Email::Sender::Server 'mail';"
mail($to, $subject, $message);

Also, it would be cool if you could either link to the module or state that it's not released.

Steve Yegge is long-winded, but he eventually gets to a good point in "Execution in the Kingdom of Nouns". Perl had the misfortune to come of age while Java was trendy, so lots of code suffers from "arrow-new disease":

$thing = StuffDoer->new();
$result = $thing->doStuff();
# instead of
$result = do_stuff();

A reminder, PHP's mail() interface is simple but it encourages insecure practice. The fourth argument $additional_headers is specified as a string that gets printed directly to the sendmail/SMTP DATA, so a malicious attacker can trick a program, like a web contact form, to insert extra headers and body. For example, setting $from to "someone\@example.com\nTo: victim@example.org\n\nSpam payload...". This type of attack was used a lot by spammers a few years ago.

If we want to mimic PHP's mail(), the $additional_headers should be be a hashref, or even better an arrayref, a la PSGI.

Also, although I (have the misfortune of having to) use PHP almost everyday, I can never remember which arguments are which :-)

Personally, I think email is hard. And were I to create a simple interface for sending email, I would use some established module like Email::Sender::Simple, or perhaps write something like Email::Sender::Simpler to make it even simpler (as the incantation for Email::Sender::Simple is not exactly one or two lines).

Also, I would probably let the MTA handle the queueing, but perhaps you have a different use case.

Leave a comment

About Al Newkirk

user-pic ... proud Perl hacker, ask me anything!