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.
Eventually, the proper way to do authentication was implemented in sendmail by the addition of the "AUTH" verb. Some ISPs use this verb for authentication (instead of poprelayd) so the "PLAIN" authentication method, is also supported by the redirector.
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.