Email Policy and Guidelines
If you run an Internet connected email server, there are a few simple things that you should do to make your life easier, make your email delivery more successful, and be a good net.citizen. This page may also be useful for people operating Microsoft's Exchange servers who are not familar with Internet conventions and current practices for email operations.
CH3 Data rejects my email
If your email was rejected from any of CH3 Data's email servers, you may contact firstname.lastname@example.org for more information and to request removal. Please include the rejection message.
Configure your DNS correctly
Your mail server has an external IP address that it talks to other mail servers on. That IP address has an associated PTR record that is managed by your ISP. You can see what yours is set to currently by running the command "nslookup your_IP_address"
You probably will get back something like
184.108.40.206.in-addr.arpa name = cpe-192-168-97-42.town.generic.bigisp.example.com.
If you get something like this, your server really looks like it's just another spambot infested system sitting out there on a cable or DSL line, and will probably be treated accordingly with increased spam scores, greylisting, or outright blocking of your email delivery attempts. Before you get pissed off, think about it from the receiver's point of view. Would you really want to accept mail from a server with a PTR that looked like that? No? Didn't think so.... In fact there's an entire company built around analyzing PTR records for their spam potential. Take a look at the Enemies List.
If you don't get any answer back at all, you are really screwed and you need to YELL at your ISP for having a badly broken infrastructure. See SMARTHOST below, since very few people are going to accept your email, and the ones that do will probably put it in the spam or junk folder right off the bat.
So how do you fix your PTR name? Pick a name for your mail server like "mailserver.your_domain_name.com" and contact your ISP's support group and ask them to "change the PTR record for your IP address."
If the ISP refuses, start shopping for a new ISP. Seriously. They are not providing business class services for you, and deserve to lose your business. If they are the only game in town, you can either take a look at the SMARTHOST section below, or better, gripe about the sorry competitive situation to your state representative and PUC.
Some known hostile ISPs
The following ISPs are known to be hostile to setting up custom PTR records, thus telling the rest of the Internet that your network is poorly managed, and somewhat suspect. If you happen to work for one of these hostile ISPs and you have seen the light and have decided to start offering real business class services to your customers, please contact me and I will be happy to update this page and put a link to the URL where your customers should go to request a PTR record.
Verizon FIOS with static IP addresses
British Telecom with static IP addresses
So that's half of the DNS sorted out. Now the other side, which should be easier. Make sure that the PTR record you set up has a matching A record that resolves to the correct IP address. To do this, log in to your control panel, contact support, or do whatever is needed to get an entry like this in your domain name's config file:
mailserver.your_domain_name.com A 192.168.97.42
So now you have a non-generic PTR, an A record that matches, and a much more professional appearance on the 'net. No more looking like a spambot host!
A reader sent me this link to Wikipedia's page on Forward Confirmed reverse DNS if what I've written doesn't make any sense.
Update - Time Warner Cable Business Class will configure PTRs for you if you email them at DNS (at) twccs.com. Kudos to TW Cable for allowing custom PTRs now.
Configure your SMTP greeting correctly
Now you just need to make sure that your SMTP greetings look professional. When your server contacts another MTA, it sends a hostname as part of the SMTP protocol ( see RFC 5321, section 220.127.116.11). If your hostname is exch932854231.internal.local, you don't really exist in the global DNS. So what should be there? If you guessed the hostname that you just configured in your A record, give yourself a gold star!
To change the banner, ask your favorite search engine, or try this link: www.knowthenetwork.com
Now your SMTP greeting hostname exists in the global DNS, the IP address from your A record has a PTR that matches the banner, and the circle is complete. This would be very difficult for a spambot to achieve. Congrats! Your mailserver now looks like it's professionally managed.
All of the above has gone completely pear shaped. Your ISP won't change your PTR, the Exchange server admin refuses to change the greeting, and the web dude can't remember the password for the control panel. Top it off with the boss getting an important email bounced or greylisted for a couple of days, and your life in IT kinda sucks.
The quick and dirty solution is to use your ISP's SMTP relay service or smarthost. There are some downsides to this. You are trusting that they've done the steps outlined above, that they are not in every DNSBL on the planet, and that the servers have enough capacity to accept and deliver your email in a timely fashion. Sometimes you have little choice though. This may help you get started.
If you really don't want to smarthost through your ISP's server, you might be able to use your web hosting company's email server or the server that hosts your web site. Watch out though--quite a few shared web host servers are home to email form scripts that are easily exploited and so have their IP addresses listed in DNSBLs. Also, you still have to make sure that you have your A, PTR, and SMTP greeting set up to match as discussed above in Configure your DNS correctly. A disturbing trend I've seen lately is ill-informed, clueless hosting companies trying to use PTR records to advertise, so they set up records like "18.104.22.168.hostedby.a.bunch.of.idiots.com." They deserve to be bit bucketed, and are at this site. If you use a virtual hosting service like EC2, you may still find yourself blocked or spam scored upwards due to the suspicious source (no one but Amazon really knows who is using a given IP address at a give time).
If you subscribe to an anti-spam service like MX Logic or Postini they may also provide a smarthost or SMTP relay service. These have the advantage of also being able to block outgoing spam and virii if you get an infection. These smarthosts are also well managed and unlikely to be blocked.
Sooner or later, some user is going to find a way to click on something shiny that leads to them getting infected with a spambot. If they have unfettered access to the Internet from their machine, your external IP address is going to quickly be listed on LOTS of different DNSBLs, and no one will accept your email if that's the same address your mail server talks on. Best solution is to make sure that the Exchange server is the ONLY system that's allowed to communicate on port 25 outbound (that's why you bought that fancy firewall). Second best is to use a different external IP address than the Exchange to NAT the normal user traffic. Just remember that some of the more aggressive DNSBLs will try to guess your external subnet mask and block all traffic anyway.
Read your mail server logs
There's a lot of useful info in there. You will probably be surprised to see a lot of messages like
450 Message delayed, IP address 192.168.97.42 can't be looked up.
451 Message delayed, greylisting in effect.
Looking through the logs will help you find delivery issues and fix problems before they get out of control.
Lots of admins also try to provide useful information about why your email was rejected or delayed. If you see links to places like Spamhaus or SpamCop you are going to have a long night finding your spam emitters and getting yourself delisted.
Personally I think that the way I see most people looking at Windows server logs sucks--one little window and you have to zoom in to see the details? Not really very easy to do for even a small server. There are apparently several tools out there to let you convert the logs to text files. I find plain text logs much easier to read. A few tools are listed here.
We are not Exchange admins. We just see many badly managed Exchange servers that are out there.
Exchange is a trademark of Microsoft Corporation.