Re: Menubar Spamcopped

[Ross Golder <ross golder org>]

On พฤ., 2005-06-16 at 22:38 +0300, Toni Willberg wrote:
> On Thu, 2005-06-16 at 22:15 +0700, Ross Golder wrote:
> > We probably ought to find out how to get the following information
> > updated:
> > 
> > http://www.spamcop.net/sc?track=12.107.209.248
> > 
> > And find a way to get de-listed, and prevent any further listings, if
> > possible.
> > 
> 
> I requested automatic de-listing. The confirmation mail was sent to the
> authorative contact "sbranden redhat com", he should reply to the mail
> to get us delisted quickly.
> 

I'm copying in 'sbranden redhat com' for his/her information.

> Otherwise the list should be cleared in 24 hours after last report, or
> so.
> 

And if whoever is reporting us keeps reporting us? I think we ought to
get the reporting address updated to make 'gnome-sysadmin gnome org', or
'mailman gnome org', or 'gnome-listadmin gnome org' or one of our many
aliases the POC for menubar spam issues. Does anyone know how we would
do that?

> I believe it's not possible to prevent further listings as we don't know
> the real cause for this one. I guess that someone (usually more then one
> person) had reported spam received via our mailing lists, causing the
> listing.
> 

Almost certainly, but which list, which subscriber? If we could see the
reports that SpamCop is sending to 'sbranden redhat com', we could
identify the cause of the reports/listings and take some action to
prevent them.

> Being listed at bl.spamcop.net isn't normally a big problem, but it
> seems that some admins who can't read instructions have set up their
> mail servers to actually block mail based on spamcop's black list,
> causing tons of bounces.
> 

I've set up SMTP-level blocking based on spamcop's list before in a
couple of cases. In one case, the mail server just didn't have the
resources to run SpamAssassin so the IP-level blocking needed to be
unusually extreme.

IMHO, RBL false positives aren't that bad. If I have to use RBL S (other
than open proxy/relay lists) to reject connections, I make it reject
with a temporary failure (e.g. postfix 'maps_rbl_reject_code = 421'). If
a well-behaved legitimate server gets listed, it will periodically retry
until it becomes delisted. Non-legitimate MTAs, or MTAs whose admins
don't take their spam reports seriously will inevitably fail to get
their mail through. Unfortunately, in cases like this, if the MTA admins
aren't even getting their spam reports, things aren't quite as rosy :)

--
Ross