Stealth Blocking

[In the message entitled "RE: Stealth Blocking" on May 24, Roeland Meyer <rmeyer@mhsc.com> writes:]

I'm getting seriously confused here. I thought that the open-relay issue was
irelevent to MAPS. That MAPS only black-holed confirmed SPAM sites (a little
tougher, but more granular, charter). Further, that it was ORBS that listed
open-relay sites specifically, whether they were involved in a spam or not
(unacceptable due to punishing potential anti-spammers for proliferating
spam that never saw their systems). To me, these are two entirely different
charters. If MAPS starts to look like ORBS then I will stop using MAPS.

Can someone please clarify?

Sure.

MAPS has four real-time lists.

The MAPS RBL(sm) is a list of sites and networks which are known to be
friendly, or neutral to spam. They include sites which harbour known spam
origin points, multi-hop open relays which refuse to close (and have
transmitted spam), spamware sites, and other persistant spam sources. Hosts
and networks can use this list via DNS (rejecting mail, and other traffic as
they see fit), or BGP (usually blackholing all traffic bound for those
sites). It's very hard to get a site listed. It's quite easy to
get off the RBL, assuming that the issue that caused the listing has been
corrected.

The MAPS RSS(sm) is a list of open relays *which have been abused*. These
are sites which have been reported to MAPS as open relays, and have spam
samples. Once the spam has been verified, a test is performed to verify
that the site is, indeed, an open relay. If a sample message is accepted,
and then returned by the site as a relay, the host is listed. Removal from
the RSS requires that the host no longer relays. Automated probes are never
done - a human must request the test, and spam must be available. Because
of the very large number of hosts listed (around 100,000 as I write this),
it's generally used in DNS mode only. It's pretty easy to get a host which
is an open relay that has transmitted spam onto the list. Between 100 and
1,500 hosts per day are added, and hundreds per day are taken off (as soon
as they let MAPS know that the relay has been closed).

The MAPS DUL(sm) is a list of dialup ports. These are dialups which have
been reported to MAPS by the ISP running them, or by users which have
received spam from the dialup. An investigator verifies that the address
range does contain dialup ports before they are listed. Hosts and networks
typically use this list in DNS mode to reject direct-from-dialup spam. It's
time-consuming to get an address listed, and also time-consuming to get an
address removed from this list.

The MAPS RBL+(sm) is a combined list, which allows a single lookup to
search all lists. It's possible to use this in BGP mode, but it's
unlikely that anyone would want to do so.

So, does MAPS look like ORBS?

ORBS probes systems no matter if spam has emitted or not. Does this catch
more open relays? You bet. Is it network abuse to scan for open relays? I
think so. Do spammers use the same techniques? You bet.

MAPS probes systems only after they have been abused by spammers. Does this
allow spammers to use the relays for at least one spam run? You bet. Is it
network abuse to confirm an open relay that has transmitted spam? I don't
think so. Do spammers use the same techniques? I don't think so.

ORBS probes systems periodically after they are listed to see if they have
been closed. Does this ensure that relays are removed after they are
secured? Sort of. But this requires that the hosts listed be probed
frequently, and still doesn't ensure that they are removed "as soon as
they are secured".

MAPS depends on the system administrator contacting MAPS to get a host
de-listed. Does this ensure that they are removed once they are secured?
Sort of. It does require that the admin be willing to contact MAPS.

So, does MAPS look like ORBS? You decide.

I'm certain that all of the network owners on this list want spam to stop.
MAPS is one tool that can help. ORBS is another. Where you draw the line,
or how you protect your networks is your choice.

One thing that I think *will* help, particularly in the short term, is port
25 blocking of dialup ports. It's my personal opinion that this will have
the greatest impact on spammers who abuse open relays. I've watched this
happen over the last few months, as various large networks have secured
their dialup ports. It's impressive.

Returning to operational traffic:

One thing that I think *will* help, particularly in the short term, is
port 25 blocking of dialup ports. It's my personal opinion that this
will have the greatest impact on spammers who abuse open relays. I've
watched this happen over the last few months, as various large networks
have secured their dialup ports. It's impressive.

TCP rate-limiting on outbound traffic to *:25 would also be extremely
effective, particularly on unclassified customer traffic, and without the
heavy-handed nature of denying all dial-up traffic. Rate-limiting doesn't
interfere with low-volume legitimate mail, but it really cramps spam.

I've seen a number of opinions that it doesn't do squat to cramp spam.

