Free mail bulkmail software for linux

Mail::Bulkmail is a platform independent mailing list module.

SYNOPSIS

use Mail::Bulkmail /path/to/conf.file

my $bulk = Mail::Bulkmail->new(
"LIST" => "~/my.list.txt",
"From" => "Jim Thomason" ,
"Subject" => "This is a test message",
"Message" => "Here is my test message"
) || die Mail::Bulkmail->error();

$bulk->bulkmail() || die $bulk->error;

Dont forget to set up your conf file!

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 its 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 Im writing these docs for 3.00 in January of 2003. So Im at least 3 major re-writes behind. (philosophy is referenced in the FAQ, below)

But thats okay, because were 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. Ive tried to make a note of things where they changed, but Im 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. Thats a given.

So whats 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.
Its just a lot easier for me to maintain, think about it, etc. if its all separated. Its 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 wasnt 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 thats all youve 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. Its 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.
Im 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.

Mail::LMLM is a list of Mailing Lists Manager.

SYNOPSIS

use Mail::LMLM;

my $renderer =
Mail::LMLM->new(
extra-classes => %extra_mailing_list_classes,
title => "List of the Foo Mailing Lists",
headline => "Foo Mailing Lists",
lists => @lists,
prolog => &prolog,
epilog => &epilog,
);

$renderer->render();

The Mail::LMLM module allows users to easily manage HTML directories of mailing lists of various mailing list managers and hosts.

To use it create a new module of type Mail::LMLM with a new method, while initializing it with the list of mailing lists (in order of listing), and other parameters. Then, invoke the render() function to create the HTML files within the current directory.

Mail::QmailRemoteXS is a lightweight C-code (XS) SMTP send function based on Qmails qmail-remote.

SYNOPSIS

use Mail::QmailRemoteXS;

$ret = Mail::QmailRemoteXS::mail($to_domain,$from_address,$to_address,$msg,$helo,$net_timeout,$net_timeoutconnect);

This module provides a single function mail that sends an email via SMTP. It uses an XS implementation of Qmails qmail-remote binary written in C so is very lightweight and fast (compared to Net::SMTP).

The difference between Mail::QmailRemote (IKEBE Tomohiro) and Mail::QmailRemoteXS is that the former requires the qmail package to be installed and simply invokes a wrapper around the qmail-remote binary for each send. This module statically links code based on qmail-remote and has no dependencies other that a working resolver.

FUNCTIONS

mail

$ret = Mail::QmailRemoteXS::mail($to_domain,$from_address,$to_address,$msg,$helo,$net_timeout,$net_timeoutconnect);

Send an email message $msg (which includes rfc822 headers) to $to_address from $from_address using $helo as the SMTP HELO greeting. $net_timeoutconnect is for the initial SMTP connection and $net_timeout is for the wait time for SMTP responses.
See Qmails qmail-remote manpage for more information and details on the return value $ret.

Mail::Field is a base class for manipulation of mail header fields.

SYNOPSIS

use Mail::Field;

$field = Mail::Field->new(Subject, some subject text);
print $field->tag,": ",$field->stringify,"n";

$field = Mail::Field->subject(some subject text);

Mail::Field is a base class for packages that create and manipulate fields from Email (and MIME) headers. Each different field will have its own sub-class, defining its own interface.

This document describes the minimum interface that each sub-class should provide, and also guidlines on how the field specific interface should be defined.

Mail::Action is a Perl module for building modules that act on incoming mail.

SYNOPSIS

use base Mail::Action;

Sometimes, you just need a really simple mailing address to last for a few days. You want it to be easy to create and easy to use, and you want it to be sufficiently anonymous that your real address isnt ever exposed.

Mail::TempAddress, Mail::TempAddress::Addresses, and Mail::TempAddress::Address make it easy to create a temporary mailing address system.

Mail::Addressbook::Convert::Mailrc is a Perl module from Unix Mailrc Addressbook.

SYNOPSIS

use strict;

use Mail::Addressbook::Convert::Mailrc;

my $Mailrc = new Mail::Addressbook::Convert::Mailrc();

my $MailrcInFile ="mailrc"; # name of the file containing the Spry data # it is found in the Spry folder

# Convert Mailrc to Standard Intermediate format

# see documentation for details on format.

my $raIntermediate = $Mailrc->scan($MailrcInFile);

# This will also work

#my @MailrcInArray = @arrayContainingTheMailrcData;

#my $raIntermediate = $Mailrc->scan(@MailrcInArray);

print join "", @$raIntermediate;

Mail::SpamCannibal is a HOWTO Install SpamCannibal.

Create a user account for the SpamCannibal client. The mail client should not be run as a root user, to do so creates an unacceptable security risk.

Check the /etc/passwd and /etc/group files to make sure that uid and gid assignments for the new user are not already used, then run groupadd and adduser.

groupadd -g 95 spam

adduser

Login name for new user []: spam

User id for spam [ defaults to next available]:

Initial group for spam [users]: spam

Additional groups for spam (seperated
with commas, no spaces) []:

spams home directory [/home/spam]: /usr/local/spamcannibal

spams shell [/bin/bash]:

spams account expiry date (YYYY-MM-DD) []:

OK, Im about to make a new account. Heres what you entered so far:

New login name: spam
New UID: [Next available]
Initial group: spam
Additional groups: [none]
Home directory: /usr/local/spamcannibal
Shell: /bin/bash
Expiry date: [no expiration]

This is it... if you want to bail out, hit Control-C. Otherwise, press
ENTER to go ahead and make the account.

you fill in the rest......

Mail::LMLM::Render is a Perl module for rendering backend for LMLM.

SYNOPSIS

use Mail::LMLM::Render::HTML;

open O, ">out.html";
my $r = Mail::LMLM::Render::HTML->new(*O);

$r->start_document("My Document", "Head Title");

$r->start_section("Google", { title_url => "http://www.google.com/", });

$r->para("Google is a very nice search engine.");
$r->end_section();
$r->end_document();
close(O);

The Mail::LMLM::Render is a base class for rendering hypertext. It is used by LMLM extensively as a thin layer around the actual format.

To use it open a filehandle, and call the packages new constructor with a refernce to the filehandle. Afterwards call the start_document method (documented below), and when youre done call the end_document method. For each section call start_section and end_section explicitly.