From is no longer used as the Sender, as was the behavior in prior versions. Now, Mail::Bulkmail first tries to use the Sender as the Sender, and failing that, falls back on the from.

 $bulk->From('"Jim Thomason"<[email protected]>');
 print $bulk->From;

To is used if you have use_envelope set to 1. See use_envelope, below. If you are not using the envelope, then the actual email address that we are currently on is used instead and ->To is never used at all.

 $bulk->To('jimslist:;');
 print $bulk->To;

As of 3.00, ->To may contain either a valid email address or a valid group definition. A group definition is as follows (pseudo-regex):

 Groupname:(address(,address)*)?;

i.e., ``the group name'', then a colon, then an optional list of email addresses, then a semi-colon

 $bulk->To('[email protected]');
 $bulk->To('MyList:[email protected]');
 $bulk->To('MyList:;');

Are all valid addresses. Only the ->To attribute may accept group syntax emails

Sender is mainly used when speaking SMTP to the server, specifically in the RCPT TO command. The spec defines ``Sender'' as ``he who send the message'' (paraphrasing), which may not actually be who the message is from. 2.00 used the From address as the Sender.

You should specify this, but if you don't then the From value is assumed to be the sender.

 $bulk->Sender('[email protected]');
 print $bulk->Sender;

If this value is not set, then Mail::Bulkmail will place a Sender header equal to the From value.

Note that the ultimate receiving SMTP server is expected to place a Return-Path header in the message. This Return-Path value will be set to the value of the sender of the message, either ->Sender or ->From. This, in turn, will be the address that bounce backs go to. You should not set a Return-Path header yourself, because bad things will result.

Reply-To is used as the address that the user's email client should reply to, if present. If this value is not set, then Mail::Bulkmail will place a Reply-To header equal to the From value.

Note that even though the attribute is ``ReplyTo'', the header set is ``Reply-To''

 $bulk->ReplyTo('[email protected]');
 print $bulk->ReplyTo;

 $bulk->Subject("This is the list you signed up for");
 print $bulk->Subject;

A lot of people, though obviously not you, because you're reading the pod, just couldn't figure out how to send HTML messages. It's easy.

 $bulk->header("Content-type", "text/html");

But it was just too hard for most people. So I added this flag.

Here's the order:

 Check and see if ->header("Content-type") is set, if so then send it.
 Otherwise, check and see if ->HTML is true, if so, then send a content-type of text/html
   i.e., an HTML message
 Otherwise, send a content-type of text/plain
   i.e., a plaintext message

use_envelope was the coolest thing I added to Bulkmail 2.00, and is arguably still the best thing I've got here in terms of raw power in your lists.

Basically, it's like lasing a stick of dynamite. Mail::Bulkmail is fast. Mail::Bulkmail with use_envelope is mind-numbingly fast.

For the uninformed, an email message contains two parts, the message itself and the envelope. Mail servers only care about the envelope (for the most part), since that's where they find out who the message is to and from, and they don't really need to know anything else.

A nifty feature of the envelope is that you can submit multiple addresses within the envelope, and then your mail server will automagically send along the message to everyone contained within the envelope. You end up sending a hell of a lot less data across your connection, your SMTP server has less work to do, and everything ends up working out wonderfully.

There are two catches. First of all, with envelope sending turned off, the recipient will have their own email address in the ``To'' field (To: [email protected], fer instance). With the envelope on, the recipient will only receive a generic email address (``To: [email protected]'', fer instance) Most people don't care since that's how most email lists work, but you should be aware of it.

Secondly, you MUST and I mean MUST sort your list by domain. Envelopes can only be bundled up by domain, so that we send all email to a domain in one burst, all of the email to another domain in the next burst, and so on. So you need to have all of your domains clustered together in your list. If you don't, your list will still go out, but it will be a lot slower, since Mail::Bulkmail has a fair amount more processing to do when you send with then envelope. This is normally more than offset by the gains received from sending fewer messages. But with an unsorted list, you never see the big gains and you see a major slow down. Sort your lists.

 $bulk->use_envelope(0);
 print $bulk->use_envelope;

