more blacklisting woes

Discussion of items in the "What's New" log.

more blacklisting woes

Postby info » Wed Aug 30, 2006 7:12 pm

Another blacklisting problem -- this time at "senderbase" (technically not a blacklist, I suppose, but the problem is the same). See for yourself: http://www.senderbase.org/search?search ... .75.35.164 -- I don't believe there's anything we can do about this (except get really frustrated -- I'm choosing to relax) - if this is a problem for you, 1) stop using senderbase, or get your provider to, 2) get senderbase to fix the problem (if you can do that), or 3) live with it. To all you well-meaning spam reporting spamgourmet users out there -- you're killing us!!!! The bouncing and greylisting puts an extra load on our server (on top of the constant attacks from the *bad* guys) and you're fouling up the service for other users. The new IP address of our server is 216.75.35.164 - stop the reports!!!!!! This has gotten so bad that I will summarily (no warning, no recourse) disable any account that falsely reports our server (if I know about it). This may be the only thing I *can* do about it.
info
Site Admin
 
Posts: 100
Joined: Thu Aug 28, 2003 12:54 pm

Postby Paranoid2000 » Sun Sep 10, 2006 2:47 am

What exactly is the problem? Senderbase reports email volumes rather than operating a blocklist (and it currently reports that SG is not on any blocklists).

SpamCop is a more likely cause of blocklisting since it includes user-submitted emails so any SG user incorrectly submitting an email should be dealt with. They should also be reported to SpamCop for breaking their rules - free accounts are then suspended while paid accounts are fined.
Paranoid2000
 
Posts: 71
Joined: Wed Dec 15, 2004 10:48 am

Postby josh » Sun Sep 10, 2006 1:56 pm

I'm not sure what the problem is -- but some servers are rejecting or greylisting spamgourmet, and providing a link to senderbase in the error messages.

Spamcop has whitelisted the new server, and I'm not aware of any reports going there. I'm looking for reports to other services.

Josh
josh
 
Posts: 1371
Joined: Fri Aug 29, 2003 2:28 pm

Re: more blacklisting woes

Postby Paranoid2000 » Tue Sep 19, 2006 8:05 am

info wrote:The new IP address of our server is 216.75.35.164 - stop the reports!!!!!! This has gotten so bad that I will summarily (no warning, no recourse) disable any account that falsely reports our server (if I know about it). This may be the only thing I *can* do about it.
I notice now that SpamGourmet includes the headers from the actual email server used, presumably to prevent future blacklisting. Although it does not reveal the real email address used, it does now show the real domain which may be worth noting for some users (those running their own email servers notably).

While I sympathise with the problems caused, rather than terminating accounts for one slipup (which could have major consequences for long-time users with dozens or hundreds of aliases) how about imposing a fine via a compulsory donation? Having the account disabled until, say US$20-50 is paid (with the option of doubling for every recurrence) should be a strong deterrent.
Paranoid2000
 
Posts: 71
Joined: Wed Dec 15, 2004 10:48 am

Postby josh » Thu Sep 21, 2006 12:02 pm

The truth is that now it's pretty much like you're describing, but without the fine -- if the person can convince us that it won't happen again, that's really good enough.

As for the headers, we've always done that. Initially, we did it because we noticed that several state laws criminalize the modification of email headers -- these laws are clearly intended to hurt spammers, but, like most tech-related laws, they're not perfectly drafted. We realized we'd be shutting down in short order if we got caught up in a criminal charge, even if logic prevailed in the resulting proceeding.

Further, the possibility that a SG user would do something fraudulent, etc., seemed worthy of consideration -- leaving the original headers gives us a "get out of conflict free" card that prevents us from having to divulge our database and server logs. We have avoided prolonged involvement with lawyers, the German police, and, yes, the U.S. Department of Homeland Security this way. Getting caught up in situations like this would dramatically increase the cost of providing the service, and would probably lead to a shut-down, as well.

Including the headers didn't bug anyone too much, because a) sg is not an "anonymizer", and b) we operate on the pricinple that spammers deal in bulk, and can't be bothered to expend energy to find an email address when there are so many that are readily available (including the disposable address in the "From:" line). So far, we believe this has rung true.

Later, we became aware of another reason to preserve the headers (the one you're describing) - we made a version of the code that used a standard Perl module for mail processing, tested it heavily (but never looked at the headers) and then deployed it. We were blacklisted with extreme prejudice within hours - the module was "re-originating" the messages by removing the prior server header info. That was a mess, and resulted in a much more comprehensive black-out that we've seen since.
josh
 
Posts: 1371
Joined: Fri Aug 29, 2003 2:28 pm


Return to What's New

Who is online

Users browsing this forum: No registered users and 3 guests

cron