Although, in theory, internet standards ought to permit grex to receive mail from any site, in practice, there are sometimes reasons why we find it necessary to disable mail from a particular site. The following is a list of sites we've disabled; follow the link to learn more details. (Follow this link if you run one of these systems).

Some sites we don't like

In addition, we don't accept mail from sites that appear to be dial-up IP connections, especially when we find that they are generating mass mail. There are too many of these sites to list here, look at

/usr/adm/badsys

on grex to learn about them.

If you administer any of the above systems, and want to fix the problem, you must also send mail to us to have us re-enable mail service.

In the past, we had a lot of problems with sites that had the in RFC 1435 problem. Here's a list of sites that had this problem (a long time ago).

146.174.250.100 noping, worf.qntm.com (HP)
152.163.200.7   noping, no incoming smtp (=listmail.aol.com)
198.93.152.11   noping, adeskgate.autodesk.com (SMI-5.3)
200.13.16.8     noping, no incoming smtp (=NIC.DATA.NET.MX, no rev arpa)
204.144.158.25  noping, puck.solbourne.com MS IE Connector
204.70.138.39   noping, neptune.pcy.mci.net Sendmail 8.6.12
205.229.27.7    noping, no incoming smtp (no rev arpa, =uunet technologies, inc.)
206.215.36.2    noping, no incoming smtp (no rev arpa, =Southern California College)
207.1.151.75    noping, no incoming smtp (h-207-1-151-75.netscape.com)
An earlier version of the mail quota software on grex rejected mail with SMTP error 452, which told the remote mail software to try again later. (SMTP is described in RFC 821.) Some mail systems interpreted later to be a few seconds later, which would cause endless problems on grex. We added a bunch of systems to badsys to deal with this. We then noticed that people whose mailboxes filled up didn't seem to appreciate the fact we were holding mail off for them. So we have become much more hard-assed. If someone's mailbox fills up, we now generate an SMTP 552 error, which causes the remote mail software to give up right away. End of problem.

Here is a list of sites that had this problem:

These sites used to have a problem, but it appears to be resolved now. 
charis.berean.org       resolved Nov 1996; thanks to chris@oz.kis.net
kingcrab.informix.com   resolved Jan 1997; thanks to dgoebel@informix.com
blueshift.com   resolved 18 Mar 1997; thanks to John Ingram <john@blueshift.com>
netspace.org    resolved ?; thanks to bfisk@netspace.org

c2.net - Community ConneXion

We don't receive mail from this site, apparently because it was originating an endless stream of mail to a user on grex. This was done 31 March 1997.

moneyworld.com - Financial Connections, Inc

natureplus.com - NetAmerica USA

We don't receive mail from these sites, because they kept sending us spam to forward to the rest of the internet, even after being asked not to do this. Grex does not have the resources to act as any sort of mail relay station, let alone one for spam.

I don't belive that email to Bob Williams works. Perhaps you can reach him at(206) 269-0846? Here's his address:

2508 5th Ave, #104
Seattle, WA 98121

cybermirror1.com - Cyber Promotions

We don't receive mail from this site, because something claiming to be an automatic mail response system sent mail to MAILER-DAEMON@cyberspace.org on 2 August 1997. This mail address does not correspond to a human, and would only be used on bounce messages generated by grex. It is a serious flaw for an automatic mail response system to reply to a bounce message that was most probably triggered by earlier mail sent by the automatic mail response system.

msn.com - Microsoft Network

Mail that is sent from Microsoft Network, appears (to us) to orginate from a series of machine named upsmot01.msn.com, upsmot02.msn.com, upsmot03.msn.com, etc. Although these machines all implement RFC 1191 path MTU discovery, they live behind a firewall that does not pass any ICMP traffic through. Because of this, TCP connections from these machines do not manage to pass complete e-Mail messages to grex, and instead hang around consuming network bandwith and computing resources on grex until they timeout. This problem is explicitly described in RFC 1435, and in that RFC, the authors recommend that such firewalls should be modified to pass ICMP message Type 3 Code 4 messages.

We contacted Microsoft on 17 April 1996, but were unsuccessful in correcting the problem. To contact the people in charge of the outbound SMTP gateways at Microsoft Network, send mail to David Whipple <dwhipple@microsoft.com> and postmaster@msn.com, or write to


David Whipple
One Microsoft Way
Redmond, WA 98052-6399
USA

mx1.expedia.com - Microsoft Corp.

Mail that is sent from Microsoft expedia travel services, appears (to us) to orginate from a series of machine named mx1.expedia.com, etc. Although these machines all implement RFC 1191 path MTU discovery, they live behind a firewall that does not pass any ICMP traffic through. Because of this, TCP connections from these machines do not manage to pass complete e-Mail messages to grex, and instead hang around consuming network bandwith and computing resources on grex until they timeout. This problem is explicitly described in RFC 1435, and in that RFC, the authors recommend that such firewalls should be modified to pass ICMP message Type 3 Code 4 messages.

