sourCEntral - mobile manpages

pdf

Email::Stuffer

NAME

Email::Stuffer − A more casual approach to creating and sending Email:: emails

VERSION

version 0.014

SYNOPSIS

  # Prepare the message
  my $body = <<'AMBUSH_READY';
  Dear Santa
  I have killed Bun Bun.
  Yes, I know what you are thinking... but it was actually a total accident.
  I was in a crowded line at a BayWatch signing, and I tripped, and stood on
  his head.
  I know. Oops! :/
  So anyways, I am willing to sell you the body for $1 million dollars.
  Be near the pinhole to the Dimension of Pain at midnight.
  Alias
  AMBUSH_READY
  # Create and send the email in one shot
  Email::Stuffer−>from     ('cpan AT ali DOT as'             )
                −>to       ('santa AT northpole DOT org'     )
                −>bcc      ('bunbun AT sluggy DOT com'       )
                −>text_body($body                     )
                −>attach_file('dead_bunbun_faked.gif' )
                −>send;

DESCRIPTION

The basics should all work, but this module is still subject to name and/or API changes

Email::Stuffer, as its name suggests, is a fairly casual module used to stuff things into an email and send them. It is a high-level module designed for ease of use when doing a very specific common task, but implemented on top of the light and tolerable Email:: modules.

Email::Stuffer is typically used to build emails and send them in a single statement, as seen in the synopsis. And it is certain only for use when creating and sending emails. As such, it contains no email parsing capability, and little to no modification support.

To re-iterate, this is very much a module for those "slap it together and fire it off" situations, but that still has enough grunt behind the scenes to do things properly.

Default Transport
Although it cannot be relied upon to work, the default behaviour is to use "sendmail" to send mail, if you don’t provide the mail send channel with either the "transport" method, or as an argument to "send".

(Actually, the choice of default is delegated to Email::Sender::Simple, which makes its own choices. But usually, it uses "sendmail".)

Why use this?
Why not just use Email::Simple or Email::MIME? After all, this just adds another layer of stuff around those. Wouldn’t using them directly be better?

Certainly, if you know EXACTLY what you are doing. The docs are clear enough, but you really do need to have an understanding of the structure of MIME emails. This structure is going to be different depending on whether you have text body, HTML, both, with or without an attachment etc.

Then there’s brevity... compare the following roughly equivalent code.

First, the Email::Stuffer way.

  Email::Stuffer−>to('Simon Cozens<simon AT somewhere DOT jp>')
                −>from('Santa AT northpole DOT org')
                −>text_body("You've been good this year. No coal for you.")
                −>attach_file('choochoo.gif')
                −>send;

And now doing it directly with a knowledge of what your attachment is, and what the correct MIME structure is.

  use Email::MIME;
  use Email::Sender::Simple;
  use IO::All;
  Email::Sender::Simple−>try_to_send(
    Email::MIME−>create(
      header => [
          To => 'simon AT somewhere DOT jp',
          From => 'santa AT northpole DOT org',
      ],
      parts => [
          Email::MIME−>create(
            body => "You've been a good boy this year. No coal for you."
          ),
          Email::MIME−>create(
            body => io('choochoo.gif'),
            attributes => {
                filename => 'choochoo.gif',
                content_type => 'image/gif',
            },
         ),
      ],
    );
  );

Again, if you know MIME well, and have the patience to manually code up the Email::MIME structure, go do that, if you really want to.

Email::Stuffer as the name suggests, solves one case and one case only: generate some stuff, and email it to somewhere, as conveniently as possible. DWIM, but do it as thinly as possible and use the solid Email:: modules underneath.

METHODS

As you can see from the synopsis, all methods that modify the Email::Stuffer object returns the object, and thus most normal calls are chainable.

However, please note that "send", and the group of methods that do not change the Email::Stuffer object do not return the object, and thus are not chainable.

new
Creates a new, empty, Email::Stuffer object.

You can pass a hashref of properties to set, including:

to

from

cc

bcc

subject

text_body

html_body

transport

header_names
Returns, as a list, all of the headers currently set for the Email For backwards compatibility, this method can also be called as B[headers].

parts
Returns, as a list, the Email::MIME parts for the Email

header $header => $value
Sets a named header in the email. Multiple calls with the same $header will overwrite previous calls $value.

to $address
Sets the To: header in the email