Remember that the spammer is handing the "open" relay one piece of mail
with zillions of RCPT TO:s - rate limiting the outbound just means that
the zillions of recipients sit in *your* queue that much longer. Also,
I have heard from multiple sources that the spammers are well clued
enough to utilize multiple relays in parallel - if you rate limit to
1/N of bandwidth, they just use N relays at the same time. The problem
is that you shoot YOURSELF in the foot by DOS'ing yourself by the time
you get N cranked high enough to do any serious damage to the spammer....

Very interesting statistics. It gives you a clear picture of the magnitude
of the squeeze. Now I understand why such heavy hammer was needed at the
helm full-time. Supposing that 100,000 server owners plus those forcibly
're-educated' get together and do something about it, like scream, or jump
of a 12 inch stool, or donate $10 each, would they be able to shake Dave
off his high horse? How about if they also rally their users that were
suddenly cut off?

The collateral damage in blocking 100,000 hosts is simply unacceptable.
Especially because there are only a few hundred die-hard professional
spammers that need to be rooted out, and the problem diminishes, or at
least becomes manageable in another way. As an ISP, I have yet to see
a list of black sheep compiled consisting of individuals, spam companies,
or credit cards used to defraud that should not be subscribed. Banks
share such information, why can't ISPs?

No matter how noble the cause, the methods are wrong. In all the debate,
it was perhaps lost that no viable technological solution to roaming,
meaning one that is happily accepted by the end user, exists yet. And
please don't mention SMTP Auth, it's not perfected yet.

--Mitch
NetSide

Remember that the spammer is handing the "open" relay one piece of
mail with zillions of RCPT TO:s - rate limiting the outbound just
means that the zillions of recipients sit in *your* queue that much
longer.

I will add "further punishes/diminishes the harm of open relays" to the
"pro" column. :wink:

I have heard from multiple sources that the spammers are well clued
enough to utilize multiple relays in parallel - if you rate limit to
1/N of bandwidth, they just use N relays at the same time.

If the rate limit is applied to *:25, then the *MORE* relays the spammer
uses, the longer it takes for him to do it.

pop-before-smtp

happily accepted by hundreds of thousands of roaming clients.

-Dan

-----BEGIN PGP SIGNED MESSAGE-----

[...]

No matter how noble the cause, the methods are wrong. In all the debate,
it was perhaps lost that no viable technological solution to roaming,
meaning one that is happily accepted by the end user, exists yet. And
please don't mention SMTP Auth, it's not perfected yet.

http://spam.abuse.net/spam/tools/smPbS.html

POP3 before SMTP. Works for any MUA that supports POP3, and the only
impact to the user experience is that the user needs to check her mail
before she sends mail (which most do anyway).

Now, please try this, close your relay, and cease this off-topic whining
to this list.

Matt

- --
Matthew S. Cramer <mscramer@armstrong.com> Office: 717-396-5032
Lead Security Analyst Fax: 717-396-5590
Armstrong Information Technology Services Pager: 717-305-3915
Armstrong World Industries, Inc. Cell: 717-917-7099

The collateral damage in blocking 100,000 hosts is simply unacceptable.
Especially because there are only a few hundred die-hard professional
spammers that need to be rooted out, and the problem diminishes, or at
least becomes manageable in another way. As an ISP, I have yet to see
a list of black sheep compiled consisting of individuals, spam companies,
or credit cards used to defraud that should not be subscribed. Banks
share such information, why can't ISPs?

Assuming that 25% of the IP space is assigned, and 1% of IP space assigned
is a mail server, that is still blocking only 1% of mail servers.

I know more then 10 million mail servers exist.

Along those lines, let me get this straight. You support someone
compiling a list of spammers that you won't sell to, but you oppose
someone compiling a list of people that I choose not to accept mail
from. That is quite interesting, and somewhat hypocritical.

No matter how noble the cause, the methods are wrong. In all the debate,
it was perhaps lost that no viable technological solution to roaming,
meaning one that is happily accepted by the end user, exists yet. And
please don't mention SMTP Auth, it's not perfected yet.

We tell users that if they roam they need to use the mail server of the
place they are roaming to.

As a matter of fact, we are in the process of setting up a set of rules to
divert all port 25 bound traffic on our dialups to local mail servers.

If everyone diverted all local traffic to a local mail server, the problem
of open relays would go away.

Jason

It interferes heavily with transmission of large files via email, though,
and this *IS* a valid use of service.

Not at all. "People" is the key. The list in question is of servers
used by innocent people. The bad people are someone else's clients.
I don't feel that it's hypocritical to refuse service to an individual
that just cheated a fellow ISP, just like a bank will not issue an
unsecured loan or credit card to someone that cheated another bank.