We contacted Microsoft on 21 March 1997, but were unsuccessful in correcting the problem. To contact the people in charge of the outbound SMTP gateways at Microsoft Network, send mail to David Whipple <dwhipple@microsoft.com> and postmaster@msn.com, or write to


David Whipple
One Microsoft Way
Redmond, WA 98052-6399
USA

lyndar.blr.novell.com - Novell, Inc.

The machine at IP address 137.97.54.190 appears to implement RFC 1191 path MTU discovery, but lives behind a firewall that does not pass any ICMP traffic through. Because of this, TCP connections from this machine do not manage to pass complete e-Mail messages to grex, and instead hang around consuming network bandwith and computing resources on grex until they timeout. This problem is explicitly described in RFC 1435, and in that RFC, the authors recommend that such firewalls should be modified to pass ICMP message Type 3 Code 4 messages.

This host, 137.65.2.254, also does not have a valid DNS in-addr.arpa PTR record. This would not affect mail delivery, but is a curious omission.

We sent a message on 19 March 1997 to postmaster@blr.novell.com but were unsuccessful in getting any response. We also tried contacting Sean Gilkes <sgilkes@novell.com>, Peter Dennis Bartok <Peter_Dennis_Bartok@Novell.DE>, and Mark Richardson <mark_richardson@NOVELL.COM> but these turned out to be invalid addresses. Perhaps it would be worth sending paper mail to:


Novell GmbH
Monschauer Str. 12
D-40549 Duesseldorf
Germany

dns.cna.com - CNA Insurance

The machine dns.cna.com (159.10.4.25) appears to implement RFC 1191 path MTU discovery, but lives behind a firewall that does not pass any ICMP traffic through. Because of this, TCP connections from this machine do not manage to pass complete e-Mail messages to grex, and instead hang around consuming network bandwith and computing resources on grex until they timeout. This problem is explicitly described in RFC 1435, and in that RFC, the authors recommend that such firewalls should be modified to pass ICMP message Type 3 Code 4 messages.

We sent a message on 25 March 1997 to postmaster@sch1p116.cna.com, and root@sch1p116.cna.com, but were unsuccessful in getting any response (as of 27 March 1997). We also tried contacting David Hillman <david.hillman@cna.com> with no more luck. In fact, David Hillman <david.hillman@cna.com> turned out to be an invalid mail address. Perhaps it would be worth sending paper mail to:


CNA Plaza
Chicago, IL 60685
USA

gateway.kellogg.com - Kellogg Company

The machine gateway.kellogg.com (198.108.149.2) appears to implement RFC 1191 path MTU discovery, but lives behind a firewall that does not pass any ICMP traffic through. Because of this, TCP connections from this machine do not manage to pass complete e-Mail messages to grex, and instead hang around consuming network bandwith and computing resources on grex until they timeout. This problem is explicitly described in RFC 1435, and in that RFC, the authors recommend that such firewalls should be modified to pass ICMP message Type 3 Code 4 messages.

We sent a message on 25 March 1997 to postmaster@gateway.kellogg.com but were unsuccessful in getting any response (as of 27 March 1997). We also tried contacting Dave Gibson <dave.gibson@kellogg.com>, and Vinh Tran <vinh-chi.tran@kellogg.com>, with no more luck. In fact, Dave Gibson <dave.gibson@kellogg.com>, and Vinh Tran <vinh-chi.tran@kellogg.com>, turned out to be invalid mail addresses. Perhaps it would be worth sending paper mail to:


Kellogg Company
235 Porter Street
Battle Creek, MI 49017
USA

didier.ee.gatech.edu - Georgia Institute of Technology

The machine didier.ee.gatech.edu appears to implement RFC 1191 path MTU discovery, but lives behind a firewall that does not pass any ICMP traffic through. Because of this, TCP connections from this machine do not manage to pass complete e-Mail messages to grex, and instead hang around consuming network bandwith and computing resources on grex until they timeout. This problem is explicitly described in RFC 1435, and in that RFC, the authors recommend that such firewalls should be modified to pass ICMP message Type 3 Code 4 messages.

We sent a message to postmaster@ee.gatech.edu on 21 March 1997, but were unsuccessful in getting any response. It may also be possible to contact the appropriate: people by writing:


Office of Computing Services
258 Fourth Street, Rich Building
Atlanta, GA 30332
USA

ivision.coloc.web.xara.net

This host retries right away when our mail returns a 400 class error. This is wrong, and wastes CPU and network bandwidth on our end. The retry rate should be more like once every 30 minutes, with some sort of exponential backoff algorithm. We haven't contacted xara.net yet, as of 14-Dec-1997.

ns3.ge.com - General Electric Company.

