This software takes the hard out of generating replies to email messages.
This module provides a very simple, very clean, very specific interface
to multiple Email mailers. The goal of this software is to be small
and simple, easy to use, and easy to extend.
Email::Sender replaces the old and sometimes problematic Email::Send library,
while this module replaces the Email::Send::SMTP::TLS.
This transport is used to send email over SMTP, either with or without
secure sockets (SSL/TLS). it uses the great Net::SMTPS.
This module is recommended than Email::Sender::Transport::TLS.
Email::Simple::FromHandle provides an Email::Simple object which uses a
filehandle as its source, so it does not need to hold the entire body in memory
until needed.
Email::Stuffer, as its name suggests, is a fairly casual module used to stuff
things into an email and send them. It is a high-level module designed for
ease of use when doing a very specific common task, but implemented on top of
the light and tolerable Email:: modules.
Email::Stuffer is typically used to build emails and send them in a single
statement, as seen in the synopsis. And it is certain only for use when
creating and sending emails. As such, it contains no email parsing
capability, and little to no modification support.
Email::Valid::Loose is a subclass of Email::Valid, which allows . (dot)
before @ (at-mark). It is invalid in RFC822, but is commonly used in some of
mobile phone addresses in Japan (like docomo.ne.jp or jp-t.ne.jp).
This module allows users to access their Gmail messages with an IMAP
client by running a server which accepts IMAP connections.
Currently this module supports only a subset of the IMAP4 protocol.
IMAP-Admin is a Perl module for basic IMAP server administration. With
this module it's easy to make Perl scripts to create new and remove obsolete
IMAP accounts, set user quotas on Cyrus server etc.
This module was created as a low-level inteface to any IMAP server. It
was built to be a 'clear box' solution to working with an IMAP
environment. The idea is that anything an IMAP client should be able
to do, and any information available via the IMAP specs, should be
available to a client interface and user. This way, the full strength
of the IMAP protocol and data can be utilized, ideally in the most
network-efficient mannger possible, rather than being contrained only
to a subset of commands or data-limited responses. If the server says
it, the client should be able to see it.
This module also takes steps to be able to handle anticipated
situations for the user rather than forcing a per-implementation
behavior for such expected events, such as referrals. IMAP::Client
will fully support referrals, and will transparently handle them for
whatever command is issued to them (so long as the referral s for
anonymous or the same user with the same password - a new user or
different password would require a new username/password to be
obtained. As of 0.01, this is not supported, however the framework is
down.