RE: ORBS (Re: Scanning)

Mailman List Mirror (Read Only)
1

From: E.B. Dreger [mailto:eddy+public+spam@noc.everquick.net]
Sent: Sunday, May 27, 2001 8:05 AM

ORBS catches far more than MAPS.

As Randy stated "so does a hydrogen bomb". The problem is target acquisition
and [the lack of] discrimination. The REASON tactical nukes aren't used
regularly is the collateral damage issue.

My take is that anybody who has a
problem with the infrequent ORBS probes should have a huge
problem with the daily bombardment of relay attempts.

A system that tests positive for ORBS , yet is using MAPS, will not be used
as a spam relay. Yet, ORBS will list such a system.

Bottom line: Blocking mail from rogue servers is the best way to stop
spam and to not be a party to somebody else getting
relay-raped. Anyone with clue closed relays how many years ago?

It is more accurate to state that most folks have placed guards on their
mail systems.

I don't buy the "we need open relay for nationwide users" argument,
either. Build a cheap MX that does nothing but take mail from a given
POP, and send it to the world. Anti-spoofing at the border,
don't accept mail from the outside world, and you're done.

You must not have a roaming staff or are willing to keep telcos wealthy.

2

Date: Sun, 27 May 2001 09:11:39 -0700
From: Roeland Meyer <rmeyer@mhsc.com>

[ snip ]

I don't buy the "we need open relay for nationwide users" argument,
either. Build a cheap MX that does nothing but take mail from a given

            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

POP, and send it to the world. Anti-spoofing at the border,

   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

don't accept mail from the outside world, and you're done.

You must not have a roaming staff or are willing to keep telcos wealthy.

Or I might know a better way.

Again, put a simple MX at each POP. Want a constant IP address for the
SMTP server? Each POP's border router redirects the SMTP server's IP
address to the local machine, which only allows inbound SMTP from the
local POPs.

Nothing new here.

And then there are VPNs for roaming staff...

Eddy

3

Roeland Meyer wrote:

> I don't buy the "we need open relay for nationwide users" argument,
> either. Build a cheap MX that does nothing but take mail from a given
> POP, and send it to the world. Anti-spoofing at the border,
> don't accept mail from the outside world, and you're done.

You must not have a roaming staff or are willing to keep telcos wealthy.

RFC2554. Works very well for me; people can connect from
anywhere that doesn't have port 25 filtered or they can connect on
port 587, which is meant specifically for authenticated SMTP
connections.
Supported by all major e-mail clients, except for Outlook/OE 5.0, and
even then only if they are using a specific version of INETCOMM.DLL that
has a bug that causes it not to send authentication; upgrading to 5.5
fixes
that.

Sendmail, Exchange and a number of other mail server products now offer
RFC2554 support.

4

A system that tests positive for ORBS , yet is using MAPS, will not be used
as a spam relay. Yet, ORBS will list such a system.

I'm not sure I understand this logic:

1.) They test positive for orbs... so they ARE an open relay
2.) That system is using MAPS, which means that there is some subset of systems the open relay itself rejects mail from

Somehow that means that non-MAPS-listed sources (of which there are many) are somehow magically restricted from relaying through the open relay?

You must not have a roaming staff or are willing to keep telcos wealthy.

POP-Before-SMTP is good. SMTP AUTH is better. Solves the problem quite nicely.

D

5

roaming staff either use webmail or pop-before-smtp.

-Dan

6

Is there a rule that, except for local dial-in, we cannot offer the same
services to a client located in a part of the world that we dont't have
a dial-in POP as we offer to our local clients? Why shouldn't such clients
be able to get their dial-in somewhere and the rest of their services from
somewhere else? That includes using a remote SMTP server in the same way
a local user can, period.

--Mitch
NetSide

7

You have to balance that desire against your users' generally
  unspoken requirement that your service be functioning, usable,
  and able to deliver mail to its' final destination. If this
  were any other kind of service that commonly requires user
  authentication (accounting, data storage, etc.) there wouldn't
  even be a question.

  And seriously, Mitch, when was the last time that you heard a
  new argument for why you should close your relay? Since you're
  obviously unwilling to do so, what's the point of bringing it
  up again and again?

