[SpamCop-List] Re: Return Codes ?!?

[Mike Easter]

HOLLO Peter Mr. (ICM Rt.) wrote:

> You recommended me Bayesian filtering that is better than RBL and

This par is about Michael Brennan's discussion points, not mine, which
you have already cleared up for yourself.

> I try to write about my problem in a clear way with samples, ok ?

I'll characterize your pars and reply inline.

> There are 4-5 big ISPs in Hungary (it is probably not the same
> situation in bigger countries), and few other bigger ISPs in
> countries where we have contacts.

This par describes how you need to get goodmails from various .hu
providers.

> You wanted samples: I am sorry, I didn't want you make bored with
> samples,

Samples are much faster;  less describing.  More perfect facts.

> invitel.hu
> datanet.hu
> t-online.hu
> euroweb.hu
> pantel.hu

Some .hu ISPs.

> And they have subcompanies who have no private SMTP servers (or they
> have it only for internally with no DNS direct sending):

> CMA.HU using Datanet's MX2 SMTP gateway called mx2.datanet.hu at
> 194.149.13.162

Got it.

> Last week for few hours mx2.datanet.hu went to their blacklist

I cannot confirm if something was on the SC list in the past, only a
deputy can do that.  But it is true that sometimes servers get on the
SCbl.

> 2005.10.11. 14:19:42  Action: Spam List Block  Client: 194.149.13.162
> From: x.y at cma.hu
> To: @icm.hu, @icm.hu  Subject: ......  Matching List: bl.spamcop.net
> Size: 3647479  SMTP ID: M2005101114182705925  Info: Message was
> relayed from a machine that is in a spam list.

I understand cma.hu using the datanet.hu server and I understand that if
it were listed, the item would be 'blocked' or tagged as spam.

<Follows 3 more examples of addresses using that server as examples>

> This week it happend to invitel.hu mx server.
> That means we lose all @invitel.hu mails on 62.77.203.3
> c.relay.invitel.hu, but for example we lose: @szentgaal.hu  just
> because a whole RIPE subnet were blacklisted at SPAMHAUS including
> @szentgaal.hu at 62.77.203.4 b.relay.invitel.hu  and the same happens
> to c.relay.invitel.hu , d.relay.invitel.hu etc. It is not a good idea
> to organize all relay under one /24 subnet, but they might have other
> subnets, I didn't check.

I cannot confirm past history at spamhaus.  That IP is not currently
spamhaus listed.  In fact I can lookup .hu ISPs at spamhaus and I can
lookup invitel.hu and spamhaus only shows a single invitel IP listed

SBL32730 = 213.163.39.180/32 is listed on the Spamhaus Block List (SBL)

That spamhaus listing of invitel is for a paypal phisher
mail.american.hu.  If the .hu IP is getting itself listed for providing
for paypal phishers and your clients are using the same server, your
partners or clients are going to get mail delivery problems.

In my opinion, these 'overlappings' of spam and scam with legitimate
enterprise may be a different problem in some countries than others -
but it can happen in any country.

If your clients are changing from week to week, and those unknown
goodmail clients are sharing servers with spam and scam, then someone is
going to have to have a method of whitelisting or to switch over to a
nonblocklisted system.

> So, here you are the examples you wanted.

Except none of the example are currently listed, so I don't know if
something is making a mistake.  As a general rule, SC is designed to not
list servers unless they are doing something abusive.  And as a general
rule, spamhaus is a rather conservative lister.  SC doesn't list blocks.
Spamhaus doesn't list blocks without good cause.

> I could show many other false positives happened because of
> blacklisting the MX servers at big ISPs, no matter of the content of
> the mail.

So far none of your examples show a current listing of a server at a big
ISP.

> You wrote "zero spam arrives via open relays".

I qualified that, or meant to.  Once upon a time, open smtp relays were
a big source of spam.  Nowadays I don't often see, I rarely see, a spam
coming from an open smtp relay.  I see tons of spam coming from an
'open' proxy or trojan user IP.

> That is probably true (But I would not try to remove relaychecking on
> my mailserver !!!)

If a relay were to be open, it would probably be promptly exploited.

> My other question:
> OK, we are a small company.
> I check few (I don't know how much % of all) RBL servers concerning
> our listings, and we have all possible internal solution to prevent
> getting infected by anythinand we also doN't have open gates on SMTP
> server.

I think anyone who is running a mailserver should be very aware of what
blocklist they might get on and most importantly what is cause them to
get on a list so that they can permanently eliminate the cause so as to
stay off blocklists all the time.  It should not be happening that you
are getting on a blocklists.  Blocklists list for a reason.  You don't
want to be causing that reason, unless it is simply because you are .hu.

> If I accidentally find ourselves listed, I contact them for removal,
> but it effect probably no mail at our organization.

There are many blocklists for which it is exceedingly difficult to be
removed.

Some blocklists will 'always' remove an IP just by using its online
gizmo.  Some blocklists will not remove no matter what you say.  Spamcop
automatically removes when the spam stops, but won't remove before that
unless some kind of mistake has been made.

When you say "I accidentally find ourselves listed" - I don't know what
that means.  In the case of spamcop, when SC makes a report, it is
notifying someone about the spams, except spamtraps.  You should put
yourself in a situation where you are notified about the kinds of things
which cause you to be listed.  That notification should cause you to
eliminate the cause of the listing.

> But what shall ISP's do who have maybe 100 mx SMTP servers and few
> hundreds of domain names within their clients ?

Not allow spamming or other abusive mail.

> Plus few thousands of xDSL and MODEM users behind their DHCP related
> RIPE subnets ?

Not allow insecurities in their networks.

> How many RBL servers they shall check a day ?

It only takes a few seconds to check 'all' of them.

> I am asking this becasue I am (the manager of SMTP servers) can freely
> decide which to use, so if they want to be sure that their mails are
> unfiltered at targets, they have to check all !!!!!

Not only check all, but remedy the causes of listings on any of them.
That is how to be a responsible provider.

> I think only that way would work, where the sender can be
> back-identified when then mail is sent.

The server has logs of things that pass thru' the server.  If there is a
user IP on a network which is insecure, that can be determined as well.
Spamcop provides evidence of the spam except for spamtrapsl

> So the result is they can even be the reason that the mentioned
> 194.149.13.162 mx2.datanet.hu had been SPAMCOPPED.
> Many recipients might have reported the spam they received from their
> source and from their domain, so finally the mx2.datanet.hu went to
> blacklist.

If you spam, you get blocklisted;  if you get blocklisted people have
mail trouble.  People who have mail trouble are going to get a different
provider.  These are the things which fix spam.

Blocklists are doing some good services even when there are false
positives.


-- 
Mike Easter
kibitzer, not SC admin