Free mailing list software for linux

Web Mailing List project designed to be an easy to use mailing list application.
Using a mailing list application can greatly enhance communication with your site visitors. Web mailing list makes it easy for users to signup for your mailing lists.
Creating and sending out email newsletters is a snap. If you your users wish to unsubscribe, they simply visit your unsubscribe page and enter the email address where they received the newslettter.
Enhancements:
- This release updates the database creation portion of the system setup.

LDAP Mailing Lists Access Policy Daemon (MLAPD) is a mailing list manager that uses LDAP (instead of BDB or GDBM) to control list access. Its designed to work in conjunction with Postfix as an access policy delegation daemon. It manages electronic mail discussion and e-newsletter lists. Its goal is to store/read list data on/from LDAP.
It works as a Postfix access policy delegation agent, so it can be installed one time and used by multiple Postfix instances, or installed multiple times and not suffer database access concurrency issues (because it uses LDAP).
Enhancements:
- This can be considered the first stable and usable release.

Notes List is a simple and easy way to take Notes.

- Change SIZE (width and height)
- tun on/off the background image
- Auto save notes

Mail::Digest::Tools is a Perl module that has tools for digest versions of mailing lists.

SYNOPSIS

use Mail::Digest::Tools qw(
process_new_digests
reprocess_ALL_digests
reply_to_digest_message
repair_message_order
consolidate_threads_multiple
consolidate_threads_single
delete_deletables
);
%config_in and %config_out are two configuration hashes whose setup is discussed in detail below.
process_new_digests(%config_in, %config_out);

reprocess_ALL_digests(%config_in, %config_out);

$full_reply_file = reply_to_digest_message(
%config_in,
%config_out,
$digest_number,
$digest_entry,
$directory_for_reply,
);

repair_message_order(
%config_in,
%config_out,
{
year => 2004,
month => 01,
day => 27,
}
);

consolidate_threads_multiple(
%config_in,
%config_out,
$first_common_letters, # optional integer argument; defaults to 20
);

consolidate_threads_single(
%config_in,
%config_out,
[
first_dummy_file_for_consolidation.thr.txt,
second_dummy_file_for_consolidation.thr.txt,
],
);

delete_deletables(%config_out);

Mail::Digest::Tools provides useful tools for processing mail which an individual receives in a daily digest version from a mailing list. Digest versions of mailing lists are provided by a variety of mail processing programs and by a variety of list hosts. Within the Perl community, digest versions of mailing lists are offered by such sponsors as Active State, Sourceforge, Yahoo! Groups and London.pm. However, you do not have to be interested in Perl to make use of Mail::Digest::Tools. Mail from any of the thousands of Yahoo! Groups, for example, may be processed with this module.

If, when you receive e-mail from the digest version of a mailing list, you simply read the digest in an e-mail client and then discard it, you may stop reading here. If, however, you wish to read or store such mail by subject, read on. As printed in a normal web browser, this document contains 40 pages of documentation. You are urged to print this documentation out and study it before using this module.

To understand how to use Mail::Digest::Tools, we will first take a look at a typical mailing list digest. We will then sketch how that digest looks once processed by Mail::Digest::Tool. We will then discuss Mail::Digest::Tools exportable functions. Next, we will study how to prepare the two configuration hashes which hold the configuration data. Finally, we will provide some tips for everyday use of Mail::Digest::Tools.

mailman-pop3d provides a POP3 interface to GNU Mailman for the purposes of deleting spam which is stuck in the administrative requests queue.
If you manage a large Mailman mailing list, and are tired of using the web interface to discard spam, this script may be for you.
This software should be considered to be in beta stage; bugs are possibly present, and bug reports would be very much appreciated. At this point, I would also be very interested in hearing about success stories.
Enhancements:
- Improved logging messages.
- Development status changed from alpha to beta.

Mail::Toaster is an installer for a collection of software which provides a full-featured mail server. The system is built around the qmail mail transport agent, with many additions and modifications
Main features:
- SMTP Mail Server (SMTP-AUTH, chk-user, SPF, TLS, tarpitting, RBL)
- Virtual Domain Hosting w/delegated administration
- Virtual Domain Users
- Mailing List (Ezmlm)
- AutoResponder
- Web Based E-Mail (Sqwebmail, Squirrelmail, V-Webmail)
- Web Based Domain Administration
- Mail Filtering (rbls, SpamAssassin, simscan, Qmail-Scanner)
- Virus Scanning (ClamAV, F-Prot, Uvscan)
- SMTP roaming via SMTP-AUTH, POP-AUTH, & IMAP-AUTH
- SMTP roaming via SMTP-submission (port 587)
- POP3, POP3-SSL
- IMAP, IMAP-SSL (Courier IMAP)
- CGI frontend to mail features
- Log processing and pretty graphs (via RRDutil)
- Auto-Installs of MySQL, Apache, phpMyAdmin, and more
- Centralized configuration files
- Support for clusters of qmail servers
- Builds SSL certs for Apache, Qmail, & Courier
Security - Mail::Toaster supports secure connections from the email client (via POP3, IMAP, SMTP, and webmail) to the server. If the remote (destination) email server supports it, we also encrypt the email as it travels across the public Intenet from server to server. Thus, if you happen to be using two Mail::Toasters and your email clients are configured to use SSL, you have a fully encrypted path from the email sender to the final recipient.
State of the Art Filtering - Mail::Toaster has sophisticated filtering capabilities built right in. A default installation blocks all viruses and will detect 85% of the spam. With a little bit of training, its reasonable to expect and achieve 99% spam filtering accuracy.
Flexibility - Mail::Toaster provides an extremely flexible framework to allow you to build your email system your way. This flexibility makes it easy to migrate existing systems to Mail::Toaster and also allows Mail::Toaster to work in diverse environments and OS platforms.
Support - There is a thriving and active support community available on the mailing list. The web forums are also frequented by quite a few helpful folks. If you need more support than folks are willing to provide, commercial support is available.
Enhancements:
- Primarily code quality improvements.
- Rewrites of major portions of the code using techniques described in Perl Best Practices.
- Many more tests, much better tests, and more error testing within the functions.
- A new Webmail interface.
- Its not terribly "pretty" yet, but is much more user friendly and functional.

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.