The Email Redirector is a program that is used in conjunction with an MTA, such as sendmail, to redirect all outbound mail messages, passing through the MTA, through a particular username on an ISP's mail gateway. Its principal use is to permit a site that is blocked from connecting to the regular SMTP port at the ISP (due to ISP paranoia about spammers), to send mail through the normal SMTP channels.
Using the redirector, members of your local network can send mail to the MTA on a local machine. The local MTA can relay through a single account on the ISP's mail gateway. Thus, the redirector transparently circumvents most typical relaying problems while still playing by the ISP's rules for relaying mail via SMTP.
Normally, to block spam, most ISPs have a list of valid IP addresses from which they are willing to relay outbound mail. All other IP addresses are blocked from relaying outbound mail through the ISP. This allows statically connected sites to send mail through their ISP but prevents spammers from using the ISP as a spam gateway.
For those sites which employ a dynamic connection to their ISP, outbound mail is usually sent under specific usernames. This works well for Joe User, with a desktop machine, who logs in to the ISP directly. However, for a site that has multiple users networked together and which wants to send outbound mail via a local version of sendmail, this presents a problem. There are good reasons for wanting to do this, by the way, not the least of which is that mail amongst the local users need never leave the safety of the local network.
The redirector is inserted into the flow of outbound mail that the MTA sends to the external gateway. It takes all of the mail and sends it under a single username on the ISP's mail gateway. As far as the ISP is concerned, the mail is being sent by a single user. As far as the users of the local network are concerned, the local MTA is working as ususal.
An additional wrinkle is that, since SMTP didn't originally support passwords, many ISPs implemented a kludge that allowed them to verify the username/password of a sender, after a fashion (see poprelayd). In order for a user to send outbound mail via SMTP, the ISP requires a POP login within a short period of time prior to the invocation of SMTP. The IP address of the POP (which uses password validation) requestor is saved in a short-time database. A subsequent SMTP request is validated against the saved IP address, thereby faking password validation for SMTP.
The redirector will perform a login and simple handshake with the ISP's POP server, immediately before sending any messages via SMTP, thereby setting the IP address in their database and meeting the requirement for SMTP use. What can we say? Its a kludge, albeit a pretty common one. It should work fine. However, given that this login and handshaking is not cheap and could be superflous, it is only done if you request it.
A word about timing is in order, at this point. Many ISPs, who've implemented poprelayd, have done so by running a job that does a tail of the system log, looking for successful POP logins, followed by an update of the poprelayd database. This causes a slight delay between when the mail client logs in and when they can legitimately send outbound mail. Normally, this is not a problem because humans are slow. However, the redirector is so fast that it may get rejected, despite having logged in correctly, because the ISP's poprelayd hasn't caught up yet. This being the case, a small timing delay can be inserted into the flow, by the redirector, to allow poprelayd to catch up.
The proper way to do authentication was eventually implemented through ESMTP's "AUTH" verb extension. The use of the "AUTH" verb, and the various authorization mechanisms employed by it for authentication, is also supported by the redirector.
The most desirable (i.e. supposedly most secure) form of authorization is selected by the redirector, based on what the remote SMTP server has on offer. Both AUTH PLAIN and AUTH LOGIN are supported directly by the redirctor.
In addition, AUTH CRAM-MD5 is supported if the Digest::HMAC and Digest::MD5 Perl modules are installed from CPAN. On many Linux systems, these modules are already installed as part of the basic Perl installation so AUTH CRAM-MD5 usually works automatically.
In order for AUTH DIGEST-MD5 and AUTH GSSAPI to be supported, the Authen::SASL Perl module from CPAN must be installed. This, in turn, requires that one of the SASL libraries be installed, with our preference being the Cyrus library. Usually, this library is available as an OS package while, as we noted above, the Perl module is available from CPAN, so the installation of the required module and library is a trivial matter, thereby making support for all of the popular AUTH mechanisms quite straightforward.
Note that the redirector script will degrade gracefully and use only the Perl modules that it can find, to support the most desirable AUTH mechanism possible. If a module is missing, it won't stop the redirector from working. It will simply use a less desirable method. Thus, you can choose what level of security you wish to authenticate at, depending on how much effort you wish to put into the installation.
With the advent of Spam becoming a major problem, many ISPs began to block connections to port 25 (either for all outbound traffic or only for traffic bound out of their network). Solutions to this kind of port blocking include running SMTP on a non-traditional port (e.g. 2525, a.k.a. The Cleopatra port) or using the RFC-defined, submit port (587) which does more rigorous user verification.
Whatever the reason for this blocking of port 25, you may need to specify an alternate port for SMTP, in which case this can easily be done by appending the port number to any remote hostname supplied, in the usual fashion, by separating it with a ':'. In this manner, non-traditional SMTP ports are easily utilized.