MV Communications Newsletter: July 2006

MV Communications Newsletter: July 2006

Click here for a frames version

 

In this issue:

Unfamiliar or bizarre terms that you run across might be in the newsletter glossary (-- if not, suggest that we add it.)

 

Newsletter Tardiness

Those holes in the newsletter grid at http://newsletter.mv.net/ are not imaginary-- sorry to say that we've missed many, many months. We do like to try to have a monthly update but sometimes there is enough other pressing work to be done that writing these notes falls through the cracks, and then through the floor below, and into the toilet. Missing a succession of newsletters gains quite a bit of inertia (if the lack of something can be said to have inertia).

Other than this, we really have no excuse. But let's make another one anyway:

One of the problems with the newsletters is with their supposedly monthly format. When writing them, we often produce pieces of text that are potentially interesting on their own, but don't provide enough material for a monthly emission. Sometimes this has meant that we skip a month; and sometimes this means that one or more of those pieces of text become outdated and can no longer be used. This brings to mind a couple of pieces of classic advice:

  1. Don't let the best become the enemy of the good. It is probably better to present what small snippets we have, rather than waiting too long for enough snippets to combine into a whole;

  2. Form follows function. The approach we take is one of form forcing function, which is backwards.

So we'd like to think about new ways of presenting "newsletter" items and holding discussions. There's no reason that these things have to be presented in a monthly collection, and every reason to have each presented on its own. Down the line, we'd like to move to a more free-form style of newsletter material, whether this be via a blog, a newsletter web site without a calendar, a forum, one or more usenet forums, or something else entirely. If you have thoughts, feel free to use the feedback link below, to post in the mv.forum.general usenet newsgroup, or to contact us via any other means.

A few of the items in this issue are for catching up: they present some things that we have done, or things that have happened in the world, since the last newsletter in July 2004. Most of this text was indeed written in the months that they happened, but as described above, simply didn't see the light of day. (Other text that may have been written is simply no longer relevant.)

Much of the new text in this newsletter relates to mail handling. That's because it's one of the things we've been working on a lot, and also because with all the old items, the newsletter is already running on a bit. And it will leave other topics for later.

 

Older news (marked with [old])

Sox [old]

First in the "really important old news" department: a very belated congratulations to the Boston Red Sox on a tremendous World Series victory! It was so stunning that we couldn't write a newsletter until well after they had lost again. (Yeah, that's it.)

How does this relate to your Internet experience? Here are some fun sites that might help resurrect that world championship glow. (For those of you who aren't Red Sox fans, well, you can look too.)

http://www.newseum.org/frontpages/redsox/
The wonderful newseum site, which exhibits information from news outlets around the world, including access to a zillion newspapers' front pages, gives you this snapshot of headlines the morning after the Red Sox win.

http://boston.redsox.mlb.com/
The official Red Sox site (and a good use of subdomains!).

http://www.bostonsportsmedia.com/
Bruce Allen's blog about what's being said in the Boston-local sports media. Look over his shoulder to see what's interesting to read today, or what you might have missed lately. (This is one among several.)

 

National Dial-up [old]

[November, 2004]

We're happy to tell you that we've added a new suite of dialup numbers that give you more choices, including numbers in most towns and cities across the US. These are considered "off-net" numbers, and here's why:

Our on-net dialup numbers are the ones that bring you into our equipment directly. This is the sort of dialup access that we've provided throughout our existence. When you dial one of these numbers, it connects you to a phone line coming into access servers at our Manchester, NH location. For most callers, this is the preferred access, as it gets you onto our network, uses our bandwidth, gets your call closer to our servers, and so forth. When you connect via the on-net numbers, our servers can tell that you are an MV user.

The off-net numbers are provided via wholesalers. When you dial one of these numbers, you reach the wholesaler network, where you use some of their resources. You still have access to all of our servers, although your connection to those servers will travel over the Internet to and from the wholesaler network(s).

The off-net numbers should be used mainly when the primary on-net numbers can't. There are a few adjustments that you need to make before calling the off-net numbers:

  • "realm" login. You need to configure your login information to add a "realm" so that the wholesaler can associate your identity with MV. This just means adding an at-sign and the "mv.com" domain (or "fcgnetworks.net" domain) name after your login name. So if you're an MV user currently logging in as "Psomebody" just change your login to be "Psomebody@mv.com" .

  • SUBMISSION for mail. In order to send email, you will need to configure your email program to use a submission protocol when accessing our mail servers. This is something that we've been moving towards for all users for some years now. So far it's been optional for on-net users, but it's required when you dial the off-net numbers (this is because our servers can't tell that an off-net user is an MV customer without it). This is another major topic in this newsletter edition, so we won't belabor it further here other than to suggest that you see the section about it, and to let you know that it's required for off-net dialup access.

