Modwest Blog

OnSite upgrade: DNS Management!

We've just launched a new version of OnSite with one big new feature: DNS Management. Thanks to our Software Engineer Jacob and the rest of the team for making it happen. 

The new feature is under Domains -> Manage DNS currently and is available only to account administrators. Using the new tool, you'll be able to point specific hostnames at your local office network, or a blog hosting service, or anything you like. And, if you get in trouble, there's always the 'reset to defaults' option to revert your changes to the records originally created for you.

As always, use the 'Report Bug' feature if you encounter any unexpected behavior or errors. Thanks!

-JM

GoDaddy? Helo? Ehlo?

Earlier this week we learned that GoDaddy was blocking legitimate mail from Modwest customers to GoDaddy customers. A quick call to their HQ revealed that they were blocking one of our mail servers because of a "bogus helo" problem, which, in their words, generally indicated the presence of a spam or virus outbreak. Once we eliminated this possibility and ensured our strict spam policies were being followed, I asked Mike, our senior sysadmin and Operations Manager, for his analysis of the GoDaddy's policy. Here's what he had to say:

Why is the policy of checking SMTP/ESMTP HELO/EHLO bad?  RFC2821 (which supersedes RFC821 as the SMTP/ESMTP standard) Section 4.1.1.1 describes the SMTP HELO and ESMTP EHLO Command, response, and requirements.  An EHLO or HELO is a MUST for SMTP clients.  RFC2821 Sec. 4.1.1.1 states exactly this "The argument field contains the fully-qualified domain name of the SMTP client if one is available."  There are many cases where one is not available.  Or where an accurate one is not available.

Now, strictly speaking, if one can't determine a valid domain you're supposed to use what RFC2821 calls an "address literal".  This amounts to your IPv4 or IPv6 address enclosed in [].  All of this is problematic.  In the case of using a domain name, what is the "correct" domain name?  Well RFC2821 makes that very clear.  Section 3.6 addresses what a domain name is in this case.  Specifically it states:

   * The domain name given in the EHLO command MUST BE either a primary host name (a domain name that resolves to an A RR) or, if the host has no name, an address literal as described in section 4.1.1.1.
   * The reserved mailbox name "postmaster" may be used in a RCPT command without domain qualification (see section 4.1.1.3) and MUST be accepted if so used.

So the second bit isn't applicable in this case.  We're talking about a domain, not an address, but the second first part is.

In our case we have a large mail cluster whose primary host name is mail.modwest.com, which has an associated A record.  The RFC does NOT make any requirement as to that A record matching the IPv4 or IPv6 address we're connecting to the remote host from.  But when presented with this as a HELO/EHLO domain, GoDaddy refuses the message with a hard failure.  So our case of using the HELO/EHLO is clearly supported by the RFC.  GoDaddy refusing to accept the mail at that point, claiming a violation of HELO/EHLO being refused is unsupported by the governing standard in the case that our server says "EHLO mail.modwest.com".

Now, it is possible that GoDaddy is rejecting mail because of suspected virus load coming from a particular machine, but again, it should not be stating the problem to be an invalid HELO/EHLO if this is the case.  If you can't accurately identify to the sender the reason why you're rejecting a message, at the time you reject it, you should not reject it.

So why might the domain name not be available for HELO/EHLO?  It may be a case of DHCP environments, where you don't know what your rDNS should be. It may be the case of a large cluster of machines that appear as the same machine.  It may be the case of a single machine with multiple interfaces. (Only the kernel initially knows the interface and therefore IP that was used for an outbound connection, unless you explicitly force them to come from a particular IP, but that can have other nasty interactions with stateful firewalls and reverse path filters. )

So there you have it. GoDaddy, we'd love to work together with you to reduce spam and malware. But can you let our customers' legitimate mail through to your customers now? We're pretty sure both sides would appreciate it.

UPDATE 4/20: GoDaddy says they've unblocked the mail server in question, and it seems to be the case.

-JM

Modwest in Motion

We've recently had the honor of winning the Transportation Best Practices award presented by Missoula in Motion,  a program "designed to help local businesses, institutions and individuals address transportation issues within the Missoula community."

Part of the promotion of the program involves videos of the winners, and a local television crew shot and produced this two-minute piece, which features several of us talking about how we get to work in the morning. Speaking of that, Bike-Walk-Bus week is coming up...

Trials and Travails of Email Filtering

Not counting our managed servers or VPS plans, Modwest handles close to a million messages a day. And mailbox owners (including me!) reasonably want 2 things:

1. Keep junk and malware out of my inbox.
2. Give me all my legitimate mail.

Turns out it's really difficult to meet both goals 100% of the time. We could maybe guarantee #2 alone by delivering absolutely everything, but with 87% of email traffic consisting of junk mail, that solution probably wouldn't be appreciated by most!

So we do our best to filter out only the bad stuff that nobody wants. There are a lot of ways to try and do this, each layer of effort knocking out another portion of junk mail. (We describe some of these measures in our Knowledge Base here.)

We also provide a fair bit of control over how each mailbox handles spam within OnSite -- that's a goal of ours, to put maximum feasible control over spam handling to each mailbox owner, and we've got some additional control features planned. (The importance of recipient control over filtering was explored in a controversial article by the Electronic Frontier Foundation.)

Microsoft says that certain file attachment types are "high risk", and we know that certain filenames are associated with particular viruses and phishing attempts. Most would agree that we should try and prevent these potentially malicious attachments from being delivered.

We expend a fair bit of human time and CPU cycles trying to ensure both delivery goals mentioned are achieved. And yet the system's imperfect -- we regularly hear from customers who receive too much spam, or (infrequently) had a legitimate mail blocked or flagged as spam. It's a hard problem, but one we're committed to continuously improving.

All this leads one to wonder: Is email dead?

What do you think? What additional spam controls or filtering improvements would you like to see at Modwest?

-JM

Howdy! And Network maintenance tonight

An introduction first - I'm John Masterson, a Modwest co-founder and general overseer of Support and Operations around here.

As recently announced in OnSite and our Status Page, we'll be taking our network offline briefly this evening for a router upgrade. This affects "everything": shared accounts, managed servers, and our new VPS accounts. Maintenance begins at 11PM Eastern Time and will last from 15-30 minutes.

This is a vendor-recommended upgrade from Juniper and offers numerous fixes and features, including "80,000 microsecond packet buffers", "ultimate-hop popping", and other network sorcery that ensures continued secure, reliable communication between your visitors' browsers, and our servers.