This host is generating a truely excessive number of bounces. A lot of mail seems to be going to sachinvt@cyberspace.org. This mail is apparently being sent from <Sachin.Thakur@gepex.ge.com>. This has been going on for 7 days, since 4-Oct-1999, and is taking up a lot of our network bandwidth. C'mon, guys, do you *really* need to do this?

jobserve.com - Jobserve Ltd.

We don't accept mail from nobody@deliver-5.tiptree.jobserve.com because, if it cannot be delivered on grex, the bounce message can't be returned to the originating agent.

jobs.usweb.com - USWeb Corporation

We don't accept mail from this system, because the mailer at this site appears to be broken, and was bombarding us with tons of mail for a non-existant address on 17 May 1997.

hotmail.com - Hotmail Free Email

Mail that is sent from Hotmail, appears (to us) to orginate from a series of machine named F5.hotmail.com, F19.hotmail.com, F25.hotmail.com, etc.

Although these machines all implement RFC 1191 path MTU discovery, they live behind a firewall that does not pass any ICMP traffic through. Because of this, TCP connections from these machines do not manage to pass complete e-Mail messages to grex, and instead hang around consuming network bandwith and computing resources on grex until they timeout. This problem is explicitly described in RFC 1435, and in that RFC, the authors recommend that such firewalls should be modified to pass ICMP message Type 3 Code 4 messages.

We have informed Hotmail (postmaster@hotmail.com) on 13 March 1997.

Some additional contact points, if you would like to contact them, are Joshua Goldsmith <joshin@HOTMAIL.COM>, at phone number (408) 222-7005 ext. 154., and Jack Smith <jsmith@HOTMAIL.COM>, at phone number (408) 222-7000.

Javasoft
1290 Oakmead Parkway
Suite 218
Sunnyvale, CA 94086
USA

kmglmail.wipsys.wipsys.soft.net.

We don't accept mail from mailer-daemon@wipsys.soft.net if sent from this address, because if it cannot be delivered on grex, it can't be returned to wipsys.

po*.wam.umd.edu - *@mobius.loop

We don't accept mail from owner-rage-l@mobius.loop (or any other mobius.loop address) because if it cannot be delivered on grex, it can't be returned to knot.org.

mail.datasys.net - DSS Online

There appears to be a problem, perhaps temporary in nature, that had resulted in multiple copies of a message with message-ID 199609230951.FAA00296@mail.datasys.net being sent to grex. This is very bad, and had filled up one person's mailbox.

We have informed postmaster@mail.datasys.net on Wednesday, 25 September 1996 00:30 -400, but never received any reply.

Some additional contact points, if you would like to contact them, are administrator@MAIL.DATASYS.NET, at phone number (912) 241-0607.

2300 Madison Highway
Valdosta, GA 31603
USA

bbmail1.unisys.com - Unisys Corporation

There is a mail loop between sureshv@tulblr.unisys.com and sureshv@nether.net. Mail from sureshv@tulblr.unisys.com is forwarded to grex as well as nether.net. The result is that about 5-6 copies of every message sent to sureshv@tulblr.unisys.com are shipped to grex, and the last one comes with too many RFC 822 "Received:" timestamps so is sent to postmaster@cyberspace.org instead. We, the people who read postmaster mail on grex, really don't want sureshv's private mail. We contacted both Informix and Nether.net on 12 October 1997, but never received any response (as of 16 January, 1997).

To contact the people in charge at unisys, you might try sending mail to Chris Liebsack, the technical and zone contact for unisys.com, or postmaster@unisys.com . It is also possible to send US postal mail to


Unisys Corporate Headquarters
Blue Bell, PA 19424-0001
U.S.A.

To contact the people in charge at nether.net, you might try sending mail to Jared Mauch, Jared Mauch also has a FAX telephone number, 313-998-6105. It is also possible to send US postal mail to


Nether Network
3015 Whisperwood Dr. #261
Ann Arbor, MI 48105
USA

Good luck. We received no response from these e-mail addresses.

seepz.tcs.co.in - ?

We don't accept mail from this system for user kanni@cyberspace.org (or any other user). because the mailer at this site was attempting to connect to us every few seconds to deliver mail, and his mailbox was full. Reversa arpa does not work for this host; we are not sure exactly what this host is for, or who uses it. Also, this host is sending mail that claims to be from the mailbox that filled up on grex; this seems like a really bad thing.

delhi.tcs.co.in - ?

We don't accept mail from this system because the mailer at this site was broken on 29 March 1998. The mail software on this system generated a mail address consisted entirely of non-ascii characters. When grex tried to send mail to this address, it got these errors: 
554 Infinite loop in ruleset 3, rule 12
554 Infinite loop in ruleset 3, rule 12

mail-gw.pacbell.net - Pacific Bell Internet Services

