Encode Your Email to Reduce Spam

Automated harvesting of openly exposed email addresses is widely regarded as the leading spam generating vulnerability today. Such exposed addresses are very easy to collect and are practically guaranteed to be valid and working addresses.

Furthermore, addresses harvested in this manner they are easily sorted by industry classification (based on the Web sites from which they are taken) for sales within targeted email marketing lists.

To help combat this problem and enable Webmasters and site owners to easily close this widely-exploited vulnerability, the OnlyMyEmail Encoder will generate JavaScript code that can be used to replace email addresses and the "mailto:" links that contain them.

JavaScript enabled browsers will render the address so that any web site visitors will see a normal looking text address or "mailto:" link, but address harvesting bots will not.

The OnlyMyEmail Encoder can be accessed and used by anyone, free of charge, through our collection of DNS Tools found at: www.onlymyemail.com/services/mailto-encoder.html

Spam Detection Rates, What the Numbers Don’t Tell You

Anyone who has looked for an email anti-spam solution is probably familiar with spam capture rate statistics. You’ve no doubt seen claims such as “Blocks 99.9% of spam” but what the capture rate doesn’t tell you is going to prove even more important to your overall filtering satisfaction.

While some spam campaigns are innovative and can be difficult for various filtering systems to catch, stopping most spam email is not too difficult. The real challenge is NOT filtering the good mail that end users want to receive in the process.

A spam filter’s claimed capture rate means nothing if you do not know their false-positive rate. False positives are good emails caught by the filters and marked as spam. A great capture rate will not be acceptable to the end-user if it comes with a high false-positive rate. The cost of lost opportunities and delayed responses to legitimate mail will exceed the benefit provided by the blocking of spam.

This aspect of filtering is so important that false-positive rates are the single most important factor the OnlyMyEmail Anti-Spam team considers when evaluating new filtering tactics and techniques.

To further complicate matters, not all false-positives are created equal. As long as users can easily train the filter to allow such emails in the future, they are pretty tolerant when it comes to blocking commercial emails such as a Costco, Expedia or Bank of America advertisements. They won’t even complain much if you occasionally trap high volume newsletters from ESPN, Motley Fool or MSNBC.

But if your filtering blocks legitimate user-to-user or critical automated e-commerce emails then the solution will be deemed unacceptable. Because of this distinction, capture rates must be balanced not only against potential false-positive rates in general, but “critical” false-positive rates as well.

Finally, in order to provide a positive end-user experience, the filtering system needs to be able to accommodate individual end-user preferences with minimal human intervention. Because not all users will agree on a single definition of spam, the best solutions allow input from users as to the types of email they individually want to receive, as well as those they want blocked.

For example, if you ask a handful of users about the the types of commercial emails referenced above, those from Costco, Expedia or ESPN, you will find that while many consider such emails valid, others will consider them spam. Because of this, no filtering solution can truly provide a useful and meaningful level of end-user satisfaction unless it can accommodate, on an individual level, which users consider what types of commercial mail to be spam and which users actually prefer to receive those kinds of messages.

While some systems attempt to provide end-user control by simply providing “Whitelists” and “Blacklists” in the real world these prove to be nothing more than error-prone band-aids because they cannot distinguish between legitimate emails from Support@Ebay.com, for example, and those from spammers that simply “spoof” the same address.

The ability of a spam solution to make decisions based on end-user preferences, with significant focus on not only blocking spam but on preventing false-positives, and to do so with minimal end-user effort, is what makes spam filtering such a complicated business.

“Effectively Perfect” Spam Filtering Hype

According to this article, a team of computer scientists at the International Computer Science Institute in Berkeley, has developed an “effectively perfect” method of filtering spam from botnets. The system works by reverse engineering the spam bot’s template to predict how it will vary messages in order to fool filters:

