SORBS Contact

Yes. First, run a quality MTA -- that *requires* an open-source MTA
that is subject to ongoing, frequent, and strenuous peer review.
I recommend one of {postfix, sendmail, exim, courier}. I recommend
against qmail.

Second, use the built-in capabilities of that MTA to block SMTP
traffic from misbehaving mail servers. Examples: (1) Use the
greet_pause (sendmail) or equivalent feature. (2) enable checks for
forward and reverse DNS existence. (3) enable checks for HELO/EHLO
(only to see if it's a FQDN, not to see if it matches connecting host).
(4) use postgrey (or equivalent) with whitelisting of hosts that
are "known" to you. And so on -- each MTA has a myriad of features
that boil down to "reject mail from misbehaving hosts" and those
features can be used to reject an awful lot of spam.

  (Yes, these measures will also occasionally reject mail from
  hosts which are either running highly broken software or which
  are badly misconfigured. This is a feature, not a bug, and
  the onus is on the operators of those hosts to bring them into
  compliance with Internet standards, both codified and de facto.)
  
Third, Put in the Spamhaus DROP list on your border routers/firewalls.
There is no reason to accept ANY network traffic, nor send any network
traffic to, any network on that list. Nothing good can come of it --
for you, that is. Update once a month.

Fourth, use a judicious selection of DNSBLs/RHSBLs (to do outright
rejection). I use and recommend:

  Spamhaus XBL (which is the XBL+CBL combined zone).
  NJABL
  DSBL
  TQMcube zone: dhcp
  SORBS zones: http, socks, misc, smtp, web, zombie, dul
  AHBL

I've never had a FP from the first three over many years of use.
I've had a handful of scattered FPs from the second three, but each
has been quickly addressed by the zone's maintainers -- and about half
of those weren't their fault anyway, but they still fixed the problem.

Fifth, if you don't need to accept mail from certain countries: don't.
Many people (including me) refuse all mail from Korean and Chinese IP
space because *at their site* it's 100.00% spam. TQMcube provides DNSBls
for that, as do others. (Conversely, if you happen to be in either of
those countries, you may find that 100.00% of your incoming traffic from
the US is spam...in which case you should consider blocking all US IP space.)

Sixth, consider a combination of AV/AS measures. One such combination
might be ClamAV and SpamAssassin; another might use those two glued
together with Amavis-new. But: it's not worth doing this until you've
done all the other stuff, because otherwise you will burden these
(relatively) computationally-intensive programs with traffic that you
could -- and should -- have already rejected near the beginning of
the SMTP transaction.

If you use SpamAssassin, you can also use various DNSBLs as part of
weighted scoring. This is a fallback if you're not comfortable using
them to do outright rejection.

Seventh, do not use SMTP callbacks -- they are abusive and readily
lend themselves to DDoS attacks. They're also pointless and stupid.
Don't bother using DomainKeys/SPF/whatever -- these technologies were
failures from the beginning despite grandiose promises ("Spam as a
technical problem is solved by SPF"). And do everything possible
to make sure you don't emit outscatter (aka backscatter): reject
during the SMTP conversation, don't accept-then-bounce.

Eighth, get on the mailing lists that discuss this, like Spam-L,
spam-research, spam-tools, spambayes, etc. NANOG really isn't
the best place for this conversation.

Finally, and perhaps most importantly: don't be a source of spam or a
supporter of it (by providing HTTP, DNS or other services to spammers).
Make sure you have a working, unblocked "abuse" address, read it,
and act on what you receive there promptly - by immediately and
permanently revoking all services that you're providing to spammers.
Make sure that you have a TOS/AUP in place that allows you to shut
them down without prior notice -- i.e. the only warning they get is
the one in the TOS/AUP when they sign it. Add a clause that allows
you to confiscate their data/equipment -- this will deter a *lot*
of spammers from even trying to sign up with you, which in turn will
greatly diminish the risk to your network and the amount of work you
may have to do later.

  (The only reason any network has persistent/systemic issues with
  spam (as opposed to sporadic/isolated issues, which can happen
  to anyone) is that its operators are (1) lazy (2) stupid
  (3) incompetent (4) greedy. There are no exceptions. There are
  also no excuses.)
---Rsk

>>
>>>This is also why I took the time to create:
>>>
>>> <http://www.ietf.org/internet-drafts/draft-msullivan-dnsop-generic-naming-schemes-00.txt&gt;

The reason I do not like RDNS naming scheme is because it forces
one particular policy as part of the name.

Fair enough. FWIW, I've seen a wide variety of naming schemes (I've
got a project that collects these as an antispam/anti-botnet measure,
and so far we've got around 16K conventions documented for 11K domains).

I've read and commented on the ID above; I think Mat's heart is in the
right place but his hopes are too high. Not just because his approach is
too English-focused (what of correo for mail? what of other i18n
variants for 'static' or 'dynamic'?) but because I've seen so many bad
examples of people using rDNS for nothing useful at all, I doubt they'll
suddenly wake up and realize "hey! I could have encoded something
useful and meaningful into my PTR!" But it's a start.

Among my favorites are those who feel it necessary to add 'rev',
'reverse', 'ptr', 'ip', etc. to the PTR along with some encoding of the
IP itself. People, we *know* it's a PTR. If we didn't know the IP, we
couldn't have looked it up, so it's rather fruitless to encode it in the
PTR, don't you think? I'm guilty of the same thing, as the IP does
provide a differentiator as well as a way to say "{something}.domain",
or "this IP is not used for anything in particular", but it's still
an area in need of some inquiry.

Ideally, speaking as a mail admin, I'd prefer that any given PTR have
some indication of:

- the assignment type and duration (short-term pool, long-term dyn,
   static, etc.)
- the technology in use (dialup, cable, dsl, wireless, etc.)
- whether it's assigned for 'business' or 'personal' use (yeah, I
   know, lousy distinction, but suggest a better one)

These are all useful for those who have to make judgement calls about
whether to trust output from a given source; this is true regardless of
protocol. It just happens that for some, email is in high relief; for
others, it might be IRC or Web spammers or SMS or ssh dictionary attacks
or whatever.

Of the 16K naming conventions I've got handy, over 100 refer to IPs
that are labeled in one manner or another as unassigned. Of course,
I collected them from spam I received here, but they're officially not
in use. Thanks! I guess I'll refuse all mail from them.

Over half are classified as 'generic' - namely, there is so little
useful information in them we can't tell whether they're dynamic,
static, residential, dialup/dsl/cable/wireless, or anything. Many,
in fact, just start with 'host' and end with some variant of the
IP address encoded into the PTR.

Only 682 of ~16K provide us enough information for us to judge them as
plainly 'static'. (There are a few other classifications that may
suggest static assignment, such as 'nat', 'vlan', 'lan', 'colo',
'webhost', etc. but that's just guesswork - 'dhcp' may strongly denote
dynamic, as may 'pool', but we've seen static DHCP as well as static
"pools", whatever they are.) The most popular approach beyond the simple
"host-foo" seems to involve encoding geographic information into the
PTR; after that is perhaps advertising "hosted.by.superwebhost!" or
redundancy "bigisp-foo-bar-baz.dyn.bigisp.net". Worst among those who
actually provide rDNS in SE Asia is probably tm.net.my, who name all of
their customer PTRs 'tm.net.my'. Hm. Maybe encoding the IP in the PTR
ain't such a bad idea after all, especially for tracking down mass
mailing viruses that HELO with the value of their PTR through NATs.

On the bright side, people seem to have mostly woken up to the idea
that if you're going to put static/dynamic identifiers into the PTR,
you need to do it rightwards, rather than leftwards e.g.

1-2-3-4.east-campus.resnet.dhcp.pool.dyn.miskatonic.edu

rather than

dyn-pool.dhcp.resnet-1-2.east.3-4.campus.miskatonic.edu

as the former is easily collected in formats such as sendmail's
access.db and doesn't require expensive regex overhead or many, many
entries to cover a single class of listing. I'm definitely seeing a
shift towards the former approach from the latter, though there are
always the jokers like 'dynamic_dsl_client.dsl.gol.net.gy' who woke up
and changed their _s to -s one day this year, but left the positional
aspects as is. And yes, that's the *full name* of the PTR, so at
least you can block it all with an access.db entry.

Your point below about having different schemes for policies in
different realms is on target, but doesn't mitigate the responsibility
of all ISPs to provide some useful information about their services to
remote systems; a well-designed PTR can do that as a first-stage effort
while we wait for $PROTOCOL's $ENHANCEMENT to stop $ABUSE to wend its
way through the standards committees and implementation.

My preference is that you lookup RDNS name and they do additional
lookup when you do need a policy information (this can for example
be done with SPF record).

My preference is that my first line of defense against botnets and
other outbreaks should be refusing mail from hosts with generic PTRs.
It works very well, and doesn't require the introduction and field
testing of new TXT formats and parsers or other RRs. And for the most
part, user/admin education can quickly mitigate any issues with those
who think that running a mail server as "dyn-1-2.home.consumerisp.net"
is just as good as running as "mail01.$mydomain".

Others have advocated putting policy record as TXT directly in IN-ADDR
zone which is ok as well though I think PTR name is better because it
allows to collect related names together and list with one policy
(kind of like common static name schemes in fact).

Perhaps.

>The idea being a common but extensible naming scheme for organisations
>want to specify generic/generated records rather than go to the hassle
>of creating individual records for each customer/host.

If you generate a record you might as well generate some other record
to go along with it, not that difficult.

Except that for every other record you need to touch when you update a
PTR, there's more maintenance overhead and likelihood of error or failure
to do so, so then you end up with out of synch records that people are
relying on for policy decisions, rather than just single out of date
records that people are relying on for policy decisions. <shrug>

Steve

There's at least one vietnamese ISP that has / had till recently set
"localhost" as rDNS for all their IPs.

first... as a draft, it carries ZERO weight. -IF- it becomes an
  RFC, its targeted status in INFORMATIONAL, e.g no standard of any kind.
  So no one is going to -force- you to implement it.

  hum... why does this draft remind me of the (in)famous WKS RR?
  what is WKS? you know, that RR type that specified the "well known services"
  running on/at the particular lable.

  WKS was depricated, in part due to the fact that "black hats" would
  use WKS to groom thair attack profiles. Use of the conventions
  outlined in this draft would be very useful in building targeted
  attacks. To paraphrase Randy Bush, "I encourage all my competition to
  implement these guidelines."

--bill

Matthew Sullivan wrote:

Mark Andrews wrote:

    Actually there can be false positive. ISP's
    who put address blocks into "dialup" blocks
    which have the qualification that the ISP is
    also supposed to only do it if they *don't*
    allow email from the block but the ISP's
    policy explicitly allows email to be sent.
  
Actually that's debatable - the SORBS DUHL is about IPs assigned to hosts/people/machines dynamically. We do not list addresses where the ISP have sent the list explictitly saying 'these are static hosts, but they are not allowed to send mail' - similarly we do list hosts in the DUHL where the ISP has said 'these are dynamic but we allow them to send mail' - it's about the people using the SORBS DUHL for their purposes, not for helping ISPs getting around the issue of whether to use SORBS as a replacement to port 25 blocking.

Regards,

Mat

This point in the thread seems as good as any to toss my two cents in.

Matthew, I use your list. I am very appreciative of the efforts you expend on it since those translate directly into less efforts expended on my part. You have my vote. Keep up the good things that you do.

This goes as well to the other DNSBL's, such as AHBL operators.

I have had no real issues removing systems that wandered "accidentally" into sorbs.

For those who cant tolerate any "false positives" from DNSBL.

I recommend that the whitelisting procedure be as easy as the blacklisting procedure -- that means running a DNSWL. Make it as easy as moving email from one imap folder to another to process whitelisting. Include instructions in your SMTP errors. Educate your support staff.

Joe

Piling on here ...

The effort is to infer the intent of a packet based on ancillary data. The twin dangers here are inference of intent and exposure of the ancillary data.

The first part is like asking "would I want to have security research done by a company on Glenwood Road or on Shady Lane?" (Ya, know "shady" in security.) Legend has it that one research company moved it's location because of this, or maybe it was a joke that came afterwards.

The second part is what ancillary data is exposed. You can require, you can request, or you can assume you won't get the data you need. Sometimes you won't get it because the giver doesn't want the headache of providing it or because the giver is afraid of the ancillary data going to nefarious uses.

My point is that inferring intent based on incomplete data is faulty, but it seems to be useable in real life. However, once heuristics get encoded in deterministic algorithms, the results generally are not so good - mostly because the encoding of the heuristics fails. The answer is to include things like RFC 3514, (Note the pub date.) or ancillary data. But the solution of adding ancillary data maybe worse than the disease. This is just one of the hard problems.

> At LISA a couple of years ago a Microsoftie got up at the SPAM
> symposium and told of an experiment they did where they asked their
> hotmail users to identify their mail messages as spam or not.

<snip>

The recipient is
> the only person who can determine these things.

Sure, but humans aren't perfectly accurate...

Early tests with bayesian classifiers, on the false postive rate, tended to indicate that building a classifier with a lower false postive rate than the humans was pretty easy.

Certainly my own experience is that I occassionaly tag things as junk, or mis-moderate messages to mailing lists. my own false postive rate is probably less than 1% spammassassain's is much lower than that. false negatives however are a reason I sitll have to tag things.

IIRC, that was fpt.vn; they replaced 'localhost' with the incredibly
useful:

adsl-pool-xxx.fpt.vn
adsl-fix-xxx.fpt.vn
dialup-xxx.fpt.vn
adsl-dynamic-pool-xxx.fpt.vn
\d+-\d+-\d+-xxx-dynamic.hcm.fpt.vn
host-\d+-xx.hcm.fpt.vn
\d+-\d+-\d+-xxx-dynamic.hcm.fpt.vn

Yes, the 'xxx's are literals. e.g.,

$ host 210.245.14.143
143.14.245.210.in-addr.arpa domain name pointer dialup-xxx.fpt.vn.

Or it may have been hnpt.com.vn, who replaced it with e.g.,

adsl.hnpt.com.vn

Again, not terribly useful for tracking leakage via NATs.

$ host 203.210.213.149
149.213.210.203.in-addr.arpa domain name pointer adsl.hnpt.com.vn.

But hey, at least they *have* rDNS, I suppose that's something.

I agree that judgements based entirely on rDNS are troublesome. So,
too, are the side effects of chemotherapy. But we're trying to save
the patient before the miracle cures arrive, and right now email is
very, very sick indeed. And rDNS is a useful tool especially in a
scoring-based environment.

There seem to be a couple in the area that do it:

As of 5 minutes ago:

% dig +short -x 203.160.1.3 -x 203.160.1.35
localhost.

inetnum: 203.160.0.0 - 203.160.1.255
netname: VNPT-VNNIC-VN
country: VN

Allan Poindexter wrote:

  > so would you consider as it is my network, that I should
  > not be allowed to impose these 'draconian' methods and
  > perhaps I shouldn't be allowed to censor traffic to and
  > from my networks?

If you want to run a network off in the corner by yourself this is
fine. If you have agreed to participate in the Internet you have an
obligation to deliver your traffic.

In many cases, that is a gross overgeneralization. Do you think anyone really
wanted the Slammer worm, or complained when ISP's blocked it?

I work for a company that is contractually obligated to NOT carry certain
traffic for our clients.

the users got it wrong some small percentage amount of the time. I
was stunned at the arrogance and presumption in that comment. You
can't tell from looking at the contents, source, or destination if
something is spam because none of these things can tell whether the
message was requested or is wanted by the recipient. The recipient is
the only person who can determine these things.

You're right. But... So what?

Perhaps it's because you're seeing things from an academic point of view and
not from a business point of view, but your post mention nothing about
contracts. People generally use DNSBLs without any formal agreement as to
what they should expect. Without any formal agreement, you really can't talk
about "obligations to deliver traffic." In this case, your recourse is to not
use the DNSBL. If you're mailing someone who has a DNSBL, you (as the sender)
have *no* recourse other than to complain to the DNSBL user.

Plus, as I pointed out earlier, some people contract with service providers
to prevent certain traffic from getting to their networks (not just spam,
either).

There are simple solutions to this. They do work in spite of the
moanings of the hand wringers. In the meantime my patience with email
"lost" silently due to blacklists, etc. is growing thin.

You're certainly welcome to encourage others not to use blacklists. Just
understand that you have no right to complain when they decide to continue
using those blacklists.

Having said that, do understand that I don't think DNSBL's are a panacea, nor
are their operators perfect. But in many cases, they can be a useful tool in
the anti-spam arsenal.

Allan Poindexter wrote:

  > There are simple solutions to this. They do work in spite of
  > the moanings of the few who have been mistakenly blocked.

So it is OK so long as we only defame a few people and potentially
ruin their lives?

Weren't you the person complaining about *others* being alarmist?

Steve Sobol wrote:

Allan Poindexter wrote:

> so would you consider as it is my network, that I should
> not be allowed to impose these 'draconian' methods and
> perhaps I shouldn't be allowed to censor traffic to and
> from my networks?

If you want to run a network off in the corner by yourself this is
fine. If you have agreed to participate in the Internet you have an
obligation to deliver your traffic.

In many cases, that is a gross overgeneralization. Do you think anyone really
wanted the Slammer worm, or complained when ISP's blocked it?

I suspect he really means that. The whole game here is maximum dollar for minimum service.

I was pretty much chased off of NANOG some years ago because of my undiplomatic insistence that the SP's had an obligation to block evil traffic (which in those would have been an easier matter than it is today). And yes, I didn't handle the diversionary flame wars and ad hominem attacks very well. Don't bother yourself, anybody, with looking them up.

>You're certainly welcome to encourage others not to use blacklists. Just
>understand that you have no right to complain when they decide to continue
>using those blacklists.
>
>Having said that, do understand that I don't think DNSBL's are a panacea,
>nor are their operators perfect. But in many cases, they can be a useful tool
>in the anti-spam arsenal.

Weighing in with an opinion, as bad as blacklists *may be*, at least
they let the sender know something's up. Not in an artful way, to be
sure, but they give some notice. The sender can do _something_,
including dropping his association with the recipient b/c it's not worth
his time and trouble. Blackholing email because you think it's spam, OTOH,
is pure evil.

Weighing in with an opinion, as bad as blacklists *may be*, at least
they let the sender know something's up. Not in an artful way, to be
sure, but they give some notice. The sender can do _something_,
including dropping his association with the recipient b/c it's not worth
his time and trouble. Blackholing email because you think it's spam, OTOH,
is pure evil.

Host type can only be used as a relatively small weighting factor
toward blocking connections. However in the absence of any other
reputation data on a particular IP, it's a safe way to trigger
throttling or rate limiting.

IMHO receivers have a right to filter traffic in any way that reduces
abuse while serving the needs of their end users. There is a lot of
pressure from end users and legitimate email senders to ensure that
whatever blocking strategy is in use ensures that the good stuff is
not blocked.

Regards,
Ken

Ken Simpson wrote (on Fri, Aug 11, 2006 at 09:09:33AM -0700):

> Weighing in with an opinion, as bad as blacklists *may be*, at least
> they let the sender know something's up. Not in an artful way, to be
> sure, but they give some notice. The sender can do _something_,
> including dropping his association with the recipient b/c it's not worth
> his time and trouble. Blackholing email because you think it's spam, OTOH,
> is pure evil.

Host type can only be used as a relatively small weighting factor
toward blocking connections. However in the absence of any other
reputation data on a particular IP, it's a safe way to trigger
throttling or rate limiting.

IMHO receivers have a right to filter traffic in any way that reduces
abuse while serving the needs of their end users. There is a lot of
pressure from end users and legitimate email senders to ensure that
whatever blocking strategy is in use ensures that the good stuff is
not blocked.

I agree that IP by itself is of limited usefullness. My main point was
that, however you came to your decision ("today I'm not accepting SMTP
from hosts with the number nine in their IP"), you should reject mail
you don't want, not accept it and toss it.

Michael Nicks wrote:

Actually I think this thread progressed from someone getting dirty blocks, to complaining about liberal-listing-RBLs (yes SORBS is one), to RBLs defending themselves and their obviously broken practices. We should not have to jump through hoops to satisfy your requirements.

Best Regards,
-Michael

Again please parse "you" and "your" as being generic and not targeted at
Michael, this is merely a reply. (except in the first series of
interrogatories, nor do I have any evidence
that Michel is currently or has ever hosted anyone who has caused a
listing in the AHBL)

So, we shouldn't enforce _our_ policies on _our_ sites, that _our_ users
agree with and assume that we follow because it's inconvenient for _you_?
Assuming that I follow the rules that I have established, and published
for review for the running of my list, how are my practices broken?
Can I not conceivably list anyone who falls afoul of my listing policies
at any time?
Why should I, someone with years of experience running, maintaining and
defending a DNSBL listen to you who lacks such experience
(to my knowledge) as to how to run my list?
Why should I, with the above mentioned points of experience listen to
you as to how to run my list when your advice is in conflict with the
policies that my list abides by,
and that my uses expect and trust that I follow?
Should I also listen to your thoughts on routing protocols so as to
ensure you are not required to "jump through hoops"?
Perhaps I should consult with you in designing my web site for similar
reasons?
Maybe I should have you review my security so that my network is not
overly burdensome to you?
Or, maybe I should show up at your facilities and start ripping out
patch cables and torching servers and equipment used to provide service
to people who fall afoul of my listing policies.
I really don't think that you'd appreciate that. Therefore your
statement that you should not have to "jump through hoops" is unsupportable.

And believe me when I say this, there's a long list of people on the
Internet that I consider to be idiots, and a large local deny file on my
mailservers for entities
I don't like, or don't want mail from that never make it into the AHBL.
I, and Matthew (to my knowledge) does not bend the rules simply because
it's convenient, or because the idiot deserved it. On the front page of
the AHBL's website is a link in size 4 bold font. "If you were told to
come here to get removed
from our list, please see this page." If you are for some reason
incapable of figuring out how to follow the link, navigating your way to
the lookup page in the subsequent instructions,
and then determining and entering your IP address; then why are you
running a mail server in the first place? Also on our site is our
policies which every volunteer with access to the
AHBL has read and agreed to follow. We also monitor raw incoming
submissions to ensure the volunteers DO follow them. So feel free to
read our policies, and if you like them, feel free
to use our list if it suits your needs. If it does not, please feel
free to direct your opinions to the bitbucket unless you want to come to
me with both a problem and a rational solution, instead of
bitching about how I do volunteer work.

Andrew