|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Fw: Administrivia: ORBS
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: [email protected]
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
|