RFC 2822 recommends that all messages have no more than 80 characters in a line (78 + CRLF), but doesn't require it. if force80 is 1, then it will force a message to have only 80 characters per line. It will try to insert carriage returns between word boundaries, but if it can't, then it will cut words in half to force the limit.

Regardless of force80, be warned that RFC 2822 mandates that messages must have no more than 1000 characters per line (998 + CRLF), and that wrapping will be done no matter what. Again, it will try to wrap at word boundaries, but if it can't, it will cut words in half to force the limit.

It is recommended that you just have your message with at most 78 characters + CRLF for happiness' sake, and definitely at most 998 characters + CRLF. You may end up with extra CRLFs in your message that you weren't expecting.

If your message is not guaranteed to have only < 78 characters + CRLF per line, then it's recommended to have force80 on for full compatibility. Note that force80 will be overridden by ->Trusting('wrapping');

Okay, this is the first major change between 2.x and 3.x. 2.x had methods to connect to one server (->Smtp, ->Port, etc.). 3.x doesn't have those, and the relevent things are now in Mail::Bulkmail::Server, instead it has a list of servers.

servers should contain an arrayref of server objects. You can either create them externally yourself and pass them in in an arrayref,

 $bulk->servers([\$server, \$server2, \$server3]);

or you can create them in your conf file. See the Mail::Bulkmail::Object for more info on the format of the conf file, and Mail::Bulkmail::Server for the attributes to specify.

servers will automatically be populated with a list of all servers in the server_list in the conf file if you don't specify anything, so you really don't need to worry about it.

If you'd rather use a different server_file, then pass the server_file flag to the constructor:

 $bulk = Mail::Bulkmail->new(
        'server_file' => '/path/to/server_file'
 );

That will override and ignore the server_file in any conf file, so use it with caution.

Realistically, though, just let the program populate in the values of the servers you specified in the conf file and don't worry about this.

