You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Charles Gregory <cg...@hwcn.org> on 2009/06/24 16:24:34 UTC

Re: [sa] Re: SORBS bites the dust

On Wed, 24 Jun 2009, Matus UHLAR - fantomas wrote:
>> somewhat hesitant to use spamcop as our own servers once had a brief
>> listing with them (and it wasn't due to spam).
> Got more info?

Sadly, we're dealing with my aging memory. :)

While I cannot remember precisely, categorically it was a situation like:
1) A piece of junk that one of our users had forwarded to another server
    and then THE USER 'reported' the spam (which naturally had *our* IP at
    the top), or,
2) Someone 'reported as spam' a bounce from our server that had their
    address forged as sender (for some condition like 'full mailbox' which
    even now still sometimes generates a DSN rather than being rejected at
    the SMTP gateway).

Admittedly we've made massive improvements to our systems since that time. 
We now filter at SMTP time, rather than have the filter in procmail which 
is bypassed by .forward, and I've put in extra mechanisms to catch as many 
of the 'full mailbox' type of conditions as possible at SMTP time.

But whichever the case was, it still bothered me that this major 
blocklist seemed to have added our IP for a singular incident/report.
I would expect there to be a minimal threshold for accidental or false 
reporting.

Mind you, there is every chance that spamcop has upgraded their systems in 
the intervening years. All I have to go on is my experience. :)

Anyways, there's what 'info' I have. I won't be surprised if it's not 
'good enough' for anyone. If someone knows something improvements to their 
spam reporting, I would be interested..... Thanks.

- Charles

Re: [sa] Re: SORBS bites the dust

Posted by mouss <mo...@ml.netoyen.net>.
Charles Gregory a écrit :
> On Wed, 24 Jun 2009, Matus UHLAR - fantomas wrote:
>>> somewhat hesitant to use spamcop as our own servers once had a brief
>>> listing with them (and it wasn't due to spam).
>> Got more info?
> 
> Sadly, we're dealing with my aging memory. :)
> 
> While I cannot remember precisely, categorically it was a situation like:
> 1) A piece of junk that one of our users had forwarded to another server
>    and then THE USER 'reported' the spam (which naturally had *our* IP at
>    the top), or,
> 2) Someone 'reported as spam' a bounce from our server that had their
>    address forged as sender (for some condition like 'full mailbox' which
>    even now still sometimes generates a DSN rather than being rejected at
>    the SMTP gateway).
> 


neither of these will et you listed on zen. zen is composed of

- pbl: these are IPs that are not supposed to send mail. this is either
decided by the ISP (then if you're listed, you know to whom to complain)
or by spamhaus (this is when the ISP doesn't want to tell which IPs are
"dynamic/residential/...").

- sbl: these are "confirmed" spammers. you don't end up here as a result
of a misconfiguration.

- xbl (cbl, njabl-proxy): these are "infected" boxes.


you may get listed on spamcop though, but such a listing expires
automatically unless the conditions are repeated. and I don't consider
such a listing to be an FP.

> Admittedly we've made massive improvements to our systems since that
> time. We now filter at SMTP time, rather than have the filter in
> procmail which is bypassed by .forward, and I've put in extra mechanisms
> to catch as many of the 'full mailbox' type of conditions as possible at
> SMTP time.
> 
> But whichever the case was, it still bothered me that this major
> blocklist seemed to have added our IP for a singular incident/report.
> I would expect there to be a minimal threshold for accidental or false
> reporting.
> 

if you talk about spamcop or cbl, you really need to reread how they
work. it is good even for you that they list you if they detect bad
behaviour. this gives you a chance to fix the problem. (I had this with
one IP, that I finally decided to block myself).

> Mind you, there is every chance that spamcop has upgraded their systems
> in the intervening years. All I have to go on is my experience. :)
> 

spamcop has changed few years ago (3 years?). so if you're talking about
an old incident, then it's no more relevant.

> Anyways, there's what 'info' I have. I won't be surprised if it's not
> 'good enough' for anyone. If someone knows something improvements to
> their spam reporting, I would be interested..... Thanks.
> 

I don't use spamcop at smtp level, because I know they block some
networks I want mail from, but the block is understandable (large
university where one of the internal dept has its own relay, which can't
be disabled for now, and which has a bogus list mgmt software that can't
yet be kicked off. in short, the block is bad for the university in the
short run, but it gives an argument to disable those old setups, which
is the way to go).