As spam is churned out, subtle changes are typically incorporated into the messages to confound spam filters. Each message is generated from a template that specifies the message content and how it should be varied. The team reasoned that analyzing such messages could reveal the template that created them. And since the spam template describes the entire range of the emails a bot will send, possessing it might provide a watertight method of blocking spam from that bot.

The hype around this tactic assumes that no one else has already implemented it (if we have, we’re not telling). Obviously this would be a good weapon in anyone’s anti-spam arsenal but touting it as “effectively perfect” is a bit hyperbolic. This tactic also fails to consider that the spammer’s templates themselves can also be designed to randomly mutate, thus making reverse engineering a much more difficult task, and dependent upon access to a large enough data sample.

The spam war has always been an escalating arms race. Whenever a “perfect” anti-spam tactic is developed elite spammers soon find a way to circumvent it. Shortly thereafter the technology finds its way to less resourceful spammers and the status quo is maintained.

Our own spam control system depends on continuous analysis of various existing spam attack vectors as well as identifying and responding to new spam tactics. Like the influenza virus, spam constantly evolves in order to survive. Accordingly, spam control techniques also evolve.

Eventually we hope to find a cure for spam. Until then we’ll just have to settle for doing a really good job of controlling it.

Should ISPs Block Port 25?

According to ISPreview, Trend Micro has apparently agitated British ISP’s by suggesting that they block their user’s port 25 SMTP access to external mail servers (connections to the ISP’s own mail servers would not be affected).

The suggestion was offered as a tactic to prevent botnets of infected personal computers from connecting to external mail servers, which is how many spammers send such massive amounts of junk email.

Interestingly, a number of articles and blog posts have been published recently that stand in opposition to this proposal, such as these articles on AllSpammedUp and ComputerWeekly.

Most of what we’ve read on the subject so far doesn’t answer the question as to whether blocking Port 25 is a good idea or not. What is clear is that very few people, even those with technical backgrounds, actually understand the issue.

Positions taken against blocking port 25 include claims that such blocking would:

1. Force sending email only through ISP mail servers greatly inconveniencing users who wish to send mail through accounts they may have through work, schools or other organizations.
2. Result in spammers shifting tactics to abuse other vulnerabilities, such as social networks.
3. Be ineffective because most SMTP servers also accept connections on ports 465 and 587.
4. Increase virus risks because: “Many anti-virus programs monitor port 25 by default, so blocking this port would leave users unprotected unless they manually change their security software settings.”
5. Create unspecified problems: “there is the possibility that the system will go wrong and block other things by mistake.”

With such a mixed bag of misinformation it’s easy to see why there is still debate on the issue. How can the facts be reasonably discussed when so few know what they are?

For the record, and to correct one erroneous point at a time:

1. Simply put, users don’t need access to port 25 in order to send mail. Almost any current email client can send outbound mail through the mail server of your choice using port 587. This being the actual port, as specified by RFC 4409 for such client submission. Enabling the use of port 587 typically only requires that the user select “Alternate Submission Port” in their client, if any effort is required at all. Because of RFC 4409 more and more email clients now automatically try 587 first, and only fall back to 25 if that is unavailable.
2. Claiming that Port 25 should be left open for spammer’s botnets to exploit so they don’t move on to more sophisticated techniques is laughable at best. It’s a “non” argument that could be used as disingenuous support against any and every spam filtering or virus detecting technique ever conceived; and it would be equally specious in every case.
3. It is true that many email servers (though not all) will accept SMTP to port 465 without authentication. It’s also true that spammers might very well modify their botnets to exploit this. For that reason, 465 should be blocked as well. Since it was never intended for SMTP that’s no real loss to anyone, either. By contrast, when submitting to port 587, a properly configured mail server will require the user to authenticate with a valid login and password and therein lies the key distinction. Allowing unrestricted access to 25/465 enables spammers to send email without any authentication, whereas 587 does not. Thus, while real users can still send mail through the server of their choice using port 587 (assuming they have the right to do so) infected zombies cannot.
4. The statement that “Many anti-virus programs monitor port 25 by default” might be true for mail servers, which both send and receive mail on Port 25. However, personal computers and other devices that are not mail servers receive their mail through ports 110, 143, 993, or 995. There is nothing on a personal computer that should be listening to port 25 and no security vulnerability created by using alternate ports for sending outbound mail.
5. As for the “possibility that the system will go wrong and block other things by mistake” it should suffice to point out that port 25 is only used for email, so this generic and uninformed fear of change is really just that.

