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
[ On Friday, January 14, 2000 at 21:46:40 (-0500), Brian Dickson wrote: ]
Subject: Re: Fw: Administrivia: ORBS
I think the issue most people aren't certain of, is when is it reasonable to test a machine, in the manner ORBS does?
I've never actually proposed pre-emptive scanning in forum as big as this before! Thanks Brian! :-) What I mean is that the last time I proposed this idea (or at least one almost the same) in a much smaller mailing list there were nearly lynch mobs coming down the wires! :-) It would still be interesting to try and estimate how much extra bandwidth and system resources a site like AOL would require to implement this, even against just the ~150k mailers listed in ORBS....
(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.)
These days I've been unable to find any justifiable need for an unprotected relay of any sort whatsoever. 99% of mailers should be the final delivery point (or at least the transfer point to some private network). The remaining few are ISPs who need to relay from their customers to the world, of course, but so long as they don't make the mistake of smarthosting for un-protected customer MTAs they can simply block relay by restricting it to their own netblocks. Even most MX targets are the final delivery point for the MXed domain. The real problem is that people are still installing mailers that do unprotected relaying by default.
5) Hosts listening to port 25.
[IMHO, Occams razor would have drawn blood already.]
Yup -- IMRSS isn't running any more.... It was a pretty interesting and revealing survey though. I hope someone can do it again too, without publishing the detailed results of course, just so we can measure our progress. -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
would have MTA turned on.)
These days I've been unable to find any justifiable need for an unprotected relay of any sort whatsoever. 99% of mailers should be the final delivery point (or at least the transfer point to some private network). The remaining few are ISPs who need to relay from their customers to the world, of course, but so long as they don't make the mistake of smarthosting for un-protected customer MTAs they can simply block relay by restricting it to their own netblocks. Even most MX Their customers != Their blocks, it's the problem. For example, the customers (mail customers) of ISP-1 can work through dialup or ISDN account of the ISP 2, etc. And it makes such access lists very long and relays relatively open (I know ISP whose relays are open for all russion netblocks, not for his own netblocks).
Don't try to do impossible - if you restrict relaying, you restrict access and service; totally free relay is wrong today; but totally restricted service is wrong too. In real life there is some balance between them.
targets are the final delivery point for the MXed domain. The real problem is that people are still installing mailers that do unprotected relaying by default.
5) Hosts listening to port 25.
[IMHO, Occams razor would have drawn blood already.]
Yup -- IMRSS isn't running any more.... It was a pretty interesting and revealing survey though. I hope someone can do it again too, without publishing the detailed results of course, just so we can measure our progress.
-- Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
Aleksei Roudnev, (+1 415) 585-3489 /San Francisco CA/
[ On Saturday, January 15, 2000 at 23:04:14 (+0300), Alex P. Rudnev wrote: ]
Subject: Re: Fw: Administrivia: ORBS
Their customers != Their blocks, it's the problem. For example, the customers (mail customers) of ISP-1 can work through dialup or ISDN account of the ISP 2, etc. And it makes such access lists very long and relays relatively open (I know ISP whose relays are open for all russion netblocks, not for his own netblocks).
So long as you're not trying to do this kind of access control on your core router there should be no problem. There are lots of high-performance filtering devices available today for very reasonable prices, adn you can build your own with free software on commodity hardware too. -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
Just again. The problem is not the mail relay blocking. Most ISP have good AUP's and in case if you send complain about SPAM source or SPAM relay, they close it at once. The problem is not with the RBL list which, of course, cause some headache amongs the network admins, but is conservative enougph to be used for the protection - because those and only those hosts are announced by this list which really are or was the spam relays. This means - we can trust to this list, because if some relay was really used as the spam relay, it means sysadmin really is interested to close it's free relaying (at least to stop this spam relaying), and (because spam relaying waste network and relay resources) he (sysadmin) usially are doing it. As the result, RBL usage do not cause us to lost many important mail (through it cause some lost and I can't recommend using it if you really depend of e-mail for your business or your life). But ORBS is another issue. Having open relay is not the crime - the crime is sending (directly or undirectly) the spam. There is different ways to fight the spam relaying, not the simple relay closing only (for example, you can use smart filterring, deny relaying for multi address messages only, etc etc). This means - if someone have mail server, and this server is not sending spam, it's not the reasons to cause sysadmin to do something with it (even if it's open relay by the nature). ORBS idea is the opposite - _YOU MUST LOCK YOUR DOOR, if you are not doing this, we'll enter and spoil the redinks and cause you to close your door by the keys_. It means - they cause a lot of headache over the network admins in the situation, when this headache could be avoided by doing NOTHING. Results are simple - first, it's not possible to use ORBS for those who depends of the e-mail (and if you use ORBS, my advice is to not use E_MAIL at all), second - a lot of network admins protects their sysadmins by filtering ORBS out. Just as the boy from the russion tail - first, he cried every evening _safe me, mother, it's a wolfs behind me_, then, when he meet the wolf in the forest, no one helped him because no one trusted him already. Just the same - ORBS list is the paranoyed list, and no one in the sane mind can trust this list. And so, wot for we are discussing the crazy service holded by the paranoyed people? On Sat, 15 Jan 2000, Greg A. Woods wrote:
Date: Sat, 15 Jan 2000 17:22:49 -0500 (EST) From: Greg A. Woods <woods@most.weird.com> Reply-To: North America Network Operators Group Mailing List <nanog@merit.edu> To: North America Network Operators Group Mailing List <nanog@merit.edu> Subject: Re: Fw: Administrivia: ORBS
[ On Saturday, January 15, 2000 at 23:04:14 (+0300), Alex P. Rudnev wrote: ]
Subject: Re: Fw: Administrivia: ORBS
Their customers != Their blocks, it's the problem. For example, the customers (mail customers) of ISP-1 can work through dialup or ISDN account of the ISP 2, etc. And it makes such access lists very long and relays relatively open (I know ISP whose relays are open for all russion netblocks, not for his own netblocks).
So long as you're not trying to do this kind of access control on your core router there should be no problem. There are lots of high-performance filtering devices available today for very reasonable prices, adn you can build your own with free software on commodity hardware too.
-- Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
Aleksei Roudnev, (+1 415) 585-3489 /San Francisco CA/
On Fri, 14 Jan 2000, Greg A. Woods wrote:
These days I've been unable to find any justifiable need for an unprotected relay of any sort whatsoever. 99% of mailers should be the final delivery point (or at least the transfer point to some private network). The remaining few are ISPs who need to relay from their customers to the world, of course, but so long as they don't make the mistake of smarthosting for un-protected customer MTAs they can simply block relay by restricting it to their own netblocks. Even most MX targets are the final delivery point for the MXed domain. The real problem is that people are still installing mailers that do unprotected relaying by default.
We do domain hosting and mail redirection (among other things), but we don't do dialup. Every single one of our customers has to use a third-party IAP for their general net access. Whether they have basic mail redirection or pop3 mailbox on our server, we only provide services relating to incoming mail. When they want to send mail out, they have to do it through their IAP's mail server. All fine and dandy, in theory. It's not unreasonable for them to want to send mail out as them@their.domain, and any sane mailer will let them do it - the problem is with the relay itself. Some IAPs don't permit any mail to be sent out through their relay unless it's something@the.isp. Others, most notably AOL, don't let their customers use any mailer other than the one they supply, and that forces them to use their assigned email address rather than the one they want to. "So what if it's valid, it's not our problem", say the IAPs. This leaves us in a tricky situation. Do we start doing dialup? It's not worth our time - I've been in that market before, and it's a royal pain in the arse - not to mention that the vast majority of IAPs here don't charge a penny for their services, and there's no way we can compete with that. Do we tell the customer to change ISP? Not only do they tend, like all users who don't quite understand the situation, to view it as a limitation of our service rather than a restriction enforced by their IAP, but we have by no means an exhaustive list of IAPs which restrict what they will and won't permit to be sent out through their relays, even if from their own IP ranges. The only thing we can do which allows all of our customers to send mail out with their address as the From: header, and not force them to use our dialup service (if we had one) is to run a completely open relay. POP before SMTP is a crufty hack, IMNSHO, and SMTP auth isn't implemented to enough of an extent that I'd be comfortable running it. Anyone who says there's absolutely no reason to run an open relay is talking absolute codswallop - as with every situation like this it requires a reasoned political decision at the site in question. Our solution? We run a closed relay and hope our customers understand the situation if they run into problems. On the whole, they do...but we've lost a few as a result. We don't use ORBS, either - Alex Rudnev has it spot on, to my mind. Oh, sure, our customers would be grateful if we could stop them receiving so much spam, but what do we say to the customer who can't receive an important email just because we're blocking the sender's mail relay? That'd be an ex-customer, very quickly. Watch the customers leave until the only ones we have left are the ones who don't care whether they receive email or not? An interesting business plan - don't think my bank manager would go for it, though. -- Patrick Evans - Sysadmin, bran addict and couch potato pre at pre dot org www.pre.org/pre
[ On Saturday, January 15, 2000 at 23:12:01 (+0000), Patrick Evans wrote: ]
Subject: Re: Fw: Administrivia: ORBS
The only thing we can do which allows all of our customers to send mail out with their address as the From: header, and not force them to use our dialup service (if we had one) is to run a completely open relay. POP before SMTP is a crufty hack, IMNSHO, and SMTP auth isn't implemented to enough of an extent that I'd be comfortable running it.
I think you underestimate the power of the "POP before SMTP" form of SMTP authorisation. It works very well. Some MUA clients have to be configured to use this scheme, but many do it by default. It would also be relatively easy for you to distribute a small authentication application to your customers too. Such things are easy to find off-the-shelf in fact, even for the crappy client platforms most of your customers are likely to be using.
Anyone who says there's absolutely no reason to run an open relay is talking absolute codswallop - as with every situation like this it requires a reasoned political decision at the site in question. Our solution? We run a closed relay and hope our customers understand the situation if they run into problems. On the whole, they do...but we've lost a few as a result.
In fact I do know what I am talking about because I am in fact practising what I preach. It may be difficult for someone who is not, or does not employ, a systems programmer to ensure their systems are capable of the schemes I've discussed, but IMNSHO if anyone running any kind of Internet service doesn't have a systems programmer either on staff or on retainer then they're bound to fail or be bought out eventually anyway. -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
Thus spake Greg A. Woods
I think you underestimate the power of the "POP before SMTP" form of SMTP authorisation. It works very well. Some MUA clients have to be configured to use this scheme, but many do it by default.
It may work pretty well, but that doesn't change it from being a really ugly kludge. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
participants (5)
-
Alex P. Rudnev -
Brian Dickson -
Jeff Mcadams -
Patrick Evans -
woods＠most.weird.com