Greg Woods wrote:
[ On Friday, January 14, 2000 at 12:24:32 (-0800), J.D. Falk wrote: ]
Subject: Re: Fw: Administrivia: ORBS
Unfortunately, ORBS does not allow for people who DO know about relays, and DO close them, and don't want to be scanned anymore. In the ORBS world, that simply isn't an option.
That's where most of the sane anti-ORBS sentiment comes from.
If your mailers were abused, reported to ORBS and listed, fixed, and finally cleared from ORBS then please don't prevent ORBS from testing them again in the future -- that is your guarantee that we won't individually block your mailers again with our own private lists.
I think the issue most people aren't certain of, is when is it reasonable to test a machine, in the manner ORBS does? Let's consider various possibilities, in an order somewhat resembling decreasing reasonable-ness. [My comments on these are bracketed.] 1) If your mailer receives an incoming connection request on port 25, it's pretty reasonable to test the machine from which the request comes. The logic here is pretty solid - before accepting a connection from another mailer, it is reasonable to want to verify that it isn't an open relay being used for spam. For efficiency, perhaps such testing could be limited to incoming requests from machines listed on ORBS or similar sites. If an ORBS-like list, maintained based not on pre-emptive testing, but on at-receive-time non-open-relay verification, this would be pretty benign. The question for this list would be, how can you ensure that any submission from participants is authentic? - have this ORBS-like list *not* trust submissions, per se; - rather, have the machine(s) hosting the list, added as MX entries *for* participants (ie, participants add the MX) - participant machines, upon detecting mail connection requests from a machine, does the following: - check to see if it is listed - if yes, refuse connection - if no, check directly if it is an open relay -if so, refuse the connection Refused connections (listed, or detected open relay) result in the open relay trying MX hosts with larger MX values, until the ORBS-like machine is tried - the ORBS-like machine, would then do its identical check, only because the sending machine was trying to forward mail through it; thus it is no longer pre-emptive. - if already on list, either refuse connection, or test again - if sending machine is determined to be an open relay, add to list [IMHO, this would be both non-pre-emptive, scalable (although with a small ramp-up problem), yet centralized enough to be useful to large and small sites alike. The central machine(s) would clearly need to re-do their testing periodically (not necessarily every time someone from a listed site tries to send mail!), and would need to be capable of handling a huge number of connection requests. I defer to the MTA-gurus as to whether this is do-able in practical terms.] [If anyone is considering implementing this - *please* be sure to put in place checks to avoid mutual- checking run-away recursion!.] 2) Hosts listed in any domain as an MX host. Unfortunately, in neither DNS nor in the IANA assigned ports, is there any distinction between an MDA and an MTA. An MX is a proxy-MDA, which by necessity is an MTA. There is no corresponding "Relay" record for DNS, which *would* be something always valid to test. In the absense of the distinction, the MX meaning could be overloaded (to use the c++ term) to include relay; the question would then become one of whether it is reasonable to test hosts that actively advertise the fact that they are relays. (What would have been really sweet, is if there were separate ports for local deliver (MDA) and transport (MTA). Then, machines with MDA, but no MTA, would never forward mail; they could locally initiate mail, and receive mail for delivery, without being any kind of relay (open or closed). This would reduce the set of hosts needing to be tested, to those with MTA ports accepting connections. It would also mean the default config for any such machine would normally be MDA and no MTA; only MX and Relay machines would have MTA turned on.) [IMHO, there's no clear line on pre-emptive testing; clearly, major mail hubs (closed relays, MX machines, large mailservers with lots of users) have to worry about (a) spam, and (b) scaling issues, and any kind of pre-emptive spam-avoidance is (1) welcome, and (2) maybe necessary.] [If the pre-emptive testing resulted in lists of known-good (machines *known* to be *not-open* for relay), then this would be, in effect, an opt-in/opt-out mechanism; then sites who don't wish to allow testing by a testing-agent, would still need to be verified when mail is received from them; this verification could be cached by mailhubs (and kept for some well-defined interval, such as the refresh period from the SOA for the zone for the sending machine.) Testing of such opt-out sites would then be done only by parties receiving mail from them, not by anyone else. I think that would keep most folks happy.] 3) Hosts listed with A records for any "main" zone, eg "foo.com". If there is no MX record, but there is an A record, which would be used for mail to that zone, it is reasonable to presume that spammers will attempt to use the machine. (Or is it? I'm playing devils advocate, here.) [IMHO, this is reasonable iff (2) is reasonable.] 4) Hosts whose names can be found by zone-tranfer from a "main" zone. If administators for a zone operate a nameserver which does not do ACL-based restrictions on zone-transfers, is it reasonable to presume that any server listening to port 25 is more likely to be an open relay? [IMHO, regardless of SMTP testing, anyone doing this check should notify admins where this is permitted, that they might want to not permit this.] 5) Hosts listening to port 25. [IMHO, Occams razor would have drawn blood already.] -- Brian Dickson, Email: briand@teleglobe.net Director, Backbone Engineering Tel : +1 703 755 2056 Teleglobe Communications Corp., Fax : +1 703 755 2648 Rm 3214, 11480 Commerce Park Drive, Cell : +1 703 851 9053 Reston, Virginia, USA, 20191 http://www.teleglobe.com