These changes will work even when you call the on-net numbers too, so once you've made a few changes, you don't have to undo them. And because at least one of them (the email submission requirement) will be required for all users eventually, we'd encourage you to make the changes whether or not you plan to call the off-net numbers.

All of our access numbers, including the new off-net ones, can be found at our access numbers page.

 

New Usenet News Server [old]

[April, 2005]

In other new news, our long-promised new Usenet News server is now in place.

What's Usenet News? While there's more to it than this, basically it provides a way for people all over the world to join in conversations and discussions. These discussions are divided into tens of thousands of areas called "newsgroups," each classified and named in a hierarchical fashion. A newsgroup name is effectively a list of its hierarchical classifications, more general to more specific, separated by periods. For example, a newsgroup named "rec.arts.comics" is specifically about "comics" within a more general category of "arts" that's within a still more general category of "rec" (recreation). Individual hierarchies are usually referred to with a "*" standing in for the most specific part, so the "rec" hierarchy is referred to as "rec.*" . (If you need to speak the name, you pronounce the periods as "dot," so "rec.arts.comics" is "rec dot arts dot comics", and "rec.*" is "rec dot star"). Note that you don't just type in random names (although that sometimes works since there are so many groups); newsgroups are explicitly created according to the rules of the hierarchy they belong in. These newsgroups are carried on thousands of servers around the world, with articles being sent from one system to another and duplicated from system to system (in the jargon, one system "feeds" another; most systems have a number of feeds in order to make sure articles aren't missed.) You may access a newsgroup on a particular server, while another person accesses the same newsgroup on a different server. The result is many many megabytes of discussions flowing into and out of each server per day.

MV has been providing Usenet news since we started, and the people behind MV have been running Usenet servers since about 1981. Although it's best to use a "newsreader" program, many web browsers have news browsing capabilities. A full introduction to usenet news would be way beyond the scope of this newsletter; fortunately you can find lots of information about it by using a web search engine and searching for things such as "Usenet News."

And this leads us to the actual newsletter item: the new server. The new news server has considerably more disk space than its previous incarnation, and is using more efficient storage mechanisms with better administrative control. As before, we've set up the server to focus primarily on non-binaries newsgroups, as we don't believe that Usenet is appropriate for most of the kinds of binary data that it's often used for. (However, we do continue to receive a subset of the binaries groups available and are willing to add legitimate ones if there is demand.) We've also added some very high-class feeds.

The new news server can be accessed via a newsreader, as before, at the name "news.mv.net". MV also offers a way to browse newsgroup hierarchies: go to the MV Newsgroup Finder to wander through the hierarchies of groups that we carry (thanks, again, to DJ Delorie). Entries are either hierarchy names (bold, and ending in ".*") or a newsgroup name. Click on a hierarchy name to show its members; click on a newsgroup name to browse that group, as long as you've got your browser configured for NNTP access.

 

Power Outages [old]

[March, 2005]

Since the last newsletter, downtown Manchester (where our data center is located) was hit by two substantial power outages. The first began at about 7:30pm on December 23 (2004), and lasted about 6 hours. The second hit at around 2:25 AM on March 15, and lasted for 8 hours. In both cases we patched some telephone handsets around our phone system and MV personnel took calls (often in the dark, or by candle light) while waiting for power to be restored.

These were rare events -- in fact were the only two outages that we've seen since we moved our office to this location back in the spring of 1997. We take precautions for power events that lie within the realm of reasonable day-to-day (indeed year-to-year) expectations, and have plenty of battery backup to keep us going through brownouts, power glitches, and surges which do happen from time to time.

 

End of older news

 

FCG Networks support

IMPORTANT: Please be aware that the FCG-related domain names including fcgnetworks.net, cyberportal.net, and coopresources.net are not owned by MV, and will be going away as of September 1. This is covered in more detail in a later section.

Just about two years ago, we began providing technical and support services for dialup customers of FCG Networks, another one of the original NH ISPs. FCG Networks had decided to go in a different direction, and as of September 2004 we entered into an agreement to gradually take over all responsibility for those dialup customers, as well as some DSL and some others. You may have used domain names such as fcgnetworks.net, cyberportal.net, coopresources.net, and perhaps others, but for ease of discussion we'll just use the term "FCG" as a succinct shorthand.

(Astute readers will probably notice that two years ago is also the time that we fell down on the task of producing newsletters.)

If you're one of these customers, you've undoubtedly heard from us (perhaps too often!). But indeed, during this time we've attempted to minimize the disruption to FCG users as best we could: we've continued to support the email addresses, dialup logins, personal web pages, and related things in the same way that FCG Networks did. When we've had to contact you to make changes, it's been for things that couldn't be helped (such as new phone numbers to dial, and different billing procedures).

We have tried to make the transition for FCG users as painless as possible. But having two separate support and technology models for customers is not always completely ideal (for us and for you). Sometimes when there are two very different ways of doing similar things, we need to choose just one approach for everyone, which may involve enhancing either one or the other.

One of the most significant of these choices relates to the handling of incoming email. FCG Networks used, for some of its mail customers, an external mail handling service. This service offered certain filtering and other options that are similar to those that we have developed here at MV. We strongly prefer not to use an external service for something as important and fundamental to our operations as email, and so we are in the final throes of weaning all users away from external mail handling, to use instead a common approach for all customers. Access to filtering choices is through a webmail interface that we have developed, and so a related change will be in replacing the old webmail interface that FCG users have used with the MV one. Note: we're still working on adding this to the webmail for FCG users: expect to see it in late August.

Apart from these filtering-related changes, we will continue to support FCG-style services for the reasonably foreseeable future. On the other hand, over the years we've developed our own mail services that are in some ways different from FCG-style email services. (If you are curious, we've recapped a bit about how our email works a bit later in this newsletter, both as a review for MV customers and and an introduction to FCG customers, and we've specifically marked the areas in which MV-side email is different from FCG-style.)

It's natural to expect that some significant advances that we make to email services will be done on the MV side. Customers who are using FCG-style services are welcome to convert to MV-side addresses at any time in the future. But there is no rush to do so.

The next couple of sections describe some of the work we have done on email handling, and some comments about how this will affect all of our email customers.

 

Sending Mail: Ports 25 and 587

In our last newsletter (stretch your memories, now..) we talked at length about things related to how you should be configuring your mail clients to send mail. We also talked about how we would finally start blocking access to IP port 25 (don't worry if this is confusing, but read on) after having promised to do so for several years. Because it's been so long without another mention of it, and because we'd like FCG users to read about this too, we're going to bring it up again here. Here will be a fairly short summary, and then we'll give a link back to the previous (much longer) discussion.

For most people, when you configure your mail program, one of the things you tell it is what mail server to use. Your mail program then sends your outgoing mail to that mail server. It does this by accessing a specific TCP/IP port number on the mail server: that number is how the mail server knows what sort of service you are asking it to perform. Up until about 1998, the only standard number to use was port 25: this is the port that mail servers use to send each other mail. Users' mail clients typically aren't mail servers, but there was no other port to use, so they too used port 25. Since that time, though, the handling of email has been changing to distinguish the cases of mail servers talking to each other from mail users submitting mail into the mail system. Another port, number 587, is now commonly used for the latter purpose. There are three significant things to know about this:

  1. For Internet users who receive a dynamic IP address (this is most everyone: if it's not you, you will know it since you will have specifically asked for a static IP address), most ISPs now prevent those users from accessing port 25 on anything other than the ISPs' local mail servers (and sometimes on all servers). The main push for this has been caused by spam and other abuse. Many computers become infected with a virus or a trojan that will cause the computer to try to access mail servers all around the net, using port 25. This is a primary vector for unwanted mail that flies around the Internet, and by blocking access to port 25, ISPs can help prevent this. Viruses and other malware may adapt (and in some cases already have) to make use of the designated mail server that you configure into your program, but at least the ISP can have a handle on the origin of any bad mail that gets through this way. We have been doing this blocking for MV-side customers with dynamic IP addresses, and we will be making sure that we apply the blocking to FCG users as well.

  2. Even with blocking of port 25 in general, you may still be able to access port 25 of the outgoing mail server of the ISP that you are using. We do allow you to access port 25 on our mail servers, provided that your IP address is one of ours (i.e. that you are getting access via our network). As this may change, we encourage you to move to using port 587 if you are not already doing so.

  3. Port 587 is now the standard port to use for submitting email into the mail system from an end-user mail program. Port 587 is specifically reserved for users who are authorized to use the mail server that offers it. Think of it this way: port 25 is for strangers, and port 587 is for people we know. Strangers are subject to certain restrictions (such as not being able to relay mail through a mail server, or being denied access due to blocklists or other reasons); those whom we know have authorization to do specific things. The implication is that when you use port 587, the mail server must be able to tell who you are (or at least that you are somebody recognizable). Accomodate this by configuring a username and password into your mail program. The username and password may be the same as your dialup access, or it may be those of one of your mailboxes.

Anyone using the off-net dialup numbers should already be familiar with most of these things, as the wholesaler providing those numbers also does blocking of port 25.

Our previous discourse on this subject may be found in this section of the July 2004 newsletter.

 

FCG domain name changes

Per a previous section, we have been providing support and services for FCG customers without you having to change much about the way you use the Internet. You've been able to continue to use the FCG domain name including fcgnetworks.net, cyberportal.net, and coopresources.net as before. However, we do not own those domain names, and while we expected to be able to continue to use them longer, we've recently been told to expect them to be withdrawn as of September 1, 2006.

To prepare for this, we've registered and set up a few new domain names that you can choose from. These domain names can be used in the same way (or similar ways) as the old ones, but the use of any of them does require that you make some changes. Please go to our FCG resources page at http://home.mv.net/fcg/ to learn more about these substitute domain names. When you switch to one of these new domain names, you will continue to use the same mail server and similar services as before.

Alternatively, you can choose to set up an account on the MV side of things. You can chose to do this now or later or not at all. If you defer the choice and switch to an MV-side address later, you will still be able to keep your address in one of these new domain names, as long as MV continues to own those names (we plan on keeping them, of course).

 

FCG incoming mail changes

As mentioned above we are wrapping up plans to move all customers to a common way of handling incoming mail. For FCG users, this means that you will be moving to MV's internal mail filtering (and other handling), away from an externally-provided gateway service. We believe this will provide a better solution over the long term. Certainly if you find things that are lacking, we would like to know about them so we can address them in the future.

The upsides: all mail that we handle will be done in a consistent manner, in ways that we can control and improve, and without being affected by issues we have no control over.

The downsides: we do not have a way to automatically get your old settings (which are, after all, maintained by somebody else) and apply them to your settings here. This means that if you have installed some custom mail handling settings with your FCG account, you should read or scan the following section(s) to learn a little about how to set up similar handling. If there's a silver lining to this, this will give you a chance to familiarize yourself with the interface that we provide.

 

MV incoming mail recap

Because it's been a while, and for the benefit of FCG users, we'd like to summarize a few of the elements of our handling of incoming email. This summary includes how we organize email accounts and the facilities we provide for filtering and accessing your incoming email, and how in some details MV-side email is different from FCG-style. (Outgoing mail has been summarized above.)

There are several components to incoming mail, as described here:

An email address
An email address, as you almost certainly know, is the handle that people use to send mail to a particular destination. It has a form like localpart@domainpart -- where localpart is usually some indicative name of some person or thing within the domainpart.

A mailbox
A mailbox is a place where email is delivered. A mailbox has a name, and it also has one or more folders where message may be stored, as well as filters, which provide delivery instructions.

  • Name: the name by which you access a mailbox. This is just a name: it can, theoretically, be most anything. The distinction between a mailbox name and an email address is sometimes confusing, so on the MV side we often make the mailbox name relate in some way to the primary email address that it's used for.

    On the FCG side, this is a mailbox name that you have set up; the name is whatever you have chosen.

    On the MV side, traditionally this name has been formed by taking your mv.com subdomain name, and appending a hyphen and the first two letters of the first address that the mailbox was created to handle. For example if your MV account's domain name is "mocv.mv.com" and you have created a mailbox to accept mail for "mem@mocv.mv.com", a likely mailbox name would be "mocv-me". Other forms of mailbox names might relate to a different domain name (e.g., "example.com-me" for a mailbox created to initially go with "mem@example.com"), or simply a numbered mailbox like "box000001" . The thing to remember is that the flow of email goes from email address into mailbox, and any email address (under our control) can be configured to go into any mailbox. A single mailbox can receive mail for many different email addresses: the name of the mailbox is unrelated to the email address itself.

  • Folders. Each mailbox can have one or more folders for storage of email. You are doubtless familiar with email folders that you can maintain on your own personal computer, but did you know that you can have folders on our mail servers as well? The primary folder is called the INBOX -- without other delivery instructions, all mail is delivered into the INBOX. If you access your mailbox via the POP3 protocol, you can only access the INBOX directly. However, if you use IMAP or MV's webmail interface or the FCG webmail interface (or potentially some other webmail front-end), you can access any of the other folders too.

  • Filters: rules and instructions. A filter can be associated with each mailbox. The filter contains a set of rules and instructions that tell the system how to process the mail that is delivered to that mailbox. Filter instructions can include things like what folder(s) to file the message into, some other email address to send the message to (instead of keeping it), or indeed whether to keep the message at all. One important part of filters is instructions for dealing with unwanted mail (like spam).

    We are still working on making our filtering system work for FCG accounts, but expect this to be completed within the next few weeks.

Access
When you have incoming messages stored in mailbox folders on our mail server, you need to access those messages. Most people will access via one of the ways described here.

  • Email program. You'll likely have a mail program such as Thunderbird, Outlook, Eudora, Pegasus, Mulberry (sadly defunct), or one of several other popular commercial or free products. Alternatively, many web browsers support access to email in the same ways as these standalone mail programs do. Standalone mail programs tend to do a better job at managing email, since that's what they are designed for, but for most purposes a browser-based program will do fine. You configure your email program with information about the mailbox (or mailboxes) that you want it to access, including the mailbox name, the password for that mailbox, and the server that that mailbox is on.

    Email clients (email programs) can access mail from a mailbox using one of two protocols: POP or IMAP. POP, which might also be referred to more specifically as POP3, is usually the default unless you specify IMAP. Using POP, you only have access to your INBOX folder. IMAP (also more specifically called IMAP4) gives you access to your other mailbox folders, and also gives you much better coordination between your mail program and the mailbox server.

  • Webmail. A webmail server is a web server that gets you access to your mailbox. Webmail typically uses the IMAP protocol to communicate with the mailbox server, and thus gives you access to all of your mailbox's folders. Webmail is very handy in situations where you don't have access to your email program, or where you simply want to be able to do quick operations on your mailbox. MV's webmail services is at http://webmail.mv.net and is also the place where you can manage your filters and other preferences. The name of the webmail server for FCG users will depend on which of the new domain names you have chosen, and is given to you when you choose the new name. Note again that the filtering options are still being added for the FCG side: expect them in a few weeks.

Control and configuration
The management of your mailbox. This includes such things as:

  • Mapping email address to mailboxes. This is something that MV staff must do at present, but on the MV-side we hope to give you some more control over this the future.

  • Filter management. Filter management is done through MV's webmail interface. Some of the changes to filter management are discussed in following sections.

 

MV incoming mail changes

Since the last newsletter we have done a lot of work in our continuing efforts to improve mail handling. There have been improvements in the mail system in general, in the facilities that we provide for filtering unwanted mail, and in the software that we use for all of this.

 

Philosophical change: filtering by default

One upcoming change relates to philosophy, and we'd like to start with that. Up until now our approach to filtering is to provide some elemental tools that you can apply to your email when it reaches your mailbox: we provide various functions, and we let you enable them. We have felt that you should actively enable any filtering that you want, and so by default nothing is done with your mail unless you do enable some filtering. You might say that this is an approach that only sits well with techies and geeks- but that is, after all, our heritage.

Times change, and by now the vast majority of people expect some amount of screening on their mailbox. And indeed, our servers apply a number of tests to incoming mail to reject clearly unwanted stuff before it even gets in the door. So there was already a bit of an inconsistency in our approach. As of this writing, only about 25% of mailbox owners have enabled any sort of filtering on their mail here, and we believe it's because they don't realize that they need to. Therefore, one major upcoming change will be to enable a basic level of mailbox filtering on all accounts. Those who aren't interested in this can still disable it. With the default filtering, if any message doesn't get a pass, it will be filed temporarily into a "Caught Spam" folder. This bears highlighting:

UPCOMING CHANGE: If you don't set up any mailbox filtering preferences, a basic level of filtering will be applied. Any mail that is discarded by this filtering will be temporarily stored in your "Caught Spam" folder.

 

Expiration of some folders

Relatedly, an issue we have found for some people who have enabled filtering on their mailboxes is that they have chosen to file spam and other unwanted email into "Caught Spam" and "Trash" folders, without ever checking those folders. The result is that those folders fill up over time, eventually bringing the mailbox over its quota, at which point new mail is rejected. We have long been threatening, er, promising to expire mail from these folders, and we will begin doing it in the near future. This, too, bears highlighting:

UPCOMING CHANGE: We will be expiring email from your "Caught Spam" and "Trash" folders.

When expired, these folders won't be completely removed: rather, the oldest messages will be removed to make room for the newer ones. The expiration parameters are still being worked out as of this writing.

 

The new "Spam Funnel"

We have introduced something that we call the "Spam Funnel." This applies a series of basic sanity checks to each incoming message. It is done in addition to (and prior to) the other filtering and filing options which are still available (via the MV webmail interface). And in fact the Spam Funnel takes no action by itself, it merely does some analysis on the message. This analysis is given as a sort of score, which may be tested by a rule within the filtering options.

You can control how aggressive the Spam Funnel is by selecting the Spam Funnel link in the webmail interface.

 

Improvements in filtering

Another major focus of our efforts has been on the tools and processes that operate to deliver mail. Without going into a huge amount of detail, as this newsletter is long and late enough already, here's a brief accounting of some of these things:

Incoming mail server
On the MV side, we have completely rewritten the mail component that accepts incoming mail (specifically, the SMTP server: the 'qmail-smtpd' piece of the "qmail" package that we use.) This rewrite makes it easier (and, for that matter, possible) to analyze incoming mail and sources of mail, and to expand on analysis and related operations in the future, including feedback and control over outgoing mail.

Mail Client Assessment Server
As a companion to the new SMTP module, we have also developed what we call a "Mail Client Assessment Server" . This is a server (a piece of software, i.e. a program) that takes input from other programs, and that other programs can consult to find information regarding the reputation of various agents that send mail to us and through us. In coordination with the SMTP server and other tools, this functions as an automatic feedback system that helps to remove a lot of the manual element in controlling the flood of unwanted email. We will talk a little more about this in future newsletter editions, but suffice it to say here that this has already had a great impact on our incoming spam volume, and we plan on turning on more advanced elements of it in the future. As with the filtering options, we'll be working to hook this into the FCG-side mail server over the coming weeks.

Mail Delivery Agent
MV's MDA (Mail Delivery Agent, the program responsible for handling your mail once it's been accepted by our server) was developed here for our needs and has been in use for the past several years. This is the program that ultimately handles your filtering and delivery instructions. Even though we've made considerable improvements since, most users have been using a version that was frozen as of October 2004 (!). There are a number of reasons for this, some of which are about compatibility with other tools and, particularly, some changes in operation for those who hand-create their own delivery scripts (all two or three of you). Rather than go into that here, we've posted a summary of the changes to the mv.forum.email newsgroup.

In the immediate future we will be retiring the older (2004) version, and the newest release of the MDA will be in use by all users. Those who have enabled or changed their filtering preferences since about May of this year are already using the latest MDA version. Also, we mentioned this above, but here it is again more exactly: in the past, if you did not select any filtering preferences, MV's MDA did not get used for your mail, and no specific filtering was done for you. In the near future, MV's MDA will be invoked for all mail, and some default filtering will take place unless you specifically disable it.

 

More to Come

There's more to say about email but we've likely overloaded you already. In future newsletters, we'll talk about some more of the nitty-gritty of email handling, including more focus on outgoing mail and rate limits and permissions, on virus detection and filtering, on enabling vacation or out-of-office email notices, on quotas and expirations, on email signing and signature validation, on techniques to foil bounce forgeries, and on other things that may not be in the crystal ball just this moment. And, believe it or not, topics that don't relate to email at all!

 

MV turns 15

In the "burying the lead" department:

MV Communications, Inc., was incorporated on June 21, 1991, and so we've recently passed our 15th anniversary. On that date in 1991, we were continuing to provide "domain park" services and email via UUCP, but were still not charging for services. It was a little while before we got our first live backbone connection turned up, and (although we think of September as our service, aka real, anniversary), we began billing in October of 1991.

 

Interesting Link(s)

This is our sometimes section where we mention one or more sites that we find interesting to one or more of us. Items here do not necessarily have anything to do with MV (and often do not), nor do they necessarily have anything to do with our business or anything else we do. (It should go without saying that we make no representation about anything contained on those web sites.)
www.woot.com Woot!
Woot isn't exactly new, but this newsletter isn't exactly timely. Each day, starting at about midnight, woot offers a single product for sale. When the inventory of that product is gone, the sale is done. (Popular woot days can end very early.) Products are typically overstocked new or refurbished items usually (but not always) related to technology or gadgets, and almost always with a very low shipping cost. There is also a weekly web contest (for fun) for woot users to participate in.

A companion site, wine.woot.com Woot Wine, offers a weekly wine selection in a similar way (though we doubt that the wines are ever refurbished). If you are in a state (such as New Hampshire) to which wines may be shipped, you may find this interesting.

Note Well: we have no affiliation with this site, and make no recommendation one way or another.

 

Your feedback?

Do you have feedback on this newsletter (or past or future newsletters)? If so, please either:
  • Go here to fill out our simple feedback form, or;

  • Send us email at mv-feedback (on our domain, mv.com).

 

Edit History

20060804: posted
20060805: fix link to access numbers