8

Well, you MUST (RFC2505, 2.1) prevent unauthorized use of your mail server as a mail relay.

So if your question is "since my local users don't have to authenticate themselves against my mail server, is there a rule that says I can't offer unauthenticated SMTP service to roaming users", I guess the answer is "yes, there IS actually a rule forbidding that."

Cheers,
D

9

Mitch,

Lets end this useless thread now. If it wasn't obvious to everyone
previously, it is definately obvious now. You're a whining crybaby who
doesn't want to secure his servers for ANY REASON. No matter that the
technology is there to do so. No matter that it will NOT cause undue
problems for your customers. You just want to whine about something.

I'm for one SICK OF IT! If you don't like being listed in
MAPS/ORBS/NAME-YOUR-LIST, secure your servers. If you want to complain
about it somewhere, do it someplace where it at least has a chance of
being operational content.

This is NANOG. Even if you drop the NA prefix, the rest of that means
"NETWORK OPERATORS GROUP." It does NOT mean "open mailserver operators
group" or anything like it.

So, grow up. Secure your server. Contact us from another email address
when you have. For now, you're <PLONKED!>

10

Well, you MUST (RFC2505, 2.1) prevent unauthorized use of your mail
server as a mail relay.

So if your question is "since my local users don't have to
authenticate themselves against my mail server, is there a rule that
says I can't offer unauthenticated SMTP service to roaming users", I
guess the answer is "yes, there IS actually a rule forbidding that."

Cheers,
D

Derek, there is a subtle difference between the words you SHOULD and
you MUST. The RFC you quoted is a "Best Current Practices" document.
You know, like "The Surgeon General had determined that [insert your
favorite vice here] is bad for your health". i.e, he can't order you
MUST stop smoking, maybe you SHOULD consider it because yadayada.

Now let's go back to 1997 and see how this baby was born. In Sep 1997,
on this very list, Paul Vixie was known to have laid the seed:

`Could somebody who hasn't been burned to a crisp by IETF politics please
write a "Mail Relay Requirements" RFC that we can brandish at these vendors?
(Dave Crocker seems like a logical choice for this given his past credits.)'

Full text of the message at Re: BGP blackholing spam [was Spammer Bust]

From this grew a business that puts food on the table for several members

of this list. And now the paid enforcers and their groupies are brandishing
it at legitimate network operators. There is a lot of money in the jackpot
now, in case you haven't noticed, and dissent will not be tollerated.

If people would have paid attention then to the implications, this monster
would have been nipped in the bud. Instead, their camel is now in your tent.
And it's not even Uncle Sam's beast...

So what was that Conan saying again? :wink:

--Mitch
NetSide

11

> Is there a rule that, except for local dial-in, we cannot offer the same
> services to a client located in a part of the world that we dont't have
> a dial-in POP as we offer to our local clients? Why shouldn't such clients
> be able to get their dial-in somewhere and the rest of their services from
> somewhere else? That includes using a remote SMTP server in the same way
> a local user can, period.

  You have to balance that desire against your users' generally
  unspoken requirement that your service be functioning, usable,
  and able to deliver mail to its' final destination. If this
  were any other kind of service that commonly requires user
  authentication (accounting, data storage, etc.) there wouldn't
  even be a question.

The service is functional, usable, and able to deliver mail to those
destinations your organization or the other overseas rival gang have no
control over. Some users left because of the blockade. Others stayed,
because they understand the reasoning posted at http://www.dotcomeon.com

That *should* worry you. It shows that most Joe users hate Big Brother.

  And seriously, Mitch, when was the last time that you heard a
  new argument for why you should close your relay? Since you're
  obviously unwilling to do so, what's the point of bringing it
  up again and again?

--
J.D. Falk SILENCE IS FOO!
<jdfalk@cybernothing.org>

I didn't bring it up this time, you did, and even changed the topic.
Vixie himself posted a request for comments on this also (twice, uh oh),
and I haven't seen any replies. Perhaps others are afraid? I resisted
the temptation to answer, although you can imagine I had a lot to say
to your boss (btw, I did put on a shirt and shoes just to write these
lines :wink:

I did reply once to this message, since it's been addressed to me, and
my private post bounces from your network. It seems you still cannot
answer the top paragraph intelligently.

So here's the essence of my reasoning: your approach to combat spamming
and your methods of enforcement are wrong. You employ the same argument
to restrict relays as used against lawful gun owners by those that want
to take them away. You are unwilling to go after the actual spammers, and
instead punish network owners for someone else's client deeds. Well, that
won't fly in America. There is your legal precedent in spirit.

I am in favor of explicit federal legislation regulating this aspect of
electronic communications. Then we'll all know exactly what's legal and
what's not, and the playing field becomes level again for all. That would
likely put you out of a job, I'm afraid...

FOO!

--Mitch
NetSide

12

> > Is there a rule that, except for local dial-in, we cannot offer the same
> > services to a client located in a part of the world that we dont't have

Auth-SMTP?

control over. Some users left because of the blockade. Others stayed,
because they understand the reasoning posted at http://www.dotcomeon.com

heh, personal vendetta or what! (for the record i would have left)

That *should* worry you. It shows that most Joe users hate Big Brother.

or arent really following the technical reasoning and arguments..

I didn't bring it up this time, you did, and even changed the topic.
Vixie himself posted a request for comments on this also (twice, uh oh),

did he turn you down for a job or something? said something bad about your
mother?

I did reply once to this message, since it's been addressed to me, and
my private post bounces from your network. It seems you still cannot

you could get a hotmail account until you become a fully functional
provider?

So here's the essence of my reasoning: your approach to combat spamming
and your methods of enforcement are wrong. You employ the same argument
to restrict relays as used against lawful gun owners by those that want
to take them away. You are unwilling to go after the actual spammers, and
instead punish network owners for someone else's client deeds. Well, that
won't fly in America. There is your legal precedent in spirit.

guns aside, how can you go after spammers? the internet is global and
anonymous. you're getting strangely patriotic over the discussion on open
relays, surprised theres no mp3 of star spangled banner attached..

I am in favor of explicit federal legislation regulating this aspect of
electronic communications. Then we'll all know exactly what's legal and
what's not, and the playing field becomes level again for all. That would
likely put you out of a job, I'm afraid...

good plan, one small flaw; not sure on the exact figures but theres many
o.r servers outside the US, especially asia.. and much of the spam i
receive is not of US origin, and not being in the US i wouldnt have to
honour any such legislation. so tell me, how will US federal law improve
on ORBS/MAPS other than you'd be able to start sending email directly to
Vixie again! (you could always setup another - closed - mail server if you
insist on o.r. for roaming users to get around MAPS/ORBS)

Interesting as this thread may be (sarc), is there actually any topical
discussion going on here or are a few individuals publicly airing their
problems at the expense of my Inbox?

.. suggest someone either contributes or we give up this thread!!!

Steve

13

No, what worries me is that you realize you're running an open SMTP
relay for no real reason other than stubbornness, and outright refuse
to fix it, even though it's widely regarded as an irresponsible
operational practice.

Please quit whining and close it up already. Thanks!

-a

14

Mitch Halmu wrote:

The service is functional, usable, and able to deliver mail to those
destinations your organization or the other overseas rival gang have no
control over. Some users left because of the blockade. Others stayed,
because they understand the reasoning posted at http://www.dotcomeon.com

That *should* worry you. It shows that most Joe users hate Big Brother.

If use of the blackhole lists was mandatory, I would say that that last
statment has some validity.

Since it's completely optional, the statement has no validity.

15

"Stephen J. Wilcox" wrote:

> > > Is there a rule that, except for local dial-in, we cannot offer the same
> > > services to a client located in a part of the world that we dont't have

Auth-SMTP?

As I said to Roeland Meyer, it's a good solution and all but
eliminates the roaming user problem.

16

Mitch Halmu wrote:

Is there a rule that, except for local dial-in, we cannot offer the same
services to a client located in a part of the world that we dont't have
a dial-in POP as we offer to our local clients? Why shouldn't such clients
be able to get their dial-in somewhere and the rest of their services from
somewhere else? That includes using a remote SMTP server in the same way
a local user can, period.

You *can* do all that. I prefer SMTP AUTH to POP-before-SMTP because PbS
leaves
a small vulnerability on your mail server - very small, but it exists
nonetheless.
But many providers use PbS too.

If this whole issue cropped up because you wanted to provide roaming
access
to your mail servers, those are two very widely-implemented solutions.
If you
want, I can even offer some help getting it set up as I have had a
longstanding
policy of offering relay-closing help at no charge to ISPs who need it.
The
only requirement is that you be running an MTA that I'm familiar with.

17

So here's the essence of my reasoning: your approach to combat spamming
and your methods of enforcement are wrong. You employ the same argument
to restrict relays as used against lawful gun owners by those that want
to take them away. You are unwilling to go after the actual spammers, and
instead punish network owners for someone else's client deeds. Well, that
won't fly in America. There is your legal precedent in spirit.

  The core problem with your reasoning is that you consider any
  site's refusal of your mail to be "enforcement," presumably
  some type of punishment, while most of the folks who deny your
  mail see it as security. They are protecting themselves from
  the people that YOU have allowed to abuse your mail server.
  They don't know or care who you are, who your users are, or
  what your reasons for allowing that abuse might be.

  I don't expect you to admit to being wrong this late in the
  thread, but please, think about that difference for a while,
  even if you disagree with it.

I am in favor of explicit federal legislation regulating this aspect of
electronic communications. Then we'll all know exactly what's legal and
what's not, and the playing field becomes level again for all. That would
likely put you out of a job, I'm afraid...

  It is the fervent wish of every sane anti-spammer (and yes, I
  know, there's a lot who aren't sane) that we could stop doing
  this work entirely.

  Oh, and you appear to be mistaken about which organizations I
  am currently involved with. I will endeavor to ensure that
  all relevant web sties are updated.

18

> So here's the essence of my reasoning: your approach to combat spamming
> and your methods of enforcement are wrong. You employ the same argument
> to restrict relays as used against lawful gun owners by those that want
> to take them away. You are unwilling to go after the actual spammers, and

This is nonsense...most of us "go after the actual spammers" as best as we
can and the law permits us. If you supply plastic explosives to
terrorists with no checks, you may not be directly responsible for their
actions, but you are certainly part of the problem. If you have an open
relay, you are a big part of the spam problem, whether you like it or not.

> instead punish network owners for someone else's client deeds. Well, that
> won't fly in America. There is your legal precedent in spirit.

What does "america" have to do with it? Open relays are all over the
place, and a big PITA. Refusing your mail is *my* right, as owner of my
network; and also my responsibility. Of course it is your "right" to have
an open relay if you like, just don't expect everyone else to accept
email from it.

  The core problem with your reasoning is that you consider any
  site's refusal of your mail to be "enforcement," presumably
  some type of punishment, while most of the folks who deny your
  mail see it as security. They are protecting themselves from
  the people that YOU have allowed to abuse your mail server.
  They don't know or care who you are, who your users are, or
  what your reasons for allowing that abuse might be.

I would argue that it's both "enforcement" and security. I know MAPS has
to argue otherwise in court, but let's face it, incentive is alot of what
it's about.

James Smallacombe PlantageNet, Inc. CEO and Janitor
up@3.am http://3.am

19

OK folks. Please. Leave poor Mitch alone and maybe he'll realize that
this ISN'T the forum for him and go away.

If you want a huge laugh, (and want to give ole Mitch the /. or NANOG
effect) go check out http://www.netside.net/sys.html

"Network and Communications
NetSide is connected directly to the Internet backbone via a high speed
point-to-point full T1 link (1.544 Mbps) into the MCI backbone (at Pompano
Beach). A Cisco 4000 router is used to direct the in-house Ethernet TCP/IP
network traffic to and from the Internet. To help reduce the network load
and improve performance, two Ethernet 10-BaseT interfaces, connected to
separate AT&T StarLAN 10 hubs (with blinking lights :slight_smile: forming in effect
subnets, are used on the servers. Each subnet connects to a different
Ethernet port on the Cisco router."

That's some FAT pipe you have there Mitch. What EVER do you do with your
spare bandwidth? heheheh And your network just blows me away. I love the
"To help reduce the network load" part. Where's the load? You've got
serious issues if you can't pass a DS1 worth of traffic without your net
melting.

"Emergency Provisions
Besides redundant servers, NetSide is also prepared to operate in
emergency conditions, such as city-wide power failures as experienced
during Hurricane Andrew. Housed in a solid concrete block structure, we
don't expect heavy storm damage to occur. Our fiber rack (for telephone
and data lines) has 3 rows of battery backup rated for 8 hours of
continuous operation. NetSide owns 2 emergency generators: an extended-run
heavy-duty Coleman Powermate Vantage (14HP 2cyl electric start gas engine
- 7000W), and a portable medium-duty Dayton (5HP gas engine - 2200W)."

Wow! So, you've got enough generator to power the lights, soda machine
and coffee maker. You gonna invite all the customers to your site and sit
around and watch the servers not run drinking soda and coffee? Sounds
like fun.

Mitch. You're an END USER. Sure, you sell dialup access. You couldn't
do much more with that big FAT DS1 you've got. You're an END
USER.

9 border3-fddi-0.PompanoBeach.cw.net (204.70.92.19) [3561] 62.524 ms 60.403 ms 63.456 ms
10 netside-corporation.PompanoBeach.cw.net (204.70.95.18) [3561] 166.477 ms 198.570 ms 117.225 ms
11 205.159.140.2 (205.159.140.2) [3561] 195.153 ms * 194.081 ms

You see, if you were a real network operator:

(1) That would be more than a DS1.
(2) The last hop wouldn't show up with the ASN of your upstream.
(3) The last hop would RESOLVE in in-addr.

NetSide Corporation (NET-NETSIDE)
   P.O.Box 403895
   Miami Beach, FL 33140
   US

   Netname: NETSIDE
   Netblock: 205.159.140.0 - 205.159.140.255
   Maintainer: NETS

   Coordinator:
      Halmu, Mircea L. (MLH3-ARIN) admin@NETSIDE.NET
      305-531-1995

   Record last updated on 29-Oct-1998.
   Database last updated on 26-May-2001 22:57:19 EDT.

It might be a good idea to register some in-addr resolution servers for
that block there Mitch.

...Then again, why would we expect you to run any other portion of your
operation any more professionally than you run your mailserver?

I tell you what. You rate right up there in my book.

Open Relay: 1,000,000,000 points
Big FAT T1: 10,000,000 points
Broken in-addr.arpa: 5,999,550 points
HUBS not SWITCHES: 99,999,999,999 TILT! TILT! TILT!

20

From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of
John Fraizer
Sent: May 28, 2001 4:43 PM
To: Mitch Halmu
Cc: nanog@nanog.org
Subject: Re: Mitch tries to defend his open relay again (was Re: ORBS
(Re: Scanning))

[note: the thing below was quoted by John from Mitch's site]

point-to-point full T1 link (1.544 Mbps) into the MCI backbone (at Pompano

That's the problem with Mitch, then. He must have gotten stuck in some type
of time warp (or cool cryogenics), if he hasn't noticed that the "MCI"
backbone was sold to Cable & Wireless nearly three years ago now (IIRC).

Give the man a break... if he just woke up from an extended deep sleep or
something, then it's no surprise that he still wants to run his mail server
the way people ran mail servers five years ago.

Vivien