While other weak and inaccurate positions can likely be put forth against port 25 blocking, there is not much substance to any of them. The only somewhat valid argument that can be advanced is that blocking port 25 would make it more difficult to run an actual mail server on a PC connected through a residential broadband connection. This obviously doesn’t effect the average user, whether business or residential, but is commonly put forth by techies who like to run mail servers on their home PCs… mostly just because they can.

In cases where a user wishes to run a mail server out of their basement or small office, their ISP could unblock port 25 for that connection, or they could configure their server to relay its mail through their ISP or another party via the submission port.

On the other hand, there is actually quite a bit of benefit to having ISPs block port 25 in that it neutralizes spam sending ability of most infected personal computers.

In order to understand this, you need only grasp a few key points:

1. ISP’s almost always allow access to their own mail servers through ports 25, 465 and also 587, so the only user that’s affected by any of this discussion is the one who wants to connect to the Internet through their ISP but who wants to send mail through some external mail server.
2. In those instances, the user’s email client software can submit to the mail server of their choice using the RFC specified port 587. A properly configured server will require the client authenticate on this port which keeps the zombies out, while allowing real users in.
3. Mail servers communicate with other mail servers using port 25. Allowing unrestricted access to external servers through port 25 just permits infected PC’s to pretend they are mail servers, sending mail directly to any other mail server on the Internet without having to have email access, authentication or privileges on any legitimate system.
4. ISP blocking of port 25/465 cripples the existing zombie botnets, leaving them unable to spam, but has no effect whatsoever on mail server to mail server traffic.

While blocking Port 25/465 won’t end spam, it will absolutely make it much more difficult for spammers to send the volume of email they currently do using infected PCs.

It will also have the effect of sparing a lot of small business from having their mail servers relentlessly pounded to the point of crawling or crashing altogether. As it now stands, millions of infected PCs can open mail server connections to any businesses mail server simultaneously, overwhelming bandwidth and CPU resources while also crowding out connections from legitimate mail servers attempting to deliver real email.

It’s also worth noting that many if not most of the major broadband providers in the United States (and elsewhere) already do block unrestricted access to external mail servers over port 25 and few if any end-users are inconvenienced or even know the difference.

Domain Name Disputes

If you own a domain or are listed as one of the contacts for a registered domain, it’s likely that you’ve been notified at least once about a “domain name dispute”.

Domain name dispute fraud is an interesting breed of email fraud. These scams tend to originate in Asia and claim to be from an Asian domain registrar that is proactively notifying you that someone is trying to register your domain name on one or more Asian top level domains (TLDs).

They capitalize on the fact that a lot of domain owners know very little about what domain ownership entails or even how their domain got registered in the first place. Consequently the targets of this type of fraud are liable to believe that not registering with the Asian TLDs will dilute their brand.

A typical domain dispute fraud email looks like the following (we replaced the name of the company that this was sent to with “fictionalco”):

Subject: Domain Name Disputes

From: “Robinson Zhou”<robinson@china-shengke.com>

To: “info”<info@fictionalco.com>

(If you are not in charge of this please transfer this urgent email to your CEO, thanks.)

Dear Manager,

We are a company of Domain registration service in China,have something need to confirm with you.We formally received an application on Mar.2nd,2010.One company which called “DM Investment Co. LTD” are applying to register ” fictionalco” as NET brand and Domains.

