I don't doubt that I'll hit a few glitches on the way to finality, but
Email::Sender's API is getting pretty close to usable.  Check it out and have a
go:  http://github.com/rjbs/email-sender

Right now, normal usage is something like this:

  my $sender =  Email::Sender::Transport::Sendmail->new;

  my $result = eval {
    $sender->send(
      $email,
      {
        to   => '[EMAIL PROTECTED]',
        from => '[EMAIL PROTECTED]',
      },
    );
  };

  my $error = @_;

$result is either false or an Email::Sender::Success.  If it's false, $error
had better be an Email::Sender::Failure.  Every failure has a 'message' and an
array of 'recipients' and may have a 'code'.

Sometimes the failure is a ::Multi, meaning that while sending was aborted,
results were mixed.  It contains other failures.  They might all be of one
subclass of Failure (Permanent or Temporary, for example) or there might only
be one failure.  Multi will have one contained failure when, for example:

  * four out of five recipients were accepted
  * ...but the SMTP transport is set to require 100% acceptance (default)

This means that it is generally safe to say:

  $sender->send($email, $env);

...and let things fail if the email was not sent.  This won't always be true,
though, when there exist transports that are not capable of atomic transaction,
like LMTP.  They will be respond to something useful with ->does, probably.

Anyway, if you really know what you're doing, you can also:

  my $sender = E::S::T::SMTP->new({
    host => 'mx.your-isp',
    allow_partial_success => 1,
  });

  my $succ = $sender->send($email, $env);

In the event that 0><x<100% of your senders are accepted, it will NOT abort the
SMTP conversation before DATA and will return an
Email::Sender::Success::Partial, which has a 'failure' attribute that contains
a Multi.

  for my $addr ($succ->failure->recipients) {
    unsubscribe($addr);
  }

I plan to write Email::Sender::Simple at some point to provide an interface a
bit more like Email::Send's, complete with envelope defaults and true/false
values with dying reserved for void context.  Or something.  I haven't given
that much thought yet.

Please let me know if you have feedback, as I'm definitely making progres
toward calling this ready for upload (once there are docs (and more tests)).

-- 
rjbs

Reply via email to