When I signed up for Verizon FiOS after enjoying complete port freedom with Time Warner Cable, I was pleasantly surprised to find out that Verizon had finally dropped its annoying habit of blocking inbound port 80 (HTTP) on residential accounts. Some obligatory follow-up testing revealed inbound traffic to port 25 (SMTP), among others, was also being allowed.
Unfortunately, Verizon is still blocking outbound port 25 as of this writing. This means that, unless you have access to an external SMTP relay listening on a non-standard port somewhere on the Internet, you will only be able to send mail by funneling it through Verizon’s SMTP server.
- You cannot deliver mail directly to anybody. Considering that many of Verizon’s residential IP address blocks are blacklisted as spam sources anyway, this is, for practical purposes, a moot point.
- Verizon’s SMTP server is sluggish—and there is no way around this unless you have access to an external relay running on a non-standard port as mentioned above.
- The Verizon relay requires both authentication and TLS/SSL encryption. While this helps prevent spam by holding Verizon customers accountable for the mail they send, it’s not daemon-friendly—most software that sends e-mail programmatically does not support authentication, let alone secure connections. A good example of this is the Intel Rapid Storage Technology (RST) driver package, which has the ability to send e-mail alerts when problems are detected on a storage volume or RAID array.
The Workaround (For Problem #3, Anyway)
By running an SMTP proxy on your LAN, local programs can send e-mail to the outside world through Verizon’s SMTP relay without having to worry about encryption or authentication, with these being handled transparently by the local proxy.
In looking for a ready-made solution, I first stumbled upon SmtpProxy—an open-source, no-frills Windows service that accepts clear-text connections from the local network and simultaneously opens TLS connections to an external relay. SmtpProxy passes traffic in unencrypted form between the client program and itself, and in encrypted form between itself and the Verizon SMTP server. Unfortunately, SmtpProxy still leaves the burden of authentication to the client, thus solving only half the problem.
Next, I tried out E-MailRelay—an open-source, cross-platform solution that bridges SmtpProxy’s authentication gap and also provides additional functionality, such as local spooling and queuing of messages. E-MailRelay fits the bill, and more.
On Windows, the E-MailRelay installer includes a wizard that asks a few questions and configures the service accordingly by dropping the appropriate command-line switches into a batch file. The basic parameters we want for Verizon as of this writing are as follows:
--as-proxy=<outgoing.verizon.net:587|smtp.verizon.net:465> --client-auth=emailrelay.auth --client-tls
The above instructs E-MailRelay to accept mail locally on port 25 over an anonymous, unecrypted connection and forward it, in real-time, to Verizon’s external relay over an authenticated, secure connection to port 465 or 587†. On Windows, the installer will create the authentication secrets file for you. (For information on maintaining, as well as creating this file on other platforms, refer to the E-MailRelay reference.)
When operating as above, the client connection will block while E-MailRelay attempts to forward the message to the external relay. If the latter rejects the message or is otherwise unavailable, E-MailRelay will pass the error back to the client and make no further attempts. This behavior is the same it would be without a proxy.
A more robust approach is to take advantage of E-MailRelay’s spooling and queuing capabilities. By having E-MailRelay store messages locally and queue them up for delivery, client programs can fire off messages instantly without having to sit and wait for the external relay to respond, which can sometimes take quite a while—especially with Verizon. Additionally, should your ISP’s SMTP server ever be unavailable, E-MailRelay will accept and queue messages locally and attempt to redeliver them later. When operating in this mode, E-MailRelay is actually no longer just a proxy; it becomes, in effect, a mail transfer agent (or MTA).
To have E-MailRelay spool and queue messages, use the following switches instead:
--as-client=<outgoing.verizon.net:587|smtp.verizon.net:465> --client-auth=emailrelay.auth --client-tls --poll 300
300 directs E-MailRelay to scan the spool directory for messages to (re)deliver every five minutes. Depending on the nature and volume of e-mail generated by your environment, you will want to adjust this value to strike a balance between load and delivery time.
† As of this writing, Verizon is recommending that users ditch the legacy
outgoing.verizon.net:587 in favor of the new
smtp.verizon.net:465 for sending mail; however, the latter is unusable on my account—while I am able to connect, the server remains silent and never sends a 220 greeting.