fictionalco.asia
fictionalco.com.hk
fictionalco.com.tw
fictionalco.hk
fictionalco.net.cn
fictionalco.org.cn
fictionalco.tw

But we find that “DM Investment Co. LTD” is not the original owner of the brand and trademark in the checking period,which belong to your company.so I need confirm with you .whether your company authorized that company to register these domain names.If you have done that,We will finish the registration for them and link to their website.
If not ,please let me know ASAP.
In addition, we hereby affirm that our time limit for dissent application is 7 workdays.If your company files have no dissent within those days,we will unconditionally approve the application.

Best Regards,

Robinson

Robinson Zhou
senior consultant
Tel: 0086-21-67150255
Fax: 0086-21-67150255
Mail: info@china-shengke.com
Website:www.china-shengke.com
Address: Room 201, No.45,Building 14, Pujiang Garden,Lane 303 Huhang Highway,Fengxian District,Shanghai. 201401

2010-03-02

Unlike so many fraud emails, this message actually has a reasonable “Subject:”, i.e. it’s not all capitalized; doesn’t have tons of exclamation points and isn’t from Dr. David (or some other first name). The “From” is fairly average but the “To:” is for “info”<info@fictionalco.com>”. This contains two clues:

1. Info@fictionalco.com is not one of the listed contacts for the domain (in fact the real domain that this was sent to is using whois privacy so nobody can find out who the contacts are).
2. The “info” address is a very likely to have been scraped from the company web site by an automated email address harvesting program. Note: you can prevent this from happening to your email addresses by using the OnlyMyEmail Encoder, which is a free tool we provide at: http://www.onlymyemail.com/dns_tools/encoder.html

The next clue is the first line of the message which makes the following request:

(If you are not in charge of this please transfer this urgent email to your CEO, thanks.)

Like the CEO is going to handle domain registration. Yeah right.

The main body of the message suffers from the same language issues that are seen in many other types of fraud emails: incorrect punctuation, spacing, capitalization and word usage. Apparently only legitimate businesses find it worthwhile to hire educated translators.

The most interesting thing about this type of fraud is that it originates from real Asian domain registrars. All of the contact information traces back to Shengke Network Co.,Ltd (bad punctuation from their web site) and no attempt is made to direct the recipient of the message to a specific contact.

Presumably whoever answers the phone is aware of this “business practice” and will gladly help you register the domain names in question, probably at an exorbitant rate and for a long time (the Shengke website only allows registration periods of 5, 10 and 15 years).

Technically this isn’t fraud because you really get to register domain names with Asian TLDs (albeit expensively). On the other hand, few businesses with registered domains actually need, or even have a use for domains on Asian TLDs. This is really just a way for unscrupulous domain registrars to unload “unused inventory”.

Here’s what you need to know to make informed decisions about the above:

1. The cost of domain registration from reputable registrars is currently around $5 to $15 per year for one domain. This is for domain registration alone and does not include hosting, web design or other related services. $20/year is very expensive for domain registration. (We’re looking at you Network Solutions.)
2. Additional services like whois privacy or renewal synchronization may raise the price slightly; commitment to longer registration periods may lower it.
3. Many registrars require a two year commitment for the initial registration but will allow singly year registrations after that. Registrars that require longer initial registrations (like the one above) should be avoided.
4. Whois tools can be found all over the web and used to look up the owner/availability of domains. Alternatively, typing the domain into a browser will often reveal whether or not the domain is registered. None of the domains in the above list are registered as of this writing and any of them could be registered with a more reputable registrar.
5. If you want to protect your brand, acquiring .com, .org, .net and .biz versions is probably sufficient unless you have a large presence in an area serviced by a different TLD like .com.tw (Taiwan) or .co.uk (UK).
6. All TLDs are reachable by the entire Internet so no matter what TLD your domain has it’s visible to the whole world with the exception of possible censoring by more repressive governments. (The country of Tuvalu has made a business of selling their country TLD (.tv) world-wide and domains like del.ico.us make words by using alternate TLDs.)
7. Domain naming is controlled by the Internet Corporation for Assigned Names and Numbers (ICANN) and not by individual registrars.

