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.