Understanding mail relaying

If you run a mail server, it's important that you understand the concept of relaying. If you don't understand this concept, it's very likely that you will end up with an open relay, which will ultimately result in your mail domain being blacklisted once spammers find your server and start using it to send tons of UCE.

Why am I telling you this, and what does it have to do with .NET? Well, during my pre-conference talk on ASP.NET at the PDC, I had an example that used the SmtpMail class in ASP.NET to send an error message using my email domain. During the break between sessions, an attendee asked me how I was authenticating against the server, or was I just using an open relay. Now I had tested my mail server, and thought I had it fully locked down, so his question caused me some concern, since I initially thought that it indicated that my server might be open to relaying, since I wasn't actually authenticating at all. I was particularly concerned since I was on the west coast, my server was on the east coast, and I did not have the server set up for remote access.

Well, now that I'm back from PDC, I've spent several hours troubleshooting the problem, including uninstalling and reinstalling my mail server software, only to discover that the reason the sample worked (and the reason that several open relay testers showed my server to be open) was because I have my email domain set up with a catch-all address. With my mail server software, if mail is addressed to a valid address within the domain, it is not considered relayed mail, so it is delivered without applying the relaying rules.

So there are three lessons to learn from this:

1. Make sure you understand how relaying works, including how it is implemented by your mail server.
2. Understand that using catch-all addresses can have consequences beyond increasing the amount of spam you have to put up with (they're still worth it, IMO, since it makes it possible to use "throw-away" addresses that are specific to a given purpose such as registering for notification from a website).
3. Make sure that when you are testing your domain for open relay problems, you do not use a TO address that is within your domain. Depending on your mail server software, this might cause a false positive (and waste a significant amount of your time tracking down a non-existent problem).

Oh...one more thing to learn from this...trying to troubleshoot software configuration issues the day after returning from an intense conference on a red-eye that arrives at 6am is probably not the most efficient course.

UPDATE: Just got notification from the testing service at ordb.org that my server is not an open relay. Good to finally confirm that (note that if you use the test at ordb.org and you are running an open relay, it will automatically be listed as such in their database, which could result in your mail being blacklisted by anyone who uses ordb.org for blacklisting).