Real domain name disputes are quite common but they always arise after someone has registered the domain. The legal issues surrounding the question of whether first come first served registration takes precedence over recognizable brand names are still being worked out. Recognizable brand names have the advantage though, because they tend to have more money for lawyers.

For more information on domain name disputes see the following:

ICANN Domain Name Dispute Resolution Policy

BitLaw – Domain Name Dispute Section

Wikipedia – Uniform Domain Name Dispute Resolution Policy

Are You Being Tracked?

There’s more to spam than just banging out a million emails a day. If at all possible you want those emails to go to addresses that are active so people will see your spam. Because of this, spammers, like any other marketers, want to know if anybody looks at their “ads”.

Not all spammers keep clean lists but if your address cannot be identified as active, it will most likely be dropped by the ones that do. And, the less your address is circulated by spammers, the less spam you’ll get.

The two most popular techniques for tracking spam campaigns are:

1. Tracking Links
2. Tracking Images

Both can be avoided with minimal effort.

Tracking Links

If you check out what the “Free Porn” link in the spam you just got actually refers to you’ll often see something like this:< /p>

• http://www.spamexample.com/a/b/d7resusWafeMAqUP

or this:

• http://www.spamexample.com/x/y/index.php?ID=d7resusWafeMAqUP

The main thing to notice in the examples above is the group of random characters which serves as a unique identifier for the address the message was sent to. When the spam messages are generated each one gets an ID that will be stored in a database along with the email address it was sent to. By monitoring the web server logs at spamexample.com the spammer can tell which addresses clicks came from.

The simplest way to avoid being tracked by links in email messages is just not clicking them. (BTW this applies to so-called legitimate advertising as well.) If you don’t click the link, no request will be sent to the spammer’s web server and they won’t know you saw the email.

Tracking Images

A trickier way of tracking messages is by including links to images in the message HTML. When presented with an image link, some email clients will automatically request a copy of the image from the server where it resides. Using the same random identifier trick mentioned above with the image link the spammer can tell you opened the message as soon as you download the image. The really sneaky part is that you won’t usually know you downloaded the image.

Newer email clients will, by default, wait for your approval before retrieving remote images and will usually say something like “For your protection images in this message were not downloaded.” This prevents the email message from automatically identifying your address for the spammer. If your client is doing this you have nothing to worry about as long as you’re not telling the client that you want to see the images. If you are asking the client to get the images you’re asking to be tracked.

If you have an email client that downloads all images by default you’ll need to look for the setting that tells it not to. If your client does not allow you to disable image downloading you should use a different client. Unfortunately, detailed instructions for this are beyond the scope of this post. If you can’t figure it out, try to enlist your neighborhood geek:)

Summary

Avoid being tracked by spammers by resisting the urge to click on their links and make sure your email client asks you before downloading images.

Currently not permitted to relay through this server – Worst Rejection Ever!

Of all the confusing and convoluted mail server rejections commonly in use, “Currently not permitted to relay through this server” causes more Support tickets for us than any other. Worse yet, it’s not even an error that we use, so we find ourselves constantly trying to coherently explain what someone else’s mail server is saying.

Given that this is arguably the worst mail server error message ever, we’re going to try to make sense of it once and for all.

When reviewing the following example, realize that the IP addresses and server names will change to reflect the server that is sending the email and also the one which is refusing to accept it. We’re replacing the receiving/rejecting server IP with 111.111.111.111 and the sending server’s IP with 222.222.222.222.

Also note that the layout and formatting for these rejections can often be confusing as well, with lots of line breaks and “550′s” scattered about.

Disclaimers aside, this ugly bounce/rejection/NDR message typically says:

SMTP error from remote mail server after RCPT TO:: host 111.111.111.111:
your-mailserver.com [222.222.222.222]: is currently not permitted to relay through this server.
Perhaps you have not logged into the pop/imap server in the last 30 minutes or do not have SMTP Authentication turned on in your email client.

While the language is fairly uncomplicated, at the same time it’s also impossibly confusing for the average user to decipher. Further, because of the dual nature of this error message, it actually confuses many experienced email and network admins too.

What on earth does this mean?

While the “currently not permitted to relay through this server” is a convoluted explanation, what it means is that the receiving server doesn’t believe that it is supposed to accept messages for the recipient domain, so it’s refusing/rejecting the email you sent.

Instead, the recipient server thinks that you’re trying to use it to deliver/relay messages to some outside domain for which it is not responsible.

Usually this is seen after someone manually changes settings on a mail server or some automatic update is applied and the server which used to happily accept mail for “recipient.com” no longer thinks it’s supposed to host mail for them and rejects with this error instead.

If this is the case, then someone in the email admin or support group will need to work on the recipient’s mail server to reconfigure it to once again accept mail for the recipient domain.

On the other hand….

On the other hand, these error messages also contemplate that perhaps you’re not some outside mail-server trying to deliver inbound mail, but instead you might be a local user with a mail account on the server who is trying to send outbound email via SMTP but you (or your email software) forgot to login and authenticate.

The fact of the matter is that most mail-servers cannot actually tell the difference between another mail-server connecting to deliver inbound mail or an individual user who is connecting to send outbound mail. That may sound hard to believe, but it’s sadly true.

And that is why this part is confusingly tacked added to the end of the rejection:

Perhaps you have not logged into the pop/imap server in the last 30 minutes or do not have SMTP Authentication turned on in your email client.

Having this one rejection message trying to cover two completely different scenarios, combined with the most confusing of language, is what causes so many problems and misunderstanding.

Now, given that the above explanation still might not make perfect sense to the average user, let’s re-write the rejection to say what it really means:

We’re sorry, our server will not accept your message.

If you are a mail-server connecting to our system to deliver this message to us, then please be aware that our servers are not configured to accept mail for the recipient’s domain.

If you are a local user, trying to send this email outbound for delivery, the problem is that we don’t see you as having logged into the SMTP server. Please download/check for new mail before sending, and you might also need to configure your email software to use SMTP Authentication.

If that doesn’t work, you might need to restart your email client software.

Granted this still probably won’t make perfect sense to someone with no knowledge of how email actually works, but it’s hopefully a lot clearer for the rest of us.

If restarting the mail client and configuring it for SMTP Authentication don’t get you past this error, then again, someone in the admin or support department for your domain will have to verify your account status and/or check their SMTP logs to figure out why your mail server is still rejecting your connections.

What is a Mail Exchanger (MX) Record?

Unlike a postal address, which contains several pieces of information (name, house/apt. number, street, city, state, ZIP code) about where postal mail should be delivered, an email address only provides two pieces of data: the mailbox ID and the domain name.

These are neatly separated by the & sign with the mailbox ID to the left and the domain name to the right. If your address is username&OnlyMyEmail.com then your mailbox ID is username and the domain name is OnlyMyEmail.com.

Fortunately, given how email works, this is enough to ensure accurate delivery.

Delivering Email

From the perspective of the Internet at large, the domain name is really all that matters. It’s up to the server that handles email for a given domain to determine which mailbox should receive the message. All the sending server needs to know in order to deliver a message is the recipient domain.

Since the right-hand side of an email address is the domain name, this is easy enough to figure out. Unfortunately, computers don’t really understand domain names the way people do. What computers understand is IP addresses.

Enter DNS

This little fly in the ointment is due to the fact that IP addresses like 216.234.108.230 work great for computers but all those digits don’t make sense to us humans. To us, OnlyMyEmail.com is much easier to remember than 216.234.108.230. So the trick is to have people use domain names and computers use IP addresses.

