For many people, using an external mail server for outbound mail is more than critical. There are many reasons for this, some of which are:
- bypassing dynamic IP blacklists by using a non-blacklisted mail server
- sending mail from an alternative mail server on an alternative SMTP port (useful if your ISP blocks port 25, and the external server supports alternative ports)
- hardcoding an SMTP server into a web-based application (like a forum or CMS) when a mail server is otherwise unavailable
Relaying allows you to send email through an external mail server, but the email looks as if it's coming from your own domain. For example, I can send an email from anything@ameir.net to anythingelse@gmail.com via an intermediate host without the Gmail user knowing about the intermediary (unless he/she looks at the headers). This doesn't sound like a big deal at all, but if you lie under one of the bulleted conditions above, then you may find it hard to communicate with the rest of the web. Most mail servers only allow you to send mail from the email address you own from them (e.g. sending mail through AOL's mail servers requires you to send the mail FROM your address).
Because I was on a dynamic IP and because Comcast mysteriously blocked port 25, I found that I needed a way to have emails from my server get to me. My backups were no longer being sent via email, my blog wasn't notifying me of any actions, and I figured it would be cool to finally send an email without a DNSBL rejecting me solely because of my IP address.
Luckily, here are some solutions:
ulmb.com (ports 25, 587)
This service actually provides you with a webhosting account of 5GB. I tried using them as a webhost once, but gave up after I ran into some restrictions. Still, they support email and relaying (although relaying isn't advertised), which is of great use. They do not pester you about DNS pointing to them or anything of the sort either.
mail.ikojomail.com (ports 25, 26)
This is an email service that offers a 5GB quota with IMAP, POP, and all the bells and whistles. Unfortunately, its webmail interface needs a little working on (it doesn't synchronize with the actual IMAP data), but as a pure IMAP email service it works very well. As an SMTP relay it works even better.
UPDATE: This domain recently expired, leaving the service inoperable. If you can find the IP for the domain when it was up, you might be in luck.
mail.inboxnow.com (ports 25, 26)
This service is the same as Ikojomail, but with a different name. The webmail interface works just like Ikojomail's (not well). For IMAP and SMTP, the service is fast and works great.
mail.icmail.net (ports 25, 587)
This service has been around for a couple of years and is pretty reliable. They offer POP/IMAP/SMTP, and their SMTP servers allow you to send from another sender. The only thing I don't like about it is that it complains sometimes when you send emails shortly after each other/have multiple connections to the SMTP server.
smtp.webalta.com (port 25)
This is a web search company from Russia that offers email accounts. The signup and webmail interfaces are in Russian, but you can get by based on the icons and the locations of the text fields if you don't know Russian (I sure don't). The service is pretty fast, and, as you expected, allows you to send emails from another sender. Seems pretty reliable.
mail.kakle.com (ports 25, 465)
This service provides 5GB webmail with full IMAP/POP capabilities. It's actually a pretty good service (when it works), and uses Squirrelmail as the webmail frontend. Message filters are done by Squirrelmail so it's not entirely server side (because you have to login and load Squirrelmail for filtering to occur). Sometimes incoming email has problems (it either works great or not at all), but as an outgoing SMTP server it works superbly. Note that port 465 is typically SMTP over SSL, but Kakle uses it as standard SMTP.
If you own a mail server but do not know how to set up relaying, there is nothing to worry about. There is documentation online for everything.
Below I show how I setup mail relaying on my Postfix server (I'll use Inboxnow for this; change the hostname to whatever server you wish to try). Before you begin, make sure you have the postfix-tls package installed. On a Debian-based distro like Ubuntu, you can install it simply with:
CODE:
apt-get update && apt-get -y install postfix-tls
Now here comes the good stuff. You must paste the following commands as root for relaying to work (copy and paste the below into a plain-text editor such as Notepad or Gedit, modify the relevant info, and paste into a terminal as root):
CODE:
postconf -e 'relayhost = mail.inboxnow.com:26'
postconf -e 'smtp_sasl_auth_enable = yes'
postconf -e 'smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd'
postconf -e 'smtp_sasl_security_options ='
# I disabled tls because Postfix complained about a self-signed certificate.
postconf -e 'smtp_use_tls = no'
echo "mail.inboxnow.com:26 USERNAME@inboxnow.com:PASSWORD" > /etc/postfix/sasl_passwd
chown root:root /etc/postfix/sasl_passwd
chmod 600 /etc/postfix/sasl_passwd
postmap /etc/postfix/sasl_passwd
/etc/init.d/postfix restart
You can see from above that I disabled TLS. This is generally not a good idea if TLS is available, but I encountered issues with Inboxnow's SSL certificate because it was self-signed. I disabled TLS in the meantime, and will keep my eyes peeled for a workaround. If you find any ways to get TLS working with a self-signed certificate, please let me know in the comments below. You should now be able to send emails via the relay. As a quick test, you can send yourself a test email and look at the headers to see the trajectory the email took. If you have mutt installed, you can easily do this by typing (as any user):
CODE:
echo "body" | mutt -s "test message" EMAIL@ADDRESS.TLD