Free mail bulkmail server 3.12 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 ;}

Proxmox Mail Gateway project addresses the full spectrum of unwanted e-mail traffic, focusing spam and virus detection.
E-mail security begins at the gateway by controlling all incoming and outgoing e-mail messages. Proxmox Mail Gateway addresses the full spectrum of unwanted e-mail traffic, focusing spam and virus detection.
Proxmox Mail Gateway uses a wide variety of local and network tests to identify spam signatures. This makes it harder for spammers to identify one aspect which they can craft their messages to work around.
Every single e-mail will be analyzed and gets a spam score assigned. The systems attempt to optimize the efficiency of the rules that are run in terms of minimizing the number of false positives and false negatives.
The flexible architecture combined with the easy-to-use configuration interface safeguards companies against existing and new e-mail threats.
Main features:
- Advanced spam detection
- Virus removal including phising e-mails
- Automatic update of virus signature database
- Automatic installation within minutes
- Support for standard PC / Server hardware (i386)
- SCSI and SCSI raid support
- Secure web based configuration
- Object-oriented rulesystem
- Attachment blocking
- Advanced statistics
- Daily reports

Mail::IMAPTalk is an IMAP client interface with lots of features.

SYNOPSIS

use Mail::IMAPTalk;

$IMAP = Mail::IMAPTalk->new(
Server => $IMAPServer,
Username => foo,
Password => bar,
Uid => 1 )
|| die "Failed to connect/login to IMAP server";

# Append message to folder
open(my $F, rfc822msg.txt);
$IMAP->append($FolderName, $F) || dir $@;
close($F);

# Select folder and get first unseen message
$IMAP->select($FolderName) || die $@;
$MsgId = $IMAP->search(not, seen)->[0];

# Get message envelope and print some details
$MsgEV = $IMAP->fetch($MsgId, envelope)->{$MsgId}->{envelope};
print "From: " . $MsgEv->{From};
print "To: " . $MsgEv->{To};
print "Subject: " . $MsgEv->{Subject};

# Get message body structure
$MsgBS = $IMAP->fetch($MsgId, bodystructure)->{$MsgId}->{bodystructure};

# Find imap part number of text part of message
$MsgTxtHash = Mail::IMAPTalk::find_message($MsgBS);
$MsgPart = $MsgTxtHash->{plain}->{IMAP-Partnum};

# Retrieve message text body
$MsgTxt = $IMAP->fetch($MsgId, "body[$MsgPart]")->{$MsgId}->{body};

$IMAP->logout();

This module communicates with an IMAP server. Each IMAP server command is mapped to a method of this object.

Although other IMAP modules exist on CPAN, this has several advantages over other modules.

It parses the more complex IMAP structures like envelopes and body structures into nice Perl data structures.

It correctly supports atoms, quoted strings and literals at any point. Some parsers in other modules arent fully IMAP compatiable and may break at odd times with certain messages on some servers.

It allows large return values (eg. attachments on a message) to be read directly into a file, rather than into memory.

It includes some helper functions to find the actual text/plain or text/html part of a message out of a complex MIME structure. It also can find a list of attachements, and CID links for HTML messages with attached images.

It supports decoding of MIME headers to Perl utf-8 strings automatically, so you dont have to deal with MIME encoded headers (enabled optionally).

While the IMAP protocol does allow for asynchronous running of commands, this module is designed to be used in a synchronous manner. That is, you issue a command by calling a method, and the command will block until the appropriate response is returned. The method will then return the parsed results from the given command.

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.

These are the primary mail utilities of the GNU system.

Specifically, this package contains a POP3 server, an IMAP4 server, and a Sieve mail filter. It also provides a POSIX mailx client and a collection of other tools.

Basset::Object is a Perl module used to create objects.

This is my ultimate object creation toolset to date. It has roots in Mail::Bulkmail, Text::Flowchart, and the unreleased abstract object constructors that Ive tooled around with in the past.

If you want an object to be compatible with anything else Ive written, then subclass it off of here.

Of course, you dont have to use this to create subclasses, but youll run the risk of making something with an inconsistent interface vs. the rest of the system. Thatll confuse people and make them unhappy. So I recommend subclassing off of here to be consistent. Of course, you may not like these objects, but they do work well and are consistent. Consistency is very important in interface design, IMHO.