The Domain Name System (DNS) bridges the gap between human readable domain names and computer friendly IP addresses by mapping domain names to IP addresses. Every domain has a set of DNS records that connect its name to the IP addresses of the servers that supply services for the domain. These records are stored on the Name Server for the domain and made available to the world so that the domain can be located.

So What About MX Records?

MX records are a specific type of DNS record used to locate the mail exchanger (M as in Mail and X as in eXchanger) for the domain specified in the domain name side of the email address. The mail exchanger is any computer configured to accept delivery of email for that domain.

When email is delivered, the destination server is determined by looking up the MX records for the domain and sending the email to the targets specified in therein.

A typical set of MX records will look like this:

onlymyemail.com. 300 IN MX 10 mailfilter1.onlymyemail.com.

onlymyemail.com. 300 IN MX 20 mailfilter2.onlymyemail.com.

onlymyemail.com. 300 IN MX 30 mailfilter3.onlymyemail.com.

onlymyemail.com. 300 IN MX 40 mailfilter4.onlymyemail.com.

Each line is a single MX record and each domain can have several. This allows the owner of the domain to specify more than one server that will accept delivery. Multiple servers may be desirable in situations where several servers share the load for one domain, as backup servers or both.

MX records consist of the following (from left to right):

• Domain Name – This is the name of the domain to which the record belongs. The trailing dot (.) at the end of the domain name is required.
• Time To Live (TTL) – In order to avoid constantly looking things up, the results of DNS lookups are usually saved (cached) by the machine doing the looking. TTL is the number of seconds that can pass before the record has to be looked up again.
• Class – Allows DNS records to be used for networks other than the Internet. Since this is rare, class is pretty much always IN for Internet.
• Type – For MX records type will always be MX . That’s why they’re MX records (as opposed to A or NS records).
• Priority/Preference – This establishes the order in which servers should be contacted when there are multiple MX records with multiple servers.
• Target – The hostname of the computer where mail should be delivered. This also requires the trailing dot (.) to work correctly.

Editing MX Records

DNS records are generally maintained by the hosting provider for a domain or, for domains that handle their own DNS, by the IT staff of the domain owner.

Note: When DNS records are not maintained in-house they must be accessed using the interface provided by the hosting service. This may allow the editing of individual fields in the records, line by line editing of record sets or a facility to upload files containing DNS records. Since DNS editing interfaces are all slightly different, a click-by-click how-to would occupy several volumes. For the sake of brevity just keep in mind that each line in a set of MX records for a domain represents a way to deliver mail to that domain.

The usual reason for editing MX records is to change where email is delivered for a domain. This is often done to have email sent to a company owned email server or an email service provider (like us).

Sometimes MX records have to be edited to re-establish these services after changing web hosting as web hosting providers will often reset the MX records of newly hosted domains to point to their own mail exchangers.

Of the six fields in an MX record only three make sense to change. Changing the domain name makes the record for a different domain; the type must remain MX or the record ceases to be an MX record and the class is always IN.

This leaves TTL, priority and target available to change.

Time To Live (TTL)

TTL is frequently 86400 which is 60 X 60 X 24 seconds or the number of seconds in a day. This means that the longest it can take for cached copies of your MX records to update is 24 hours. This is normally quite effective since MX records don’t change very often.

However, it can be useful to update the TTLs on MX records in advance of a change in order to make them propagate faster during the change. Lowering the TTL to 300 (5 minutes) a day before making the actual MX changes will cause cached records to be updated in 5 minutes instead of 24 hours and make mistakes reveal themselves much sooner. Once the changes are proven correct, TTLs should be set back to 864000 to keep the hosting server from being deluged by DNS cache update requests.

Priority/Preference

Both priority and preference are likely terms for this field. Either way the field should contain a decimal integer (a.k.a. a number). Records with lower numbers are tried first, thus a record with a priority of 10 would be tried before a record with a priority of 20.