from $address
Sets the From: header in the email

cc $address
Sets the Cc: header in the email

bcc $address
Sets the Bcc: header in the email

subject $text
Sets the Subject: header in the email

text_body $body [, $header => $value, ... ]
Sets the text body of the email. Unless specified, all the appropriate headers are set for you. You may override any as needed. See Email::MIME for the actual headers to use.

If $body is undefined, this method will do nothing.

html_body $body [, $header => $value, ... ]
Set the HTML body of the email. Unless specified, all the appropriate headers are set for you. You may override any as needed. See Email::MIME for the actual headers to use.

If $body is undefined, this method will do nothing.

attach $contents [, $header => $value, ... ]
Adds an attachment to the email. The first argument is the file contents followed by (as for text_body and html_body) the list of headers to use. Email::Stuffer should TRY to guess the headers right, but you may wish to provide them anyway to be sure. Encoding is Base64 by default.

attach_file $file [, $header => $value, ... ]
Attachs a file that already exists on the filesystem to the email. "attach_file" will auto-detect the MIME type, and use the file’s current name when attaching.

transport

  $stuffer−>transport( $moniker, @options )

or

  $stuffer−>transport( $transport_obj )

The "transport" method specifies the Email::Sender transport that you want to use to send the email, and any options that need to be used to instantiate the transport. $moniker is used as the transport name; if it starts with an equals sign ("=") then the text after the sign is used as the class. Otherwise, the text is prepended by "Email::Sender::Transport::". In neither case will a module be automatically loaded.

Alternatively, you can pass a complete transport object (which must be an Email::Sender::Transport object) and it will be used as is.

email
Creates and returns the full Email::MIME object for the email.

as_string
Returns the string form of the email. Identical to (and uses behind the scenes) Email::MIME−>as_string.

send
Sends the email via Email::Sender::Simple.

On failure, returns false.

send_or_die
Sends the email via Email::Sender::Simple.

On failure, throws an exception.

COOKBOOK

Here is another example (maybe plural later) of how you can use Email::Stuffer’s brevity to your advantage.

Custom Alerts

  package SMS::Alert;
  use base 'Email::Stuffer';
  sub new {
    shift()−>SUPER::new(@_)
           −>from('monitor AT my DOT website')
           # Of course, we could have pulled these from
           # $MyConfig−>{support_tech} or something similar.
           −>to('0416181595 AT sms DOT gateway')
           −>transport('SMTP', { host => '123.123.123.123' });
  }

  package My::Code;
  unless ( $Server−>restart ) {
          # Notify the admin on call that a server went down and failed
          # to restart.
          SMS::Alert−>subject("Server $Server failed to restart cleanly")
                    −>send;
  }

TO DO

Fix a number of bugs still likely to exist

Write more tests.

Add any additional small bit of automation that isn’t too expensive

SEE ALSO

Email::MIME, Email::Sender, <http://ali.as/>

AUTHORS

Adam Kennedy <adamk AT cpan DOT org>

Ricardo SIGNES <rjbs AT cpan DOT org>

CONTRIBUTORS

adam <adam@88f4d9cd−8a04−0410−9d60−8f63309c3137>

adamk AT cpan DOT org <adamk AT cpan DOT org@88f4d9cd−8a04−0410−9d60−8f63309c3137>

adam@phase−n.com <adam@phase−n.com@88f4d9cd−8a04−0410−9d60−8f63309c3137>

Aristotle Pagaltzis <pagaltzis AT gmx DOT de>

Arthur Axel ’fREW’ Schmidt <frioux AT gmail DOT com>

Chase Whitener <chase DOT whitener AT infotechfl DOT com>

CosmicNet <webmaster AT cosmicperl DOT com>

John Napiorkowski <jjn1056 AT yahoo DOT com>

Kevin Tew <tewk AT tan DOT tewk DOT com>

Kieren Diment <kd AT fenchurch DOT local>

Kris Matthews <krismatth AT icloud DOT com>

Kris Matthews <kris AT tigerlms DOT com>

Manni Heumann <github AT lxxi DOT org>

Ross Attrill <ross DOT attrill AT gmail DOT com>

tokuhirom <tokuhirom AT gmail DOT com>

COPYRIGHT AND LICENSE

This software is copyright (c) 2004 by Adam Kennedy and Ricardo SIGNES.

This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.

pdf