My ORBS faq (To be further revised.) $Id: orbs.faq.txt,v 1.60 2000/05/26 08:20:34 dhesi Exp $ (C) Copyright 2000 Rahul Dhesi, All RIghts Reserved. Copying is permitted if this document is kept intact and not modified, except for grammatical and typographical corrections. This faq is available at this URL: http://www.rahul.net/dhesi/orbs.faq.txt Each question is preceded by a [TEXT LABEL] to make it easy to refer people to that specific question. Comments may be sent via email to the author of this FAQ at this address: dhesi@email.rahul.net The above email address is heavily spam-filtered, including checking the sending host against RSS and ORBS. [WHAT] Q. What exactly is ORBS? A. ORBS is a number of things. It's a web site at this URL: http://www.orbs.org/ ORBS describes itself as a "small group of (grumpy) volunteers who are sick and tired of receiving junk email via open relays." It's a list of IP addresses and netblocks. You can look these up in the DNS zone relays.orbs.org . (A 'netblock' is just a way of referring to a set of IP addresses. See the TERMS section.) For more information and details please go to http://www.orbs.org/ . Q. If I can get information about ORBS at www.orbs.org, what's the point of this FAQ? A. The ORBS web site presents the opinions of ORBS. This FAQ presents the opinions of the author of this FAQ. That's the point. :-) There is a lot of misinformation out there on the net, and I decided that instead of trying to counter it in many places, I would put all my arguments in one place, here in this FAQ. [BLOCK] Q. I hear the ORBS blocks people's email. Is this so? A. Well, not exactly. ORBS (the list) contains IP addresses -- a lot of them. In some cases it contains netblocks, and each netblock implicitly includes many IP addresses. These IP addresses can be checked by doing a DNS lookup. A site on the Internet can do this check automatically when email is received from some remote host. If the IP address of the remote host is in the ORBS list, the site in question may choose to block mail from the host -- or it might choose to not block mail from that host. When a site chooses to block mail from a host that is listed in ORBS, ORBS has no idea that this blocking was done. The decision really lies with the site that does the blocking. But at the same time, ORBS gets to decide what's listed by ORBS. So you can think of it as a synergistic situation. But since nobody forces any site to use ORBS, ultimately the choice to block mail based on ORBS is a choice made by individual sites, not by ORBS. Q. Isn't it still the case that the email I send might not reach some site that uses ORBS, so isn't ORBS responsible in a way for my mail not getting through? A. I think of it this way. The set of all sites that use ORBS, and ORBS itself, may collectively be called "everybody involved in using or maintaining ORBS", or EIIUOMO for short. When you send email to any site that is part of EIIUOMO, and if you send that mail through an open relay, your email might be rejected. So if you want to exchange email with EIIUOMO, you will need to conform to EIIUOMO's requirements. If you are not able to conform to EIIUOMO's requirements, then you will have difficulty exchanging email with EIIUOMO. The point of the above was to say that EIIUOMO is responsible if you send mail to EIIUOMO and it is rejected by EIIUOMO. Q. Why would anybody want to block email from ORBS-listed hosts? A. Because by blocking email from ORBS-listed hosts, one ends up blocking almost all spam. One also ends up blocking some legitimate email. Those that truly hate spam and don't mind some of their legitimate incoming email sometimes being blocked can use ORBS to their advantage. Q. What about those that want to block almost all spam without blocking any legitimate email? A. They probably will not entirely get their wish. But by using a variety of different techniques, they might be able to come close. One effective way of blocking a large fraction of spam is by consulting another list called RSS. It works similarly to ORBS, but RSS has a better selection of IP addresses. Using RSS will rarely block legitimate email. But using RSS also allows more spam through than using ORBS. See the RSS web pages at: http://www.mail-abuse.org/rss/ . Q. If my service provider uses ORBS to block email, will any of my email be silently lost? A. Any mail blocked as a result of consulting ORBS will bounce back to the sender with an error message. (This assumes, of course, that the sender address on the message was valid, so the bounced message will reach the sender. It also assumes your service provider has properly configured his machines.) Q. Is there a safer way of using ORBS, so no legitimate mail ever bounces back? A. One method is to not bounce rejected mail, but tag it in some manner, or perhaps save it into a spam folder. You can then read that folder at low priority (e.g., once a day, or once a week). This way you can quickly scan through that folder, ignore the spam, and find any occasional message that was wrongly classified as spam. Discuss this with your service provider to see if he can do it for you. Q. So you are saying that it's possible to use ORBS and not risk losing mail, yet people still get upset with ORBS? A. Yes, indeed. Welcome to life in the big city. :-) Q. If a site chooses to block mail using ORBS, does it have to block all hosts listed in ORBS? Or can it pick and choose? A. The simplest alternative is to just block all hosts listed in ORBS. But this is not a requirement. Many other possibilities exist. For example, a site can have its own list of permitted netblocks, and then it can always allow incoming mail from those netblocks, regardless of what ORBS says. A site could also examine the actual value returned when a DNS look-up is done in relays.orbs.org, and depending on that value, choose to block or not block. (See the sections entitled STATIC and TYPES.) [SPAM] Q. I have heard that ORBS sends lots of spam. Is this so? A. That depends on what you mean by spam, I suppose. If by spam you mean unwelcome email that arrives in your mailbox with a forged reply address and tries to sell you things, then no, ORBS doesn't send spam. On the other hand in order to test machines to decide whether they should be in ORBS, the ORBS software probes machines by sending, or trying to send, email through those machines. Some of this test email, also called test probes, ends up in the postmaster's mailbox. Some postmasters object to this test email reaching them. From their perspective, it can be called spam -- they didn't ask for it and they didn't want it. So if you are looking for similarities between conventional spam and ORBS's test email, you will certainly find them. If you are looking for differences, you will find those too. ORBS's test email contains predictable reply addresses, so it's rather easy to recognize and block or discard. ORBS's test email is also addressed to ORBS's own destination email address, so it's not really directed towards anybody but ORBS itself. The ORBS test email is rather easy to stop, by simply having the administrator of a site send an email request to be put on ORBS's static list. For more information see STATIC. So to conclude, whether or not ORBS sends spam depends very much on your perspective. People will never agree on this issue. At this point some people reading this FAQ will go "No way man, it is spam." And others will say "No, it's not." And the previous ones will say "Is, too". And so it goes ad infinitum: "Is!" "Is not!". Which is what we were referring to when we said above that "people will never agree on this issue." (And at this point some readers of this FAQ are surely saying "Oh yes, they all agree it's spam." and others are saying "Nope, they don't". "Do!" "Don't!" ...) Q. Couldn't ORBS refrain from doing its probe until a machine was actually found to be relaying spam? A. Yes it could. In that case ORBS would become the same as RSS, and we already have RSS, so there is no need for ORBS to become RSS. It's good to have choices. Using RSS blocks spam, but using ORBS blocks more spam. (And contrariwise, using RSS risks blocking some legitimate email, but using ORBS risks blocking more legitimate email.) RSS imposes pressure on administrators of open relays AFTER they have been exploited by spammers. ORBS imposes pressure also on administrators of open relays BEFORE they have been exploited by spammers. [STATIC] Q. How does a site administrator arrange for ORBS to not send any test email to his site? A. The site administrator should send an email request to ORBS (getting the right email address from http://www.orbs.org/), identify himself and what netblock(s) he administers, and ask for these netblocks to be placed on ORBS's static list. Q. "Static list" -- what does that mean? A. ORBS includes two types of entries. (Well, actually there are more types, but two is all we need for this discussion.) First, there are the dynamic entries, which are entries corresponding to hosts that ORBS has tested and found to be insecure. (Insecure here means that ORBS was able to relay mail through these hosts.) Second, there are the static entries, which are entries added manually. Both types of entries collectively constitute the ORBS list. For more details see the section entitled TYPES. Q. So if a site administrator doesn't want ORBS to probe his machines, he can achieve this, but then his machines get listed in ORBS? A. Exactly. Q. That sounds unfair. If ORBS doesn't probe a machine, why should it list that machine? If it doesn't probe that machine, it doesn't know if that machine is an open relay. A. Yes, it does sound unfair. Turning the argument around, though, you can see that if ORBS doesn't probe a machine, ORBS doesn't know if the machine is closed to relaying. So the question really is: If ORBS cannot test a machine, should it assume the machine to be an open relay, or a closed one? Either assumption will be wrong some of the time. ORBS makes the first assumption. ORBS's philosophy can be summarized, in the words of the author of this FAQ, as: "Be probed or be listed." Q. Wouldn't it be better if ORBS were willing to not probe netblocks when so requested by the administrator, WITHOUT adding such netblocks to the static list? A. Consider what would happen: Every time a site administrator was notified by ORBS that he was running an open relay, he could simply and easily avoid doing anything about that by simply asking ORBS to cease probing his host(s). As a result, the incentive to close an open relay, due to the threat of being listed in ORBS, would vanish entirely. In the opinion of the author of this FAQ, netblock administrators should be given greater, not lesser, incentives to close open relays. Or consider what would happen if a service provider was getting too many help calls from his customers who were notified by ORBS that they were running open relays. Instead of expending resources to help them understand the situation and close their open relays, the service provider would find it much easier to send a "do not probe" request to ORBS. This would result in more and more netblocks having open relays that would not be discovered until AFTER they had already been exploited by spammers. But the spammers would simply then move on to the NEXT open relay that has not yet been closed. The current situation is that service providers hesitate to send "do not probe" requests because they would prefer to be not listed in ORBS. Q. I hear that ORBS "retaliates" against people who block its probes. That sounds pretty bad. Why does ORBS retaliate? And how? A. ORBS has a simple and consistent policy which I have described above as: "Be probed or be listed." "ORBS retaliates" is just a more romantic way of saying the same thing. Q. I hear that ORBS contains "false positives". What's that all about? A. Whether an ORBS entry is a false positive depends on how you define ORBS. If you define ORBS as containing only verified open relays, then any entry that's not a verified open relay would be considered a false positive. On the other hand, if you have read this FAQ so far, you know that ORBS contains two types of listings: Verified open relays, and netblocks that ORBS cannot probe. And if that is what ORBS is, and if we find no other problems, then there are no false positives in it, only entries that satisfy ORBS's listing criteria. A false positive would be an entry that does not satisfy the "be probed or be listed" principle, for example, an entry about which a legitimate complaint of type 1 or 2 is being made. See the section entitled COMPLAINTS for more discussion about this. Q. Are there absolutely no exceptions to "be probed or be listed"? A. I think there are one or two. I believe the MX host for the domain airmail.net is one such exception -- it's an open relay (or was when I last checked some time ago) but it's not in ORBS. There might be others but I do not know. This would be an interesting question for the reader of this FAQ to investigate. Anything you find, please let me know. Q. Some guy said he argued with the ORBS person and his host got listed as a result. Is that fair? A. Chances are ORBS was simply following its "be probed or be listed" policy. If in an argument the person said "don't you dare probe my machines!", that would typically result in ORBS (a) not probing those machines and (b) adding them to the static list. [TYPES] Q. Is there any way for sites to tell the difference between when a netblock is in ORBS's normal list of verified open relays, and when it's in ORBS's static list? A. There isn't an "official" method, but in practice the DNS value from a look-up can be used to distinguish between the two. So a site could choose to block mail from hosts that are on ORBS's normal list but not from hosts that are in the static list. This would, of course, allow more spam in, because hosts in netblocks on the static list are not being relay-checked by ORBS and the administrators of open relays are not being notified by ORBS. Based on information received from ORBS, the various types of entries are described below. zone: relays.orbs.org updated: frequently 127.0.0.2 - open relay picked up by automated system 127.0.0.3 - individual manual entry 127.0.0.4 - netblock entry zone: testing.orbs.org updated: hourly 127.126.0.2 - new submission being tested 127.126.0.3 - old open relay being retested zone: ok.orbs.org updated: daily 127.127.0.2 - ORBS-tested host which appears OK. (Note: if ORBS tests have been blocked from a host, it will appear OK even if it's an open relay. Hosts that don't do SMTP, such as routers, will appear OK too.) Anything in testing.orbs.org is almost always OK, as hosts usually fail checks very quickly. [COMPLAINTS} Q. I have heard complaints from some people that they wanted ORBS to stop probing their machines but ORBS didn't stop. A. Let's classify the possible types of complaints: 1. Person asks to be added to the static list, doesn't get added. 2. Person asks to be added to the static list, gets added, but probes continue. 3. Person asks ORBS to stop probing his netblock(s) but not add them to the static list. ORBS has no provision for doing so. Person complains that ORBS won't listen to him. Person is right. :-) 4. Person sends complaint to some mailing list or posts one on Usenet. ORBS doesn't read that mailing list or newsgroup. Person follows up with more complaints about how ORBS didn't pay attention to his complaint. Complaints of types 1 and 2 would indicate a real ORBS problem. The author of this FAQ believes that the majority of complaints seen in mailing lists and on Usenet are of types 3 and 4. Only a handful of instances of complaints of types 1 and 2 have been observed by the author of this FAQ, and most of them did not seem to be credible. If you, the reader, have experienced any complaint of types 1 or 2, please notify me. Q. Are you saying there are no legitimate complaints against ORBS? A. Oh, there probably are. But the trouble is that the majority that you see are exaggerations or colorful descriptions of the simple and consistent "be probed or be listed" policy. If you do come across any complaints where ORBS has *NOT* followed this policy, please do bring them to my attention. I am interested only in recent incidents, occurring during the last 6 months. ORBS policies, management, and location, have all changed over time. This FAQ addresses only the current situation, not any situation that might have existed in the less recent past. Q. Some guy I met said your FAQ is biased and not to be trusted. A. Give that man a cigar! This FAQ is indeed biased and not to be trusted. It represents the opinions of the author of this FAQ. ^^^^^ LOOK! LOOK! GREAT OUT-OF-CONTEXT QUOTE ABOVE ^^^^^ But remember, the truth is out there. A lot of it -- not necessarily all of it, but a lot of it -- is in this FAQ. You have to find it, though. But remember, there are lies out there too. And some of them might be here. Find them too. Ultimately, trust no-one but your own judgment. Better not trust that too much, either. It's all illusion anyway. Did you see "The Matrix"? You didn't really see it, you just thought you did. But seriously, if you are looking for a Source of Ultimate Objective Truth, this FAQ is not it. (Well not yet anyway. After a few more revisions, maybe....we'll see.) This FAQ tells you the truth as I see it -- it's my truth. Find your own truth. Until you do, you can borrow mine. Try it out. See if it fits. If it does, make it your own. One really nice thing about Truth is that you can give it away, and yet you still have it. If you see somebody without Truth, give him some of yours. It will brighten up the day for the poor sap. Or not. Whatever. [SMARTHOST] Q. I know of some instances when some ISP's customer was running an open relay, and the ISPs mail host(s) got listed in ORBS. This is wrong, isn't it? A. In most such cases, what is happening is that the customer's machine and the ISP's machine are together acting as an open relay. Neither alone might be an open relay, but taken together, they become one. This happens if the customer's machine will promiscuously accept incoming mail from anywhere, and send that mail on to the ISP's machine. The ISP's machine then delivers the mail to its final destination. This can be called a "multilevel relay", and in fact the multilevel relay could contain more than two machines too. ORBS and RSS have different policies in such cases. ORBS lists all open relays it finds, whether or not an open relay is a multilevel open relay. RSS does not list multilevel relays. Q. But it's not fair! Why should an ISP's hosts be ORBS-listed just because of one customer's fault? A. It does sound a bit unfair, but fortunately the ORBS procedure in such cases is to notify the owners of the machines involved in the multilevel relay, and to give the ISP time to act before the ISP's host gets ORBS-listed. If the ISP does not heed the warning, the ISP's host will then get ORBS-listed. Q. If RSS and ORBS treat multilevel relays differently, then both can't be right, can they? Either RSS is wrong and ORBS is right, or ORBS is wrong and RSS is right. A. It would make no sense for RSS and ORBS to have identical policies, since that would mean that both services are duplicating their efforts and wasting resources. That RSS and ORBS have different policies is a good thing -- it means that you, the reader, have a choice as to which service you will use when you process your incoming mail. You can use both, or neither, or pick one of the two. Thus right vs wrong is the wrong question. More choice vs less choice is a better question, and the answer is: More choice is good. [CHOICES] Q. Suppose a netblock administrator does not want ORBS probes. What are his choices? A. Three. 1. Do nothing, accept the probes. 2. Block ORBS probes at machine(s) or router(s). 3. Ask ORBS to add netblocks to the static list. Choice 1 is self-explanatory. Choice 2 is to block the ORBS probes at one's hosts or routers, such that they do not get through any more. The likely consequence is that ORBS will detect this blocking, and add the relevant netblock(s) to its static list. Choice 3 is to send a request to ORBS. In case of choice 3, too, ORBS will add the relevant netblock(s) to its static list. Q. Between choice 2 and 3, which is better? A. The final result of both will be that the relevant netblock(s) will get added to the ORBS static list. So from that perspective there is no difference. However, one advantage of choice 3 is that no effort needs to be expended to keep any blocks in place. If we are a big service provider reselling connectivity to many customers, choice 3 is always better for our customers. We send a request to ORBS to put all our netblocks on the static list, and also ask ORBS to honor contrary requests from those who administer smaller pieces of our network space. Those of our customers who want the ORBS probes can then ask ORBS to remove their slice of the network from the static list. This gives our customers a choice. If we simply block all ORBS traffic, our customers have no choice. Q. Does anybody actually want the ORBS probes? Or are they just a nuisance? A. The ORBS probes are very thorough and will test a host for relaying using many address formats. Site administrators who manage many machines can take advantage of the ORBS probes to help them keep their SMTP servers secure against unauthorized relaying. The author of this FAQ relies on ORBS probes for this. [INTERNET] Q. All in all, is ORBS good for the Internet? A. ORBS has helped keep many machines more secure against relaying. It has also helped many people cut down incoming spam. On the other hand, ORBS also annoys many site administrators, which is bad. The volume of email generated by ORBS, due to the test probes, is probably much, much smaller than the amount of spam that ORBS helps to cut down. So the existence of ORBS results in a net decrease in total spam, even if you consider all ORBS probes to be spam. (See the section entitled SPAM for a discussion of whether ORBS probes are spam.) So the question boils down to: If ORBS can substantially cut down spam, at the cost of annoying many site administrators, is it good for the Internet, or bad for the Internet? You, the reader, must determine for yourself the answer that satisfies you. [TERMS] Q. What is an open relay, exactly? Doesn't every mail server relay mail? A. In this document, the term 'open relay' refers to a machine that accepts SMTP connections and relays mail between two machines neither of which is under the administrative control of the owner of the 'open relay' machine. This allows arbitrary persons to relay spam through the machine that is the open relay. A correctly configured machine (a 'closed relay') will relay email between two machines only if at least one of them is under the administrative control of whoever owns the closed relay machine. This allows an authorized user to send mail to a stranger, and it allows a stranger to send mail to an authorized user. But it prevents a stranger from using our machine to send mail to another stranger. Q. What's a netblock? Is it different from a network? A. A netblock is just a specified contiguous range of IP addresses. It might or might not correspond to a specific physical network. Saying 'netblock' is better than saying 'network' because that might refer to a physical network (such as somebody's LAN). Or it might refer to a traditional class A, B, or C network and that terminology is a bit inflexible and doesn't allow us to specify arbitrary ranges of IP addresses. We can have netblocks within netblocks, but we can't usually have networks within networks. [FEEDBACK] Q. I have some opinions. Would you add them to this document? A. Probably not. The author of this document pays for web space and bandwidth to publish his own opinions. He does not wish to pay for web space and bandwidth to publish yours. You are, of course, very welcome to pay for your own web space and bandwidth to publish your opinions. If you provide a URL, it might be added to this document to point viewers to your own web site. Q. I have some facts. Would you add them to this document? A. Very likely, if they are relevant and useful to the author of this document. == END ==