It is generally recommended to number in increments of 10 or so to allow new records to be inserted between older ones without having to renumber all of the subsequent records. For instance, if your preference settings are 0, 1, 2, 3 and you want to add a new highest priority server you have to raise all of the other priorities by 1. Whereas, if your preferences are 10, 20, 30, 40 you could stick in a new highest priority server by setting it’s priority to 5 without touching any of the other records.

Target

The target is the most critical of the editable fields in an MX record. TTL and priority/preference can be off by a little (as long as they’re numbers) without interrupting mail delivery. Target on the other hand has to be perfect or it won’t work.

First, the target must be a Fully Qualified Domain Name (FQDN). In this context the the outstanding feature of the FQDN is that it includes the trailing dot. If the trailing dot is omitted the hostname won’t work. (Some interfaces will catch this and fix it but don’t count on it.)

Spelling is also important. Computers don’t gloss over spelling errors the way humans do. It only takes one incorrect character to cause mail delivery to fail, or worse, deliver mail to the wrong domain.

Finally, it is important to note that some interfaces will allow the use of an IP address instead of a domain name. While this may actually work, it is contrary to the DNS specification (see IETF RFCs 974, 1034 and 1035) and may cause email from your domain to be rejected by mail servers that are strict about RFC compliance. This can be extremely difficult to troubleshoot because it only causes intermittent failures. It is much better to avoid this problem altogether by using FQDNs instead of IPs in MX records.

Verifying MX Records

Most hosting providers will tell you what they think your MX records are but it can be worthwhile to get a second opinion. Finding and using a good MX lookup tool (or several) will often help with troubleshooting by revealing discrepancies between what you think is in your MX records and what is actually returned by a routine MX lookup request for your domain.

More Information

Wikipedia – MX Records

What Are False-Positive Emails?

When spam filtering systems block the delivery of a legitimate email, this is referred to as a “false-positive” result.

As it turns out, doing a good job of stopping Spam is not nearly as difficult as avoiding false-positives results. Eliminating false-positives is the most difficult problem for email recognition and filtering technologies, and is what separates the better mail filtering solutions from the rest.

A realistic expectation is that every useful spam filtering system or technique will create false-positives, and especially with regards to automated notifications, mass-mailed commercial newsletters and “legitimate” direct marketing messages.

Regardless of marketing claims, these types of false-positives are unavoidable simply because automated and mass mail systems seldom verify that the addresses they are sending to are legitimate, or that the recipients specifically requested such promotional emails in the first place. As a result, they often send to recipients who never subscribed, and this results in those emails being reported as spam.

Further, as a practical matter and in real-world applications, few users really care if a hobby newsletter or credit card marketing offer from Amazon.com is delayed or deleted by their spam filter, as long as such instances can be easily discovered and corrected so they do not occur again in the future.

On the other hand, the delay or deletion of personal or business communication or a transactional confirmation or receipt can often have significant negative consequences, such as missed appointments, lost opportunities or damaged business or personal relationships.

With this in mind, the real measure of performance and accuracy when it comes to blocking legitimate emails is the measurement of what can be referred to as “critical false-positives.” These can be loosely defined as the blocking of human to human correspondence or legitimate (and specifically non-mass mailed) notifications such as purchase confirmations and other transactional emails that are event specific and unique to the recipient.

Unfortunately, all third-party testing that we’ve seen to date, including online reviews and other comparative analysis, simply don’t do a very good job of accurately making this distinction, if they even attempt to measure critical false-positives” at all.

The result is that while such analysis and review can often be very accurate as it relates to spam-capture rates, when it comes to measuring critical false-positives you’ll need to evaluate them for yourself.

The only reliable guide is going to be experience, typically base on a live-trial of various filtering solutions in order to see how they perform in the real world, and against your organizations unique email stream.