Fri Aug 15 19:00:51 PDT 1997 — The web server had some problems with it’s internal socket communications, and was unable to serve cgi’s for a brief time. All’s well now. -Dane

Fri Aug 15 06:24:37 PDT 1997 — AOL still hasn’t fixed their mail problem. We’ve isolated the problem to high-volume mailing lists, specifically: ‘sammyhagar’, ‘rent,’ and ‘vanhalen’. Sendmail has a terrible problem with delivery to high-volume mailing lists. This is a flaw in its design. Fortunately, we have alternatives to effect mail delivery. The most popular solution is ‘qmail,’ and it is very fast. We are now running qmail on our outbound mail server, which handles mail destined for sites out on the Internet. Apparently, once we implented qmail, the extreme volume and efficency of these mailing lists triggered AOL’s spam filters. This wasn’t obvious at first. To prevent mail bounces, we held all mail to AOL. Now that we know what their problem is, we are delivering all mail to AOL except the high-volume mailing lists mentioned above. Specifically, we’ve implemented a solution that defers mail _from_ these lists, _to_ AOL, while still performing normal delivery.

In other words, mail to AOL is now working, except for the high-volume lists. Please visit news:sonic.net for further discussion of the AOL problem. -Scott

Fri Aug 15 14:11:59 PDT 1997 — AOL has resolved the issue that prevented our lists from delivering mail to them, and mail is currently dequeueing to them like crazy. Our new delivery system has nearly all of the mail sent already, and the performance is impressive! -Eli

Thu Aug 14 14:24:55 PDT 1997 — Because of high mail volumes, AOL’s filters have decided that mail from us is probably spam, and they are bouncing a lot of mail traffic. AOL’s network operations has said that they expect to have this fixed within 24 hours, and until then we are holding all mail which is destined for AOL. We’ll keep you posted here in the MOTD. -Dane

Sun Aug 10 04:20:06 PDT 1997 — During our Sunday morning wee-hour maintenance period, we upgraded our Cisco 7010’s route processor. The Cisco 7010 serves as our gateway to the UUNet and MCI Internet backbones. Downtime was approximately 15 minutes. There’s a picture of the route processor at: www.sonic.net/expansion/fiber/page9.shtml (the route processor is the card in the topmost slot.)

Tue Aug 5 08:59:58 PDT 1997 — Access to Usenet news was unavailable between 6:00am and 6:30am this morning. In other news news, we’ve added three new news feeds in the past couple weeks, and this should give us faster article propagation to our server.

Mon Aug 4 16:46:36 PDT 1997 — We’ve added a site search tool to our web server. This allows you and the people who visit your page to search for data on our entire web site. We’ll be publishing information shortly on how you can incorporate the search tool in your own HTML and limit searches to your area of the server. We’ll be providing more tutorial information in the FAQ section shortly. See it in action at:

www.sonic.net/search/

Mon Jul 21 13:58:26 PDT 1997 — Our MCI T1 was offline for five hours this AM between about 8:40am and 1:40pm PST. As we’re a ‘non default’ ISP who is fully multihomed to multiple backbone providers, this didn’t affect our ability to communicate with the rest of the Internet. Our investment in Cisco equipment pays off at times like this. -Dane

Sat Jul 19 08:05:28 PDT 1997 — What a week. Randy Benn at clark.net participates in the North American Network Operators’ Group, where he relates the following web page containing links to several outage stories: www.clark.net/pub/rbenn/outages.html

A reasonably accurate summary of this week’s fun and games can be found at: www.usatoday.com/life/cyber/zd/zd3.htm

Fri Jul 18 17:02:52 PDT 1997 — A number of bad things are happening out there in Internet land. UUNet’s fiber carrier has had a large trunk cut in Wisconson, and this is affecting much of UUNet’s non Bay Area destinations. We’ve been noticing slow access and lots of packet loss. In addition, our network is currently under attack, apparently from another UUNet customer. We’ve blocked access from their network, and we’re working with UUNet security to isolate the source of the attack.