The problem is, ISPs will not cooperate willingly to identify their
repeat offenders. Whatever legalities are involved could be sorted out
in the same fashion as credit reporting agencies are set up.

Hey, if MAPS is willing to change their business model by becoming
an agency that reports on the individual or company that author spam,
instead of squeezing providers for a deed performed by someone else's
client, I would be the first one to support the initiative.

--Mitch
NetSide

I will give you a solid reason why we won't try this, quoting research
with POP-before-SMTP conducted by the founder of MAPS TSI, Chip Rosenthal
http://users.laserlink.net/~chip/relay-pres-9910/

You don't have to believe me that our clients will not accept that, take
his words instead:

"Our users hated it - particularly those using MS Outlook"

No need to describe what happens when your clients hate your service...

--Mitch
NetSide

Shawn McMahon wrote:

> TCP rate-limiting on outbound traffic to *:25 would also be extremely
> effective, particularly on unclassified customer traffic, and without the
> heavy-handed nature of denying all dial-up traffic. Rate-limiting doesn't
> interfere with low-volume legitimate mail, but it really cramps spam.

It interferes heavily with transmission of large files via email, though,
and this *IS* a valid use of service.

The transmission of large files is not a valid use of email.

So you say. Feel free to configure your network that way.

Meanwhile, millions of people will continue to disagree with you daily.

Of course this page is, ah, just a little old... presumably outlook
express is a little better now.

Of course he also states laserlink *DOES* use pop-before-smtp, so...

-Dan

Well, I guess you're going to have to decide which they're going to hate
more; inconvenience with one POS email client that's going to get them
hacked anyway, or not being able to send email to hundreds of domains.

Pop before SMTP has come a long way since 1999, and newer outlook does
SMTP auth. If you support both, Pop before SMTP for clients who cannot
do SMTP Auth, then you shouldn't have users hating it.

Jason

Mitch Halmu was said to been seen saying:

I will give you a solid reason why we won't try this, quoting research
with POP-before-SMTP conducted by the founder of MAPS TSI, Chip Rosenthal
http://users.laserlink.net/~chip/relay-pres-9910/

You don't have to believe me that our clients will not accept that, take
his words instead:

"Our users hated it - particularly those using MS Outlook"

No need to describe what happens when your clients hate your service...

  From past experience MS Outlook in and of itself is the worst MUA
to use for Internet mail to begin with as the whole idea of internet mail
was an afterthought, doesn't follow half the MIME standards and for sake
of not finding a more "high tech" way to say it... It just plan sucks, get
a real MUA.

  Jeremy T. Bouse

My clients use SMTP AUTH, or (if they either have an old mail client, or don't have AUTH configured) use smtp-after-POP. Both work well. The SMTP AUTH implementation in sendmail 8.11.x works flawlessly, as does the TLS implementation, which we also support and use. Outlook and Outlook Express support SMTP AUTH with no problems whatsoever. Their TLS implementation has some issues.

Eudora 5.1 has the cleanest implementation of TLS and SMTP AUTH I've seen anywhere. They've done a great job with the implementation. Same goes for Qpopper 4.0, which is easy to work with, and supports TLS well.

We do email hosting, but provide no access services. All of our users connect to our mail servers remotely. We've never run an open relay, and our customers have full access to use our SMTP and POP services. It really is possible to do all of this, be successful and have happy customers.

Returning to operational traffic:

> One thing that I think *will* help, particularly in the short term, is
> port 25 blocking of dialup ports. It's my personal opinion that this
> will have the greatest impact on spammers who abuse open relays. I've
> watched this happen over the last few months, as various large networks
> have secured their dialup ports. It's impressive.

TCP rate-limiting on outbound traffic to *:25 would also be extremely
effective, particularly on unclassified customer traffic, and without the
heavy-handed nature of denying all dial-up traffic. Rate-limiting doesn't
interfere with low-volume legitimate mail, but it really cramps spam.

I'm partial to intercepting, rather than blocking, port 25 outbound traffic
from dialups and redirecting it to a mail relay. This way, you can easily
see which of your users are sending spam, because you force it all to go
through your own mail relay, even when the dialup user tried to connect
directly to MX hosts. Roaming users would not need to change their MUA
configuration to use a different outgoing relay. It also gives you the
opportunity to expunge the queue of spam as soon as it is noticed, sparing
other admins the pain of dealing with it, and saving yourself some
embarassment and pain dealing with the complaints.