MV Communications Newsletter: July 2004
Unfamiliar or bizarre terms that you run across might be in the newsletter glossary (-- if not, suggest that we add it.)
We do hate to miss June, too, because June is our anniversary month. MV was incorporated June 21, 1991-- so we've completed our 13th year as an incorporated ISP. Our roots go back a little further than that, as some of you know. If you're curious, you can find a brief history of MV on our web page at www.mv.com -- just click on the "About MV" link and find it there. It's a little out of date, but then again, history always is and, like all history, it could use a little updating.
PHP lets you write programs within your web pages; programs that are executed on our web server as part of delivering web pages or accepting data from web clients. Note that it is possible to write malfunctioning PHP programs: we may disable any PHP programs that are observed to be doing malicious things, abusing resources, or going against our terms of service.
Executive SummaryThis is a fairly long-winded section: the bottom line is that we are going to be implementing the filtering of TCP port 25 packets to and from IP addresses that we dynamically assign. These port 25 connections will only be allowed to and from our mail servers. We originally announced this a few months ago (in the March, 2004 newsletter -- specifically, here.)This will not affect most of you, as almost everyone with a dynamically assigned IP address already uses our mail servers anyway; these filters won't change anything for you. However, it will be good for you to at least know about the "submission" ports mentioned later on (see the "what" subsection). The initial goal of this change is to help block abusive email (e.g. with spam or virus content), especially messages that are sent from compromised computers without the owners' knowledge. This will also help prepare for other changes to email that will be coming in the future. Skip the "Why" subsection if it doesn't appeal to you, but please at least glance at the "What" text. Why? Some backgroundAs spam and viruses and other predatory activity have become more and more prevalent on the Internet, biting into our productive use and enjoyment of the Internet, the old mechanisms that have long been in use in exchanging email are being revised and updated. SMTP (the Simple Mail Transfer Protocol) was originally designed in a fairly open atmosphere, where it was simply assumed that any computer could connect to any other computer and transmit email; that any email message so sent was trustworthy and good; that if an email message was not directed to the system receiving it, that system would simply be polite and attempt to deliver it to the intended destination with no questions asked. This design works well when everyone is a contributor, when no one wants to fool anyone else, and everyone always operates in the best interest of everyone else. Unfortunately, as we've found, systems designed on such levels of trust are ripe for exploiting by those who wish to prey on others, by those who think of others on the Internet as opportunities or as targets, or by those whose goals are not positive. Part of what makes email so valuable is its openness: you can send a message to anyone with an email address without having to make a formal advance arrangement. In that regard it's just like conversation: you can walk up to anyone and talk to them. However, one of email's drawbacks is its susceptibility to abuse: how easy it is to contact millions of people, and how little accountability and traceability there is in the system. Now, there are broad efforts to tighten this up-- to try to mend the system without breaking it. Many of these involve new techniques for establishing or verifying trust relationships, and of identifying the senders of mail (if not simply verifying a responsible organization involved). And we will indeed be working to participate in some of these as they develop. But one simple change is to clarify the roles involved in sending mail, and to make the participants act according to what role each plays. Originally there wasn't much of a dividing line between these roles: every system that was involved in SMTP email transfers simply talked to any other system. But clearly there are several different roles played by the parties involved in the email system. These include:
In the traditional email system, the these layers were blurred-- in fact, all roles often looked alike, with all parties simply using SMTP connections to talk to each other. Significantly, there was no functional distinction between an originator system and a system engaged in email transport. And in a world where the mail transport system is abused in all sorts of ways, making this distinction turns out to be an important way to add some traceability and accountability for messages that are injected into the mail transport service. For example: the vast majority of spam and viral activity on the Internet these days comes from personal computer systems that have been compromised in some way. Usually this compromise is via software that has been inserted onto the target computer without the owner's knowledge (e.g. by a virus). Writers of such software know that they can use the compromised system to connect to a great number of different SMTP receiver systems on the net and deliver spam or virus email to each one, in essence taking on the role of a mail transport service, sending the tainted messages a few at a time to a large number of systems. By the time the abuse has been detected by the world at large, the damage has been done. However, when an originator can only submit mail to servers that it is authorized to use, it's easier to detect and isolate systems that are infected or that are behaving badly for any reason. It's also a little harder for virus authors to correctly make use of authorized submission servers than it is for them to simply fire email messages off to millions of random targets. And, it's easier to hold the authorized submission server accountable for messages that it passes along. For these reasons, the process of email origination and submission are being made distinct from email transport. What?As we said, we'll be adding the blocking of TCP port 25 traffic to and from all IP addresses that we dynamically assigned. This means that if you've got a dynamic IP address, you will need to configure your email client to use our mail servers for outgoing mail, or alternatively to use a submission port on some other mail server that you are authorized to use. (See the "submission" section below for more on these.) If you've got a dynamic IP address, you're almost certain to be doing this anyway. What about static IPs? If you are an MV customer with a statically assigned IP address, you won't be affected by this change, at least not yet. However, the reasons for separating mail submission from mail transport may very well apply to you even if you have a static IP address. Very few end users need to run SMTP transport systems, and as the technology of email delivery continues to evolve, that will simply become more true. And over time, receiving systems will become more restrictive about what connections they will accept. So how do you, as an originator of email messages, change to using an authorized submission server? There are just a few ways:
We expect that modern email clients and new versions of existing email software will be changing to use the submission mechanisms by default. Summary thoughtsCongratulations if you've stuck with it to this point. Just some remarks to make in closing: This is not new. The "submission" port was put into an RFC (RFC2476) way back in 1998. Many if not most ISPs are already blocking port 25 access to and from dialup and other users. Even though we've always been very aggressive in promoting conscientious use of the net and discouraging abuse, we're behind the curve on this one. We've been torn between not wanting to block access to anything, and helping to preserve the integrity of the Internet. Plus, we're old geeks who grew up with the old open unrestricted SMTP model, and the notion of adding restrictions never sits well with us. We also understand that a lot of you are heavily into computer technology and have some of the same attitudes as we do. However, email has changed a lot, and will continue to change. It's beyond dispute that computer systems have vulnerabilities that will be exploited. As much as we'd like to hope that people will never click on attachments, never run untrusted software, never respond to spam, never visit sites with malicious code, never operate software with bugs in it- we must deal with reality. We need to do what we can not only to help protect our users from the rest of the net, but to protect the rest of the net from anything bad that might originate here. There will be more to be done in both these areas over the coming months and years. This is just one step. Some of the changes to email coming down the road will favor the use of well-known, trusted mail servers, and mail servers that have specific designations to originate mail for given domains. Even if you'd like your system to contact all SMTP receivers directly, those receiving systems will be enforcing more and more restrictions as time goes by.
You probably read all about the FTC's (US Federal Trade Commission) decision not to establish a Federal "Do Not Spam" list, similar to the "Do Not Call" telemarketing list established last year. The FTC concluded (and rightly, we think) that creating such a list at this time would be futile, and could do as much harm as it did good. Read the full report if you wish. There are also a couple of discouraging news items relating to why spam continues to be such a scourge. First, earlier this year the FTC solicited comments from the public about federal anti-spam legislation. About 12,500 comments were received. Approximately half were form-letter comments from the National Association of Realtors, opposing any restrictions on spam. The rest of them (along with a few samples from the realtors' letters) are posted here on the FTC web site. Random sampling of these letters show many of them to be from people who feel that restrictions on their ability to bother people via email would interfere with their business. Second, according to a study by Pew Internet and American Life (as reported by USA Today and other sources), 20% of Internet users report having purchased products as a result of spam. In this as well as other environments, individuals will pursue personal objectives that are contrary to the health of the whole system. (Here again we observe that solving the spam problem by asking everyone to stop responding to spam or sending spam or opening virus-infected email is somewhat like solving traffic problems by asking everyone to drive better.) Speaking of the FTC: you may or may not have known that the FTC has long encouraged people to send samples of spam to an address at ftc.gov . We won't print that address here, because it's changed: there's now a new address in a new domain. If you're so inclined, send those spam copies to spam@uce.gov (UCE being an acronym for "Unsolicited Commercial Email"). Unfortunately there is no corresponding web page in uce.gov (although we're told one is coming), but for now you can use www.ftc.gov/spam, and you can read the announcement of the new reporting address on the FTC site here.
We have noticed an increase in malformed email messages coming into our system. These messages seem to have a common problem, in that the internal header on the message terminates early with an unexpected string of characters. While this doesn't cause a problem with the servers, it does cause a problem with some email clients, and so far seems to be mainly on systems running XP Home. What's this "internal message header" that is causing problems? Email can be compared to a letter received in the postal mail. There is envelope information, outside of the message, that is used by the email transport software to deliver the message to its destination. There's also header information, inside of the email message, that contains summary information about the message. Similarly a letter going to your house has the destination address on the envelope but may have a different address or name "Dear Sirs", for example, on the letter itself. It is this internal header that is corrupt as far as email clients are concerned. Unfortunately the servers that transport the email from system to system do not look at the contents of the message, so do not see it as being corrupt. On your computer, the email client is simply a program (such as Outlook, Outlook Express, Eudora and others) that uses common services on the computer to attach to the mail storage computer and retrieve your email. While we don't like to point fingers, it appears that the common services portion of some editions of XP Home believe that the character sequence in the headers is our server closing the connection. This can cause problems with any program trying to get email. Outlook Express may show an error that the server disconnected and indicate an SSL error; Outlook may simply crash. You can work around this by logging into Webmail (http://webmail.mv.net), opening your INBOX, and clicking on the "Size" link in the table header, which will sort the messages according to size. The corrupted messages are usually under 1200 bytes and may be shown without a sender or subject. You can then use the webmail interface to delete the messages and prevent them from causing problems in your email client. There may also be softare updates for the email program you are using. We know of at least one for Outlook Express; you can find the information at http://www.microsoft.com/technet/security/bulletin/MS04-018.mspx.
We've been running UNIX shell servers for a very long time now, and every time we upgrade and migrate from one to another, it's been fairly easy: we simply move to newer hardware with a new revision of a familiar operating system. One side-effect of this ease is that we tend to carry along every little piece of software we've ever installed. Not so this time: we're trying not to bring over a lot of the programs that are out of date and probably not being used anyway. During this trial period we had hoped to get some feedback about the things that are missing. The good news is that there have been few complaints. The bad is that there haven't been a lot of you trying the new server. At any rate, it's time to get on with it. Over the weekend of August 21/22, we'll be making the new system, osmium.mv.net, the new shell server. When you log in on Monday, August 23, you'll be on the new system. Please do take some time between now and then to check it out and to tell us what you'd like to see there. The information in this notice still applies (with the possible exception of some optimistic dates.)
Each shell server had a name. Names were "jade," "granite," and "gold" -- both in the .mv.com and .mv.net domains. As the years have gone by, we've kept these names active, and they can still be used as aliases for your shell username's email address. However, it seems to us that the only use for these names now are as spam targets. Many shell users are already filtering out mail with these domain names in them; we'd like to take the final step and make those names stop working for email. Official shell email addresses should use the domain/suffix "@mv.com" or "@mv.mv.com" or "@shell.mv.net". If there are any objections to getting rid of the old aliases, please let us know by September 1 and we'll get rid of the mappings selectively. Otherwise, if there are no objections, we'll just drop them altogether.
|