Nick Gasper
This user hasn't shared any biographical information
Homepage: http://www.iphouse.com
Posts by Nick Gasper
The Pressure of “New Media.”
Apr 29th
As someone who has been *ahem* ‘asked’ to write on various topics, I can appreciate the pressure that new media puts on companies. Traditional media is predictable; pay money, gain access. Release statements quarterly, crafted with your company’s message. Coordinate your ads with your message and the image you hope to portray. Push out positive messages and suppress negative ones. It certainly takes time and effort, but you can reasonably expect your efforts to pay off.
New media is much more unpredictable, it’s hard to maintain a consistent image without fading into the ether. It’s harder,still to control information, good or bad, that can effect your company. While there is a high amount of passion with the participants of new media, this can lead to a low signal-to-noise ratio. You’re competing with a lot of people out there and if your stuff isn’t interesting, it’ll just be a ripple in the ocean.
Request For Comments
Feb 4th
One of the many terms you’ll hear thrown around an internet service provider is Request For Comments, aka, RFC: “This isn’t per the RFC!” or “We follow the RFC!” or “Read the <expletive deleted> RFC!” So what is an RFC, and why do you want to know what it says.
RFCs are, in a nutshell, the description of how a program, or procedure should work. The history of RFC is long and boring, but basically, they’ve been around since the ARPANET Project began, as written or typed memo that were literally Requests for Comments, open ended questions that someone wanted to solicit answers to. As ARPANET grew, RFCs became the standard way to record procedure, and a way for people to implement the fundamental technologies that make up the Internet as it stands today. Today, RFCs are managed by the Internet Engineering Task Force.
Anti-spam Part 2, Bayesian Spam Filtering
Jan 5th
Well, Andrew and I kinda stepped on each others toes last month, but I’ll go into a little more depth on some of the things he touched on. Last month I talked about the frontend of our anti-spam filtering via Greylisting.
At the opposite end of our anti-spam system is content filtering. We use a third party vendor for this, MailFoundry in the form of two appliances. An appliance is a machine that you plug in, and is suppose to work with minimal configuration.
Now the MailFoundry appliances are “black box” systems. We don’t know how they work exactly, but we’re pretty sure that one of the techniques they use is Bayesian spam filtering.
Bayesian spam filtering uses the concept of probability to evaluate each token in a message, assign a weight to each, give the overall message a rating based on this weight, and evaluate the message based on a preset threshold.
Ok, unless you’re up on your statistics or logic based calculus, or a computer nerd with Wikipedia handy, I know your eyes just glazed over. Rest assured, you are not alone.
Anti-Spam Part 1, Greylisting
Dec 5th
I’ve occasionally gotten calls from system administrators about a “mail bouncy thing” they notice in their logs when they send mail to us. They find it weird and sometimes frustrating and many consider it a silly anti-spam technique. Well, that would be greylisting, and while it’s weird, it also drops a lot of spam getting through to our customers.
It’s also our first line of defense against spam.
Greylisting is a very simple technique. It is a daemon attached to database that keeps track of who externally sent mail to whom internally, including from what IP address. When a new sender/recipient/IP-address (or triplet as it is called) combination pops up, it bounces the transaction with a temporary, 450/451 response code. This is per the RFC and any properly implemented SMTP server should adhere to it, re-queue the message, and send it again later. If the server sends it before a specified “too early” window (in my case on my personal server, 2 mins, but that’s fairly aggressive) it’s temp-failed (tech term for try again later) again. If the message comes back after this “too early” window, but before a 24 hour expiration window, the message is passed through, and an entry is made in the database allowing that triplet to send mail unhindered for a few days (depending on configuration). If enough messages come from the same ip address and domain pass Greylisting, that whole domain can be automatically white-listed through the check.
The goal of greylisting is not to penalize legitimate mail servers but only to stop non-compliant botnets from getting through.
Greylisting is very effective because it keeps non-compliant SMTP servers from sending mail to our (or even your) servers. Most virus infected computers that send or relay spam won’t re-queue messages, or will re-queue them for only the briefest amount of time. Why? Their goal is to blast as much email/virus payload as possible, and any slowdown or long retry time is very counterintuitive to this goal.
Problems with greylisting are legitimate, by mis-configured SMTP servers either not re-queuing the messages because they are set to treat 400 series bounces as 500 series (permanent) bounces. Or they re-queue the messages, but report to the original sender that the message bounced.
Yahoo implements a more esoteric set up, where they have 4 servers listed in the MX record, and at any time, any of them will bounce messages. This is another way to test for non RFC compliant servers, as a server is supposed to try all of the MX entries in turn, by weight value. Most virus infected computers won’t do that. At least that is what it looks like from the outside.
Because some of our users may have problems with receiving mail, our web-based interface, ipMom, gives you the option to disable greylisting. If you log into ipMom with your email address and password, you’ll notice a “Greylist” option . Set it to off, and greylisting is no longer affecting your mail. Keep in mind that this does let more spam into the system, although our other anti-spam protections may still catch them.
I hope that helps!
So who hosts what in the where now?
Nov 20th
One of the most common points of confusion for our customers domain registration and DNS hosting. DNS isn’t exactly the easiest thing to understand, nor is domain registration, so it’s natural that a lot of people would find the whole thing baffling.
The first thing to understand is the Registrar. A registrar is a company that is accredited, and allowed to work with ICANN ( The Internet Corporation for Names and Numbers). ICANN actually maintains domain names and their information. You pay a registrar for your domain registration, and they, in turn, pay ICANN and provide them with the domain’s information. There are other parties and services involved, but in the interest of keeping it simple, that’s how it works.
Once the registrar has the domain name registered and reserved, actual Domain Name Servers need to be assigned to it. DNS is the service that turns the domain name, say, example.com, into its associated IP address. Humans can remember words far better than numbers. And computers deal with numbers. This is why we have DNS.
It also tells servers where to send email and what IP addresses various services may use. Each service normally has an A (or address) record. For example, an ftp server, ftp.example.com, may be on one IP address while the website, let’s say www.example.com, may be on another. Mail routing is controlled through the MX (mail exchange) record, which must point to a host name, like mail.example.com instead of an IP address. Canonical Name records and TXT record are used for more specialized purposes.
Usually, a registrar defaults to using their in-house nameservers. You can use these servers, putting in the information from your hosting company, usually by using a web based interface. However, we feel it is a better idea to switch the nameserver to your hosting company’s. That way, if your hosting company makes a change then they can update your DNS automatically alleviating your need to worry about these technical details.
DNS can be tricky and it is absolutely critical that your information is correct. One small mistake can cause you to not receive email, or not be able to view your own website. Many outages are associated with DNS problems and can easily be avoided by making sure the right information is in the right place.
Now, there are PTR (or rDNS) records that often are confusing. Most DNS queries are like looking up a name in a phone book directory, but you look up a server name to get the IP address (instead of a phone number). There are a few instances where you want to check the IP address and see who it belongs to, kind of like a reverse directory search of a phone number to see who’s calling. This is called a reverse DNS check.
This most often come into play when mail servers want to check the legitimacy of the SMTP servers that are sending them messages. If they query the IP address and get mail.example.com (or some other, similar Fully Qualified Domain Name) they let it pass. If they get something like 192-168-123-45-adsl-dynamic-customer.isp.net, they may reject or quarantine messages. These records are maintained by the ISP who provides the IP address, so if you run a server out of colocation space or off your Internet connection, you’ll want to contact the ISP to update that information.
Well, this was a very basic summary, hopefully it helps!
