Mail::Bulkmail v1.11 Copyright (c) 1999 James A Thomason III (jim3@psynet.net). All rights reserved. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. FAQ Just what is this thing anyway? Mail::Bulkmail is a platform independent mass-mailing module. It's designed to make mailing to your mailing lists fast and easy. So just how fast is this thing, anyway? Really fast. Really stupendously incredibly fast. The largest list that I have data on has 91,140 people on it. This list runs through to *completion* in about an hour and 43 minutes, which means that Mail::Bulkmail can process (at least) 884 messages per minute or about 53,100 per hour. So? How big were the individual messages sent out? Total data transferred is what counts, not total recipients! How right you are. 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. Am I going to see transfer speeds that fast? Maybe, maybe not. It depends on how busy your SMTP server is. If you have a relatively unused SMTP server with a fair amount of horsepower, you can easily get these speeds or beyond. If you have a relatively busy and/or low powered SMTP server, you're not going to reach speeds that fast. How much faster will Mail::Bulkmail be than my current system? This is a very tough question to answer, since it depends highly upon what your current system is. For the sake of argument, let's assume that for your current system, you open an SMTP connection to your server, send a message, and close the connection. And then repeat. Open, send, close, etc. Mail::Bulkmail will *always* be faster than this approach since it opens one SMTP connection and send 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. 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 25 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. In short, there's no way to tell how much of a speed increase you'll see. Have you benchmarked it against anything else? Not scientifically. I've heard that Mail::Bulkmail is about 4-5x faster than Listcaster from Mustang Software, but I don't have any hard numbers. If you want to benchmark it against some other system and let me know the results, it'll be much appreciated. :-) Wait a minute! You said up there that Mail::Bulkmail opens one connection and sends all the messages through. What happens if the connection is dropped midway through? Well, either something good or something bad depending on what happens. If it's something good, the server will send a 221 message (server closing) which Mail::Bulkmail should pick up and some point, realize its disconnected and then reconnect for the next message. If it's something bad, the server will just stop replying and Mail::Bulkmail will sit there forever wondering why the server won't talk to it anymore. Realistically, if your server bellyflopped and is not responding at all and won't even alert that it's disconnected, you probably have something serious to worry about. A future release will probably have a time-out option so Mail::Bulkmail will bow out and assume its disconnected after a certain period of time. What about multipart messages? (MIME attachments) I may add this in in the future, I may not. It has its benefits, but realistically multipart messages should only very rarely come up in legit bulkmail. If your attachment is all text, you should probably stick it all into the message body. If your attachment is a graphic, you'll probably bury your server with the load. You should probably be able to insert MIME into the message yourself, but you'll have to define your own headers, boundaries, etc. It *should* work just fine, but I don't know of anyone that's tried it. I'd like to send out a mass-mailing that has different From and To fields in the message and the envelope. Can I do this? Nope. Nor will you ever be able to. This is a feature that I'm never going to add into the module. I can't think of any legitimate business use where you'd want to have the message headers and envelope differ. I can, however, think of about 3,000 spam usages for this feature. Since this ability would make the module much much more attractive to spammers, it ain't gonna be added in ever. So what is it with these version numbers anyway? I'm going to *try* to be consistent in how I number the releases. The hundredths digit will indicate bug fixes, 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, it will be the same as x.ac->x.ba but on a much larger scale. Anything else you want to tell me? Sure, anything you need to know. Just drop me a message. HISTORY - 1.11 11/09/99 Banned addresses now checks entire address case insensitively instead of leaving the local part alone. Better safe than sorry. $self->fmdl is now used to split BULK_FILEMAP Various fixes suggested by Chris Nandor to make -w shut up. Changed the way to provide local maps to mail and bulkmail so it's more intuitive. - 1.10 09/08/99 Several little fixes. The module will now re-connect if it receives a 221 (connection terminated) message from the server. Fixed a potential near-infinite loop in the _valid_email routine. _valid_email now merrily strips away comments (even nested ones). :) hfm (headers from message) method added. fmdl (filemap delimiter) method added. - 1.01 09/01/99 E-mail validation and date generation bug fixes - 1.00 08/18/99 First public release onto CPAN - 0.93 08/12/99 Re-vamped the documentation substantially. - 0.92 08/12/99 Started adding a zero in front of the version name, just like I always should have Changed accessing of non-standard headers so that they have to be accessed and retrieved via the "headset" method. This is because methods cannot have non-word characters in them. From, Subject, and Precedence headers may also be accessed via headset, if you so choose. AUTOLOAD now complains loudly (setting ->error and printing to STDERR) if it's called. - 0.91 08/11/99 Fixed bugs in setting values which require validation checks. Fixed accessing of non-standard headers so that the returns are identical to every other accesor method. - 0.90 08/10/99 Initial "completed" release. First release available to general public.