Be warned that servers will be populated by the constructor if you do not populate servers at object creation. You may still change servers later (before you begin mailing), but there is the slight performance hit to initialize all of the server objects and then throw them away. This doesn't affect mailing speed in anyway, it'll just take a little longer to get started than it should.

 $bulk->Message('Hi there. You're on my mailing list');
 print $bulk->Message;

Don't put any headers in your Message, since they won't be transmitted as headers. Instead they will show up in the body of your message text. Use the ->header method instead for additional headers

This mutator is known to be able to return:

 MB020 - could not open file for message
 MB021 - could not close file for message
 MB022 - invalid headers from message

message_from_file allows you to load your message in from a file. If message_from_file is set to 1, then the value passed to ->Message() will be assumed to be a path to a file on disk. That file will be openned in read mode (if possible), read in, and stored as your message. Note that your entire message text will be read into memory - no matter how large the message may be.

This is simply a shortcut so that you don't have to open and read in the message yourself.

NOTE This is a bit picky, to put it mildly. No doubt you've read that the constructor actually is taking in its arguments in an array, not a hash. So they're parsed in order, which means you need pass in message_from_file before Message. i.e., this will work:

 $bulk = Mail::Bulkmail->new(
        'message_from_file' => 1,
        'Message'                       => '/path/to/message.txt',
 );

But this will not:

 $bulk = Mail::Bulkmail->new(
        'Message'                       => '/path/to/message.txt',
        'message_from_file' => 1,
 );

Ditto for using the mutators. Turn on the flag, i<then> specify the Message.

headers_from_message allows you to specify mail headers inside your message body. You may still specify additional headers in the traditional manner.

Note that if you change the value of ->Message (not recommended, but there are times you may want to do so), then any headers that were previously set via headers_from_message will be wiped out.

any headers specified in the message will be set when you call ->Message.

If a string literal, then Mail::Bulkmail will attempt to open that file as your list:

 $bulk->LIST("/path/to/my/list");

If a globref, it is assumed to be an open filehandle:

 open (L, "/path/to/my/list");
 $bulk->LIST(\*L);

if a coderef, it is assumed to be a function to return your list, or undef when it is done:

 sub L {return $listquery->execute()};  #or whatever your code is
 $bulk->LIST(\&L);

The coderef will receive the bulkmail object itself as an argument.

if an arrayref, it is assumed to be an array containing your list:

 my $list = [qw([email protected] [email protected])];
 $bulk->LIST($list);

Use whichever item is most convenient, and Mail::Bulkmail will take it from there.

BAD may be either a coderef, globref, arrayref, or string literal.

If a string literal, then Mail::Bulkmail will attempt to open that file (in append mode) as your log:

 $bulk->BAD("/path/to/my/bad.addresses");

If a globref, it is assumed to be an open filehandle in append mode:

 open (B, ">>/path/to/my/bad.addresses");
 $bulk->BAD(\*L);

if a coderef, it is assumed to be a function to call with the address as an argument:

 sub B { print "BAD ADDRESS : ", $_[1], "\n"};  #or whatever your code is
 $bulk->BAD(\&B);

The coderef will receive two arguments. The first is the bulkmail object itself, and the second is the data in the form that it was returned from the LIST attribute.

if an arrayref, then bad addresses will be pushed on to the end of it

 $bulk->BAD(\@bad);

Use whichever item is most convenient, and Mail::Bulkmail will take it from there.

GOOD may be either a coderef, globref, arrayref, or string literal.

If a string literal, then Mail::Bulkmail will attempt to open that file (in append mode) as your log:

 $bulk->GOOD("/path/to/my/good.addresses");

If a globref, it is assumed to be an open filehandle in append mode:

 open (B, ">>/path/to/my/good.addresses");
 $bulk->GOOD(\*B);

if a coderef, it is assumed to be a function to call with the address as an argument:

 sub G { print "GOOD ADDRESS : ", $_[1], "\n"}; #or whatever your code is
 $bulk->GOOD(\&G);

The coderef will receive two arguments. The first is the bulkmail object itself, and the second is the data in the form that it was returned from the LIST attribute.

if an arrayref, then bad addresses will be pushed on to the end of it

 $bulk->GOOD(\@good);

Use whichever item is most convenient, and Mail::Bulkmail will take it from there.

Please note that ->GOOD only says that the address was initially accepted for delivery. It could later fail while transmitting the email address, or it could be an valid but non-existent address that bounces later. It is up to the end user to inspect your error logs to make sure no errors occurred, and look for (and weed out) bounces or other failures later.

server_class is used by the constructor to create the server list to populate into ->servers, ->servers is not populated in the constructor.

By default, this should probably be Mail::Bulkmail::Server, to allow mailing. Another useful value is Mail::Bulkmail::Dummy See Mail::Bulkmail::Server and Mail::Bulkmail::Dummy for more information on how to create those objects.

Also, if you write your own server implementation, this would be where you'd hook it into Mail::Bulkmail

So that's where Trusting comes in to play. If you set a Trusting value, then certain tests will be skipped. Use this at your own risk. If you tell Mail::Bulkmail to be Trusting, then it won't verify addresses or to make sure your list is under 1,000 characters per line. So if you're Trusting and you pass in bad data, it's your funeral. If there is any chance of invalid data, then don't be Trusting. If you're *positive* there's nothing wrong, then you may be Trusting.

Trusting values are set one as key/value pairs.

 $bulk->Trusting("email" => 1);
 $bulk->Trusting("wrapping" => 1);
 $bulk->Trusting("default" => 1);

And read back with just the key:

 $bulk->Trusting("email");
 $bulk->Trusting("wrapping");
 $bulk->Trusting("default");

default is used as a fall back. So if you didn't specify a Trusting value for ``email'', for example, it will use the ``default'' value. Note that the default is only used if a value is not specified.

 $bulk->Trusting("default" => 1);
 print $bulk->Trusting("email");        #prints 1
 print $bulk->Trusting("default");      #prints 1
 $bulk->Trusting("default" => 0);
 print $bulk->Trusting("email");        #prints 0
 print $bulk->Trusting("default");      #prints 0
 $bulk->Trusting("email" => 1);
 print $bulk->Trusting("email");        #prints 1
 print $bulk->Trusting("default");      #prints 0
 $bulk->Trusting("email" => 0);
 $bulk->Trusting("default" => 0);
 print $bulk->Trusting("email");        #prints 0
 print $bulk->Trusting("default");      #prints 1

You may also directly set all values with the integer short cut.

banned may be either a coderef, globref, arrayref, or string literal.

If a string literal, then Mail::Bulkmail will attempt to open that file (in append mode) as your log:

 $bulk->banned("/path/to/my/banned.addresses");

If a globref, it is assumed to be an open filehandle in append mode:

 open (B, ">>/path/to/my/banned.addresses");
 $bulk->banned(\*B);

files should contain one entry per line, each entry being an email address or a domain. For example:

 [email protected]
 jimandkoka.com
 [email protected]
 bar.com

if a coderef, it is assumed to be a function to return your banned list:

 sub B {return $bannedquery->execute()};        #or whatever your code is
 $bulk->banned(\&B);

The function should return one entry per execution, either an address or a domain.

if an arrayref, then it's an array of banned addresses and domains

 $bulk->banned([qw([email protected] jimandkoka.com)]);

The arrayref can contain email addresses and domains.

Use whichever item is most convenient, and Mail::Bulkmail will take it from there.

Once banned has been populated, the values are stored internally in a hashref.

Precedence must be either:

 * list (default) - a mailing list
 * bulk - bulk mailing of some type
 * junk - worthless test message.

You can use an alternate Precedence if you set Trusting to 0. But seriously, there's *no* reason to do that. Keeping the appropriate precedence will help the servers on the internet route your message as well as the rest of the email out there more efficiently. So don't be a jerk, and leave it as one of those three.

This method is known to be able to return:

 MB001 - invalid precedence

Another thing you won't need to worry about.

In a nutshell, the constructor accepts a hash with name/value pairs corresponding to attributes and attribute values.

So that:

 my $bulk = Mail::Bulkmail->new(
        'LIST' => './list.txt',
        'Message' => "This is my message!",
        'HTML' => 0
 ) || die Mail::Bulkmail->error;

is the same as:

 my $bulk = Mail::Bulkmail->new() || die Mail::Bulkmail->error;

 $bulk->LIST("./list.txt");
 $bulk->Message("This is my message!");
 $bulk->HTML(0);

*technically* it's not exactly the same, since the constructor will fail with an error if your attribute calls return undef, but it's close enough.

It is recommend to tack on an || die after your new() calls, to make sure you're alerted if your object isn't created.

 my $bulk = Mail::Bulkmail->new() || die Mail::Bulkmail->error();

Otherwise, you won't be alerted if your object isn't created.

Upon creation, Mail::Bulkmail will first iterate through the conf file and populate all of the attributes defined in the conf file into your object. It will then iterate through the values you passed to the constructor and mutate the attributes to those values. If you don't pass any arguments to the constructor, it still gets the default values in the conf file. Values passed to the constructor always override values specified in the conf file

There is one special constructor flag, ``server_file'', which does not correspond to an attribute or method. ``server_file'' is used to override the server_file specified in the conf file.

If you pass a key/value pair to the constructor that doesn't have a corresponding attribute, then it is assuming you are setting a new header.

 my $bulk = Mail::Bulkmail->new('foo' => 'bar');

 is the same as:

 my $bulk = Mail::Bulkmail->new();
 $bulk->header('foo' => 'bar');

This method is known to be able to return:

 MB003 - could not use server class

 $bulk->header('X-Header', "My header value");
 print $bulk->header('X-Header'); #prints "My header value"

Use this to set any additional headers that you would like.

Note that you can't use this to bypass validation checks.

 $bulk->Header("Subject", "My Subject") will internally change into $bulk->Subject("My Subject");

There's no benefit to doing that, it'll just slow you down.

If you call header with no values, it returns the _headers hashref, containing key value pairs of header => value

This method is known to be able to return:

 MB004 - cannot set CC or BCC header
 MB005 - invalid header

 print $bulk->valid_email('[email protected]')->{'extracted'};                                 #prints [email protected]
 print $bulk->valid_email('"Jim Thomason"<[email protected]>')->{'extracted'}; #prints [email protected]
 print $bulk->valid_email('[email protected]')->{'extracted'};                                 #prints [email protected]
 print $bulk->valid_email('jim@@jimandkoka.com');                                                               #prints nothing (invalid address)

Note that as of v3.10, valid_email returns a hash with two keys upon success. 'original' contains the address as you passed it in, 'extracted' is the address person that was yanked out.

 {
        'original'      => 'Jim Thomason'<[email protected]',
        'extracted'     => '[email protected]',
 }

Given an invalid address, returns undef and sets an error as always.

If Trusting is 1, then valid_email only removes comments and extracts the address spec part of the email. i.e., if your address is

 some name<[email protected]>

It'll just return [email protected]. This is required, because valid_email is also where the address spec is validated. As of 3.00, valid_email should be fully RFC 2822 compliant, except where otherwise noted (such as forcing a valid domain as per RFC 2821). And also as of 3.00, Trusting is even more trusting and has a faster return. There are speed reasons to have Trusting set to 1 (such as not having to check the validity of each email address), but if you do that then you must be positive that all of your addresses are 100% valid. If you have any addresses in your list that are invalid and Trusting is set to 1, then you may have bad things happen. You have been warned.

This method is known to be able to return:

 MB006 - no email address
 MB007 - invalid email address

 print $self->lc_domain('[email protected]');  #prints [email protected]
 print $self->lc_domain('[email protected]');  #prints [email protected]
 print $self->lc_domain('[email protected]');  #prints [email protected]

This method is known to be able to return:

 MB009 - cannot lowercase domain w/o email

 $bulk->setDuplicate($email);

once an address is set as a duplicate, then isDuplicate will return a true value for that address

 print $bulk->isDuplicate($email2);     #prints 0
 $bulk->setDuplicate($email2);
 print $bulk->isDuplicate($email2);     #prints 1

This is mainly used internally, but I decided to make it external anyway.

setDuplicate will always return 1 if you have Trusting('duplicates') set.

Be warned that there is a performance hit to using this, since it will eventually store your entire list inside an entire hashref in memory. You're in much better shape if you weed out the duplicates in advance and then set Trusting('duplicates' => 1) to skip the check and skip storing the values in the hashref.

But if you have to use this to weed out values, go to town.

This method is known to be able to return:

 MB010 - cannot set duplicate w/o email
=cut

sub setDuplicate {         my $self        = shift;
        my $email       = shift || return $self->error(``Cannot set duplicate without email'', ``MB010'');

        return 1 if $self->Trusting('duplicates');

        if (! $self->Trusting('banned')) {
                $self->_duplicates->{lc $email} = 1;
        }
        else {
                $self->_duplicates->{$self->lc_domain($email)} = 1;
        };

        return 1;
};

 print $bulk->isDuplicate($email); #prints 0 or 1

once an address is set as a duplicate, then isDuplicate will return a true value for that address

 print $bulk->isDuplicate($email2);     #prints 0
 $bulk->setDuplicate($email2);
 print $bulk->isDuplicate($email2);     #prints 1

This is mainly used internally, but I decided to make it external anyway.

isDuplicate will always return 0 if you have Trusting('duplicates' => 1) set.

Be warned that there is a performance hit to using this, since it will eventually store your entire list inside an entire hashref in memory. You're in much better shape if you weed out the duplicates in advance and then set Trusting('duplicates' => 1) to skip the check and skip storing the values in the hashref.

But if you have to use this to weed out values, go to town.

 $bulk->isBanned($email);       #prints 0 or 1
 $bulk->isBanned($domain);      #prints 0 or 1

->isBanned goes off of the values populated via the banned attribute

This is mainly used internally, but I decided to make it external anyway.

->nextServer will iterate over the ->servers array and return the next valid, connected server. If a server is not connected, ->nextServer will try to make it connect. If the server cannot connect, it will go on to the next one.

Once all servers are exhausted, it returns undef.

nextServer is called if the present server object has reached one of its internal limits. See Mail::Bulkmail::Server for more information on server limits.

This method is known to be able to return:

 MB011 - No servers (->servers array is empty)
 MB012 - No available servers (cannot connect to any servers)

extracts the email address from the data passed in the bulkmail object. Not necessary in Mail::Bulkmail, since all it does in here is reflect through the same value that is passed.

This will be very important in a subclass, though. getNextLine might return values beyond just simple email addresses in subclasses, hashes, objects, whatever. You name it. In that case, extractEmail is necessary to find the actual email address out of whatever it is that was returned from getNextLine().

But here? Nothing to worry about.

This method is known to be able to return:

 MB013 - cannot extract email w/o email

extracts the sender of the message from the data passed in the bulkmail object. Not necessary in Mail::Bulkmail, since all it does in here is return either the Bulkmail object's Sender or its From field.

This will be very important in a subclass, though. getNextLine might return values beyond just simple email addresses in subclasses - hashes, object, whatever. You name it. In that case, extractEmail is necessary to find the actual email address out of whatever it is that was returned from getNextLine().

But here? Nothing to worry about.

extracts the Reply-To of the message from the data passed in the bulkmail object. Not necessary in Mail::Bulkmail, since all it does in here is return either the Bulkmail object's Sender or its From field.

This will be very important in a subclass, though. getNextLine might return values beyond just simple email addresses in subclasses - hashes, object, whatever. You name it. In that case, extractEmail is necessary to find the actual email address out of whatever it is that was returned from getNextLine().

But here? Nothing to worry about.

Here, the whole method:

 sub preprocess {
        my $self        = shift;
        my $val         = shift;

        return ref $val ? $val : \$val;
 };

But in a subclass, this may be much more important. Making sure that your data is uniform or valid, that particular values are populated, additional tests, whatever.

You'll never need to call buildHeaders unless you're subclassing, in which case you may want to override this method with a new routine to build headers in a different fashion.

This method is called internally by ->bulkmail and ->mail otherwise and is not something you need to worry about.

The first time buildHeaders is called, it populates _cached_headers so as not to have to go through the processing of rebuilding the headers for each address in your list.

This method is known to be able to return:

 MB014 - no From address
 MB015 - no To address

You'll never need to call buildMessage unless you're subclassing, in which case you may want to override this method with a new routine to build your message in a different fashion.

This method is called internally by ->bulkmail and ->mail otherwise and is not something you need to worry about.

This method is known to be able to return:

 MB016 - ->Message is not defined

 $bulk->bulkmail();

will take your list, iterate over it, build all your message headers, build your message, and email to everyone on your list, iterating through all of your servers, log all relevant information, and send you happily on your way.

Easy as pie. You don't even need to worry about it if you subclass things, because you'd just need to override buildHeaders, buildMessage, getNextLine and extractEmail at most.

This method is known to be able to return:

 MB017 - duplicate email
 MB018 - banned email
 MB019 - invalid sender/from

 $bulk->mail('[email protected]');

Sends your Message as defined in ->Message to [email protected]. You can also optionally pass in a server as the second argument.

 $bulk->mail('[email protected]', $server);

is the same as above, but relays through that particular server. if you don't pass a server, if tries to bring the next one in via ->nextServer

->mail wants its first argument to be whatever would be normally returned by a call to ->getNextLine($bulk->LIST); Right now, that's just a single email address. But that may change in a subclass. So, if you're operating in a subclass, just remember that you may be able (or required) to pass additional information in your first argument.

This method is known to be able to return:

 MB018 - banned email
 MB019 - invalid sender/from address

But, basically, Really fast. Really stupendously incredibly fast.

The last official big benchmark I ran was with v1.11. That list runs through to completion in about an hour and 43 minutes, which meant that Mail::Bulkmail 1.11 could process (at least) 884 messages per minute or about 53,100 per hour.

The last message sent out was 4,979 bytes. 4979 x 91,140 people is 453,786,060 bytes of data transferred, or about 453.786 megabytes in 1 hour and 43 minutes. This is a sustained transfer rate of about 4.4 megabytes per minute, or 264.34 megabytes per hour.

So then, that tells you how fast the software was back in 1999, 2 major revisions ago. But, invariably, you want to know what it's like *now*, right? Well, I'll do my best to guesstimate it. However, these tests were not run through an SMTP relay, they were run using DummyServer in v3.0 and a hacked 2.05 and (severely) hacked 1.11 to insert similar functionality. All data was sent to /dev/null.

Tests were performed on a 5,000 recipient list.

First of all, with envelope sending turned off (average times):

 v1.11......20 seconds  (1.00)
 v3.00......23 seconds  (1.15)
 v2.05......50 seconds  (2.5)

1.11 was the speed champ in this case, but that's not surprising considering the fact that it did a lot less processing than the other 2. The fact that 3.00 almost catches it should speak to the improvement in the code in the 3.x release. 2.05 was...clunky.

Now then, there's another thing to consider, envelope sending. With envelope sending turned on (average times):

 v3.00......12 seconds  (1.00)
 v2.05......19 seconds  (1.58)
 v1.11......22 seconds  (1.83)

This is with an envelope_limit of 100. So the supposed speed gains that envelope sending were supposed to see in 2.05 never really materialized. While doing these tests, I discovered a bug in 2.05's use_envelope routine that would sometimes cause it to slow down substantially. 3.00, with a new routine, was never affected. Incidentally, Bulkmail 2.05 will be faster with trivially low envelope_limits. Bulkmail 3.00 becomes faster with an envelope_limit greater than 2.

There is also mail merging (filemapping in 1.x) that should be considered. This was benchmarked with Mail::Bulkmail::Dynamic for 3.00. A simple mail merge with one item was used, and one global item, read from a file, and split on a delimiter (since this was the only functionality that v1.x had). With mail merge turned on (average times):

 v1.11......20 seconds  (1.00)
 v3.00......35 seconds  (1.75)
 v2.05......40 seconds  (2.00)

And finally, 2.x and 3.x have both had the capability to generate a dynamic message. This is a minimal test with one dynamic message element, one dynamic header, and a mail merge into the dynamic element:

 v3.00......36 seconds  (1.00)
 v2.05......44 seconds  (1.22)

So 3.x is usually faster than 2.x, but sometimes slower than 1.x. Which makes sense, again due to the added features in 2.x and 3.x.

These tests do not take into account the multi-server capability introduced in 3.00.

Also note that these speeds are only measuring the time it takes to get from Mail::Bulkmail to your SMTP relay. There are no measurements reflecting how long it may take your SMTP relay to send the data on to the recipients on your list.

Mail::Bulkmail will always be faster than this approach since it opens one SMTP connection and sends every single message across on that one connection. How much faster depends on how busy your server is as well as the size of your list. The connection will only be closed if you have an error or if you reach the max number of messages to send in a given server connection.

Lets assume (for simplicity's sake) that you have a list of 100,000 people. We'll also assume that you have a pretty busy SMTP server and it takes (on average) 25 seconds for the server to respond to a connection request. We're making 100,000 connection requests (with your old system). That means 100,000 x 25 seconds = almost 29 days waiting just to make connections to the server! Mail::Bulkmail makes one connection, takes 25 seconds for it, and ends up being 100,000x faster!

But, now lets assume that you have a very unbusy SMTP server and it responds to connection requests in .003 seconds. We're making 100,000 connection requests. That means 100,000 x .0003 seconds = about 5 minutes waiting to make connections to the server. Mail::Bulkmail makes on connection, takes .0003 seconds for it, and ends up only being 1666x faster. But, even though being 1,666 times faster sounds impressive, the world won't stop spinning on its axis if you use your old system and take up an extra 5 minutes.

And this doesn't even begin to take into account systems that don't open and close SMTP connections for each message.

This also doesn't take into account the load balancing between multiple SMTP relays that 3.00 can perform.

In short, there's no way for me to tell how much faster (if at all) it'll be. Try it and find out.

If you want to benchmark it against some other system and let me know the results, it'll be much appreciated. :-)

So your SMTP server must be configured properly to allow you to relay your messages out. It is recommended that this machine be kept behind a firewall for security reasons. Make sure that it's configured properly so it's not an open relay. Ask your SysAdmin for help.

Until then? You can always do the MIME encoding yourself, set your own headers, etc. It's perfectly fine to do it yourself, but you will have to do it yourself for now.

Anyway, you're more than free to subclass and over-ride things with ``standard'' modules if you'd like. ou can make your own server implementation using Net::SMTP, or your own dynamic message system using Text::Template, or whatever else. Feel free to use the standards if you'd prefer.

Me? I enjoy re-inventing wheels, so I'll continue to do so.

The hundredths digit will indicate bug fixes, minor behind-the-scenes changes, etc.

The tenths digit will indicate new and/or better functionality, as well as some minor new features.

The ones digit will indicate a major new feature or re-write.

Basically, if you have x.ab and x.ac comes out, you want to get it guaranteed. Same for x.ad, x.ae, etc.

If you have x.ac and x.ba comes out, you'll probably want to get it. Invariably there will be bug fixes from the last ``hundredths'' release, but it'll also have additional features. These will be the releases to be sure to read up on to make sure that nothing drastic has changes.

If you have x.ac and y.ac comes out, you'll want to do research before upgrading. I break things, I lose backwards compatibility, I change stuff around a lot. Just my nature. Porting from one major release to the next is pretty straightforward, but there's still work to be done on your part - it won't just be a drop in replacement. And, depending upon your list and what options you're using, you may or may not see any benefit to upgrading. Read the docs, ask me questions, and test test test.

Don't get me wrong, I'm not going to intentially *try* to make things not backwards compatible, but if I come up with what I think is a better way of doing things, I'm going to go with it. And I don't like to pollute modules with a lot of cruft bridgeworks for backwards compatibility. This thing is huge enough as is without having to worry about making sure internal band-aids work.

If this'll be a problem, then don't upgrade.

When using dynamic_header_data, you can no longer set a default header to be used if no header is defined for the individual user. This will also probably return in the future.

local merges no longer exist. You only have global merges and individual ones.

It will now date all messages to the time of the first sent message.

You can no longer externally load in a list of duplicates. Come on, did *anybody* ever actually do that?

The issue here is that (say it with me now), you can't bulkmail because the To header hasn't been set. If you're using envelope sending (on by default in Mail::Bulkmail), then you have to specify an address to set in the To: header of the message. This is specified via the ->To accessor.

 $bulk->To("[email protected]");

So, specify the To header, and then you'll be fine.