Free mail software for linux

Mail::SendEasy can send plain/html e-mails through SMTP servers (platform independent). Supports SMTP authentication and attachments.

This modules will send in a easy way e-mails, and doesnt have dependencies. Soo, you dont need to install libnet.
It supports SMTP authentication and attachments.

USAGE:

OO

use Mail::SendEasy ;

my $mail = new Mail::SendEasy(
smtp => localhost ,
user => foo ,
pass => 123 ,
) ;

my $status = $mail->send(
from => sender@foo.com ,
from_title => Foo Name ,
reply => re@foo.com ,
error => error@foo.com ,
to => recp@domain.foo ,
cc => recpcopy@domain.foo ,
subject => "MAIL Test" ,
msg => "The Plain Msg..." ,
html => "The HTML Msg..." ,
msgid => "0101" ,
) ;

if (!$status) { print $mail->error ;}

STRUCTURED

use Mail::SendEasy ;

my $status = Mail::SendEasy::send(
smtp => localhost ,
user => foo ,
pass => 123 ,
from => sender@foo.com ,
from_title => Foo Name ,
reply => re@foo.com ,
error => error@foo.com ,
to => recp@domain.foo ,
cc => recpcopy@domain.foo ,
subject => "MAIL Test" ,
msg => "The Plain Msg..." ,
html => "The HTML Msg..." ,
msgid => "0101" ,
) ;

if (!$status) { Mail::SendEasy::error ;}

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.

As you probably know, Yahoo Mail does not provide free POP access to its users any more. You can still use your YM account for free, but you have to use a Yahoo Mail web site to access your account.
This is not very convenient as you always have to be online, you cannot use your favourite e-mail client to read your messages, and so on. You can easily immagine the disadvantages of having to manage all your corespondence via web.
When Yahoo disabled its free POP access, the first thing that came to my mind was to change my e-mail account. But then I realized, there are far too many people used to my current Yahoo Mail address, that I am used to my YM address very much too and I thought - if Yahoo closes a free service, the other services will follow sooner or later. So changing an e-mail service/account wasnt really solution.
That is when I have decided to write YoSucker as a simple portable perl application, that would simulate a user actions to retrieve my mail to my local inbox. Yahoo Mail Sucker simply connects to the Yahoo Mail web site, parses the HTML code and fetches new messages.
With time I have added lots of other features and functionality (like support for multiple accounts, support for procmail, support for local Yahoo Mail sites, for proxy connection and much more) but the basic idea still stay the same...
Main features:
- secure SSL login
- support for multiple accounts
- encrypted passwords for enhanced security
- transaction safe writes
- support for various folders (including BULK mail)
- support for multiuser environment
- support for multiple mailboxes in one config file
- support for procmail (output to a pipe)
- support for localized Yahoo Mail sites
- support for proxy
- support for basic proxy authorization
- support of command line parameters
- powerful digest feature for listing mailbox content
- handles virtually unlimited number of messages
- LeaveOnServer, EmptyTrash and OnlyNew features
- restore message unread flag feature
- powerful CLEAN option
- quota storage warning system
- session Respawn feature
Enhancements:
- This things been around too long be be a prototype any longer.
- Filtered the annoying "Yahoo! Domain Keys" message in From header

SubEtha is a sophisticated mailing list manager, similar in many respects to the popular Mailman package. SubEtha is a three-tiered J2EE application using EJB3 and JMS. It is stable and self-hosting.
Main features:
- Very easy installation on Windows and Unix platforms
- A user-friendly web interface for all configuration management
- Virtual domains (ie list@foo.com and list@bar.com are separate lists)
- Users can have multiple email addresses and self-moderate messages from unknown addresses.
- Intelligent attachment handling; attachments can be removed from delivered mail and replaced with a download link to the archives.
- Pluggable, configurable message processing filters which can arbitrarily modify the inbound and outbound message streams. Example filters include attachment stripping, header munging, spam detection, and insertion of advertising.
- Per-list role-based permissions.
- One-step creation of basic list types (ie "Announce-Only List" or "Technical Support List"). The set of available types is pluggable.
- Searchable, threaded archives
- Users can reply to messages from the archives. They can click on a button and have the message resent to them normally.
- Intelligent VERP bounce processing
- Clusterable for nearly unlimited scalability
- Easy integration with any mail transport agent (MTA)
- EJB and SOAP interfaces for automation
- International characters in emails are properly passed through the system and rendered in the web interface
- RESTful, bookmarkable URLs
- A modular SMTP library that can be used outside SubEtha
Enhancements:
- This release works around a a backwards compatibility issue issue where SubEtha would not run on Java 5 because the released code was compiled using Java 6.

Masswire Mail provides a SQL POP3 Webmail software.

Masswire Mail is a Webmail client written in Perl that can retrieve messages from multiple POP3 accounts and store them in a single SQL table.

Some features include a spell checker using the Text-Aspell module, a Bayesian filter using the Algorithm NaiveBayes module, and attachments using the Mail Sender module.