We don't accept mail from this system because the mailer at this site has a defective anti-spam rule. The intent of this rule appears to be to prevent this host from being used to relay mail. Unfortunately, this rule is implemented in the wrong place. Instead of rejecting mail before it is accepted, it is accepted, queued, rejected, and bounced. The bounce message is not delivered to the originating host, which may be long gone, but instead to the return path, which may be a completely different host, and point to the mailbox of a user who is completely not associated with the problem. Very bad.

2 Mar 1998 - added to badsys.

bali.infophil.com - InfoPhil, Inc.

We don't accept mail from this system because this system keeps sending mail to several addresses on grex despite our best efforts to remove those addresses from the supposed mailing list sent from here. The mail that is sent also appears to contain a large amount of commercial content, sugggesting that this is actually thinly disguised unsolicited commercial e-mail, or spam. We followed the directions given to unsubscribe rbk@cyberspace.org on 16 Feb 1999, with no luck.

6 Nov 1999 - added to badsys.

dmshouston.net - Networks On-Line

We don't accept mail from this system because the mailer at this site does not accept bounce messages from grex. According to RFC 821 in section 3.6 (page 14), when a mail rejection notice is generated, the return path is supposed to be <>. However, when this mail is returned to dmshouston.net, this mail is rejected with the message 
>>> MAIL From:<>
<<< 501 bogus mail from
554 <ThoughtADay-owner@ThoughtADay.com>... Remote protocol error
This is bad.

1 Oct 1998 - added to badsys.

qmail.erosmail.com - TropiX Talent

We don't accept mail from this system because the mailer at this site had been sending mail to an invalid address at grex for some time, and when we attempted to unsubscribe this address, their web server went insane. Apparently, it went into some sort of infinite redirect loop, and attempted to unsubscribe kelvin@cyberspace.org a whole *bunch* of times. Each attempt resulted in generating mail to kelvin. By the time we noticed, and turned off the temporary alias, over one megabyte of unsubscribe reports had been sent. Their mailer is still busy attempting to send more such reports.

Proper mailing list software notices when mail sent to invalid addresses is rejected with "no such user", and proper web software does not return redirect pages pointing to itself.

16 Feb 1999 - added to badsys.

alpha2.dlinc.com - D & L Online, Inc

We don't accept mail from this system because it sends mail as <nobody@dlinc.com>, and if a bounce notification is sent to this address, the mailer for the dlinc.com domain rejects this. According to RFC 821 in section 3.6 (page 14), when a mail rejection notice is generated, the return path is supposed to be <>. However, when this mail is returned to alpha1.dlinc.com (the MX host for the dlinc.com domain), this mail is rejected with the message 
>>> MAIL From:<>
<<< 550 <>... Sender address not in proper format
554 <nobody@dlinc.com>... Remote protocol error
This is bad. (Sending messages as nobody seems most dubious in the first place.)

15 Mar 1999 - added to badsys.

internet standards - some pointers

ICMP is an integral and necessary part of the TCP/IP protocol stack. It is used for MTU path discovery, various kinds of IP layer congestion control, TCP error returns, and network diagnostic software. Without ICMP, some or all of these will not work. Grex is unusual in that its internet connection tends to fragment packets, which can cause problems with non-compliant internet implementations or sites. Nevertheless, IP fragmentation is, in fact, part of the standard, and sites that can't handle IP fragmentation are not completely in compliance.

For more information on internet host requirements, check out RFC 1122 and RFC 1123, Requirements for Internet Hosts. For information on TCP, check out RFC 793 and RFC 964. For information on ICMP, check out RFC 792 and RFC 950. ICMP and TCP are layered on top of IP, which is described in RFC 791. For information on path MTU discovery, check out RFC 1191. SMTP (the mail transport protocol used by grex for incoming mail) is described in RFC 821 and RFC 822. RFC 1435 contains IESG advice on path MTU discovery. RFC 1858 talks about security considerations for IP fragment filtering. RFC 1470 contains a list of tools that can be used to debug TCP/IP networks.

The IETF standards process is described in RFC 1796 and RFC 1818. Some of the philosophy behind the internet can be found in RFC 722, RFC 871, RFC 875, RFC 1118, and RFC 1539. When grex refuses mail for hosts described in this http document, it is, in essence, implementing a greatly updated form of the administrative denial of service described in RFC 706.

There are many RFC's that deal with security issues. RFC 1244 contains a general site security handbook. RFC 1636 contains workshop notes on internet security.

For more general internet information, check out RFC 1206 - new internet user, and RFC 1207 - experienced internet user. RFC 1392 contains an internet glossary. Finally, RFC 1855 contains a netiquette guide.

This is merely a starter list of relevant RFC's; for a complete list of RFC's, check out the RFC index file.

Contact Information

www.cyberspace.org + postmaster@cyberspace.org