Free mail server software for linux

Scam-protect is a milter which restricts the use of your domain address in emails. The aim is to protect your users from phishing by rejecting mail purporting to be from your domain. It is not meant as a replacement for SPF or SenderID.
Main features:
- Reject mail with your domain name in the mail from envelope
- Reject mail with your domain name in the From header
Performance
Scam-protect milter was designed to be light-weight and use minimal resources.
Whitelist
Scam-protect has a configurable whitelist of IP addresses or a range of IP addresses (CIDR). This feature can be used to allow which hosts can use your domain name in email addresses..
Accept mail from users
Users should configure their mail clients (MS Outlook, Eudora, Mozilla Thunderbird) to use the port 587 (MSA) instead of the SMTP port to send mail through the mail server running Scam-protect.
Scam-protect will accept mail if the connection was authenticated through SMTP AUTH.

Fetch and deliver mail is a simple, lightweight replacement for mail fetching, filtering, and delivery programs such as fetchmail and procmail.
It can fetch using POP3, POP3S, IMAP, IMAPS, or stdin, and deliver to a pipe, file, maildir, mbox, or SMTP server, based on a set of regexps.
Fetch and deliver mail can be used for both single user and multiuser setups, and is designed with privilege separation when running as root.
Enhancements:
- Mostly configuration file enhancements and code cleanup were done since 1.2. ifdef/endif blocks and inline shell commands are allowed in the configuration file.
- A built-in string cache using TDB was added.
- Some extra default tags were added. NNTPS fetching was implemented.

Mail Avenger is a highly-configurable, MTA-independent SMTP server daemon. Mail Avenger lets users run messages through filters like ClamAV and SpamAssassin during SMTP transactions, so the server can reject mail before assuming responsibility for its delivery.
Other unique features include TCP SYN fingerprint and network route recording, verification of sender addresses through SMTP callbacks, SPF (sender policy framework) as a general policy language, qmail-style control over both SMTP-level behavior and local delivery of extension addresses, mail-bomb protection, integration with kernel firewalls, and more.
Enhancements:
- Several minor bugs were fixed.
- The SMTPCB configuration directive was changed to give more options.
- An InsecureSASL configuration option was added by request of users.

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.

SubEthaSMTP is an easy to understand Java library that provides a receptive SMTP server component.
By plugging this component into your Java application, you can easily receive SMTP mail using a simple abstract Java interface.
Also included is a small sub-project called Wiser, an easy to use incoming mail testing framework.
Main features:
- A mailing list manager (ie, SubEtha Mail)
- A mail server that delivers mail to user inboxes
- A mail archiver like Mail Archive
- An email test harness (Implemented in this project. Its called Wiser.)
SubEthaSMTP was split out of the SubEtha Mail mailing list manager because it is a useful standalone component. When we wrote SubEtha, the last thing we wanted to do was write our own SMTP server. In our search for a modular Java SMTP component, we examined:
Apache JAMES
JBoss Mail Server
Dumbster
Jsmtpd
JES
Java Mail Server
Since youre reading this page you probably already know what we found: Six different SMTP implementations without the slightest thought given to reusability. Even Jstmpd, which purports to be a "A Modular Java SMTP Daemon", isnt. Furthermore, even though JBoss Mail is in active development, the team was unintersted in componentization of the SMTP processing portion of their server.
During the development of SubEthas testing harness, we tried out the Dumbster software and found that not only was the API difficult to use, it did it not work properly, the developer has not done any development on it in about a year and it does not work reliably on Mac OS X. With two simple classes we re-implemented it as an included project called Wiser.
We hate reinventing wheels. This should be the LAST FREAKING JAVA SMTP IMPLEMENTATION.
Enhancements:
- This release fixes a couple of bugs with SMTP RFC handling.

Courier mail transfer agent (MTA) is an integrated mail/groupware server based on open commodity protocols, such as ESMTP, IMAP, POP3, LDAP, SSL, and HTTP. Courier provides ESMTP, IMAP, POP3, webmail, and mailing list services within a single, consistent, framework.
Individual components can be enabled or disabled at will. Courier now implements basic web-based calendaring and scheduling services integrated in the webmail module. Advanced groupware calendaring services will follow soon.
Couriers source code should compile on most POSIX-based operating systems based on Linux, and BSD-derived kernels. Courier should also compile on Solaris and AIX, with some help from Suns or IBMs freeware add-on tools for their respective operating systems.
Courier evolved out of several related projects, that merged together (more on that later). Courier implements SMTP extensions for mailing list management and spam filtering. Courier can function as an intermediate mail relay, relaying mail between an internal LAN and the Internet, or perform final delivery to mailboxes.
Courier uses maildirs as its native mail storage format, but it can also deliver mail to legacy mailbox files as well. Couriers configuration is set by plain text files and Perl scripts. Most of Couriers configuration can now be adjusted from a web browser, using Couriers web-based administration module.
Courier can provide mail services for regular operating system accounts. Courier can also provide mail services for virtual mail accounts, managed by an LDAP, MySQL, or PostgreSQL-based authentication database.
Enhancements:
- This release introduces a Web-based interface to couriermlm, implementing complete, browser-based mailing list administration functionality.

PhpXmail is Web-based management software for the Xmail mail server. It allows the administrator of the mail server to perform configuration management and monitoring tasks for the mail server.
It allows the postmaster for each domain the Xmail server is configured to perform management functions. The project allows the users who have a mail account to manage their account settings.
Enhancements:
- IE7 compatibility was fixed.