Platform independent mailing list module

Mail::Bulkmail gives a fairly complete set of tools for managing mass-mailing lists. I initially wrote it because the tools I was using at the time were just too damn slow for mailing out to thousands of recipients. I keep working on it because it's reasonably popular and I enjoy it. In a nutshell, it allows you to rapidly transmit a message to a mailing list by zipping out the information to them via an SMTP relay (your own, of course). Subclasses provide the ability to use mail merges, dynamic messages, and anything else you can think of. Mail::Bulkmail 3.00 is a major major *major* upgrade to the previous version (2.05), which was a major upgrade to the previous version (1.11). My software philosophy is that most code should be scrapped and re-written every 6-8 months or so. 2.05 was released in October of 2000, and I'm writing these docs for 3.00 in January of 2003. So I'm at least 3 major re-writes behind. (philosophy is referenced in the FAQ, below) But that's okay, because we're getting it done now. 3.00 is about as backwards compatible to 2.00 as 2.00 is to 1.00. That is to say, sorta. I've tried to make a note of things where they changed, but I'm sure I missed things. Some things can no longer be done, lots are done differently, some are the same. You will need to change your code to update from 1.x or 2.x to 3.00, though. That's a given. So what's new for 3.00? Lots of stuff. Immediate changes are: * code compartmentalization * multi-server support * conf file The immediate change is that the code is now compartmentalized. Mail::Bulkmail now just handles ordinary, non-dynamic mailings. See Mail::Bulkmail::Dynamic for the merging and dynamic text abilities from the prior versions. Server connections are no longer handled directly in Mail::Bulkmail (Smtp attribute, Port attribute, etc.), there is now a separate Mail::Bulkmail::Server object to handle all of that. And everything subclasses off of Mail::Bulkmail::Object, where I have my super-methods to define my objects, some helper stuff, and so on. It's just a lot easier for me to maintain, think about it, etc. if it's all separated. It's also easier for you, the user, if you want to make changes to things. Just subclass it, tweak it, and use it. Very straightforward to modify and extend now. 2.x and below *could* do it, but it wasn't really that easy (unless you were making very trivial changes). This should rectify that. Another major change is the addition of multi-server support. See the docs in Mail::Bulkmail::Server for more information. You can still specify one SMTP relay if that's all you've got, but if you have multiple servers, Mail::Bulkmail can now load balance between them to help take the stress off. No matter what, the biggest bottleneck to all of this is network performance (both to the SMTP relay and then from the relay to the rest of the world), so i wanted to try and help alleviate that by using multiple servers. I know that some people were doing that on there own with small changes, but this allows you to do it all invisibly. And finally, finally, finally there is a conf file. Documentation on the format is in Mail::Bulkmail::Object. It's pretty easy to use. This is the conf file format that I designed for my own use (along with most of the rest of Mail::Bulkmail::Object). The software also has the ability to read multiple conf files, if so desired. So no more worrying about asking your sysadmin to tweak the values in your module somewhere up in /usr/lib/whatever Just have him create the conf file you want, or pass in your own as desired. conf_files are specified and further documented in Mail::Bulkmail::Object, in an internal array called @conf_files, right at the top of the module. To specify a universal conf file, put it in that array (or have your sysadmin do so). Alternatively, you can also add a conf_file via the conf_files accessor. Mail::Bulkmail->conf_files('/path/to/conf_file', '/path/to/other/conf_file'); #, etc. But the recommended way is to specify your conf file upon module import. use Mail::Bulkmail 3.00 "/path/to/conf/file"; In addition, there is the usual plethora of bug fixes, tweaks, clean-ups, and so on. And yes, the horrid long-standing bug in the Tz method is *fixed!* No, honest. I'm also trying a new documentation technique. The pod for a given method is now in the module by that method, as opposed to everything being bunched up at the bottom. Personally, I prefer everything being bunched up there for clarities sake. But from a maintenance point of view, spreading it all out makes my life much easier.

There is no official package available for openSUSE Leap 15.3


openSUSE Tumbleweed