Spamgourmet support at Spamcop

[lwc]

I thought this may interest Spamgourmet's powers that be.

So did I get it all right?

So far the suggestion and I ("is he a spammer from Spamgourmet?") were almost lynched. And to think these are the good guys...

[josh]

dude -- I took about 10 minutes and I'm still not sure what that thread is about -- maybe a summary?

For the record, people in control of spamcop *have* been friendly and made special provisions for us, regardless of what those posters may know. This is all in the area of the listing of our server IP address -- is this thread about something different?

[lwc]

Yes, it's not about IP addresses. Just read the original post real well. There are examples. The point is your rules 1)-3) (I admitted later 4) was a mistake) should be undone by Spamcop.

The rest of the posts are mainly nonesense by the newbies there.

[josh]

Wait a minute -- who's spamcop? No doubt a bunch of spammers in disguise, pretending to be cops -- just kidding -- there was a bit of sting for me reading those first few posts after six+ long years of this.

starting to get it -- the problem is that the redirection addresses are showing up in the headers as displayed in the spamcop report? As you know, having a redirection address allows you to send mail to the original address and easily make it look as if it came from the disposable address - it sort of does reveal the disposable address, but you really have to think about it before you can see it. Maybe munging these addresses automatically would require new feature to be implemented at spamcop.

I guess the other risk is that a viewer of the headers would see the redirection address and think the sender was someone at spamgourmet.com, and jump to conclusions and think we're spammers? Maybe. The original sender address will still be in there, though. We've taken enough false accusations over the years that I'm almost numb to them (*almost*).

As for modifying the headers, you probably know that spamgourmet adds to the subject, and modifies the *addresses* if reply address masking is on, but really doesn't do anything else. Passing through spamgourmet builds a part of the headers, like any other mail server hop would, and we add an X- header, but that's normal.

An interesting hypothetical question to ask regarding whether it was permissible to remove post-spamgourmet header entries would be the situation where you have a border email server that you control, as well as an internal email server -- both leave headers, as they should, but does spamcop require that you supply the internal server headers if you report from inside? Seeing as how you could also report from the border server before the internal headers are added, what's the difference if you remove the internal headers afterward? I'm not familiar enough with spamcop to answer that question. And yes, you don't really control spamgourmet, but you sort of do.

Spamcop *is* good about not picking up and listing the spamgourmet server -- wish I could say the same about other reporting services.

Sorry for not jumping over there yet -- I don't think I have an account, I don't know spamcop very well, and I'm maybe still not 100% on the issues.

[lwc]

The most annoying thing was those newbies didn't even bother to enter this site to see what it's about. Maybe they thought it would cause their computers to explode.

There's nothing much to know about Spamcop. It's a service that censors the message-id and all of the addresses except the "from" address (See the problem now? In Spamgourmet this could be the spammer's Spamgourmet's reply masking address and not their original address) and sends the rest of the message to the proper abuse department.
If many complaints are sent about the same IP address (taken from the first legit received line) , it also blacklists that IP address (some ISPs use Spamcop's blacklist).
Finally, it allows you to also send the reports to a curious third party for whatever reason.

In Spamgourmet's case and in your example, the connection is "A to B to C". All the spammer's ISP should know is about "A to B", but Spamcop creates a fake "A to C" report. There's no reason on Earth to expose C.

Now, I guess you leave me no choice but to copy and paste the other rules.

The biggest unjustified privacy problem:

1) This was your example. Basically they tell me "you $%$, don't you dare hide that internal server!"
Like your example, Spamgourmet adds extra lines thus exposing servers the spammer's ISP shouldn't know about.
So I cut every received line until the original "by gourmet.spamgourmet.com".
Speaking of your example, I also tried in vain to give another one - imagine if B likes to forward his messages to C and only then report them. So "B to C" is just his own forwarding. Why including it in the report?

Less minor problems (which why I don't tend to bother undoing them):

2) Being the only uncensored address, "from" is reported as the reply masking address and not as the original address. That just involves Spamgourmet in something it has nothing to do with. You know nothing good can come out of it.
This is where the newbies started shouting the "from" address doesn't matter and wouldn't listen when I kepy saying I never claimed it matters - I just said it shows up in reports and that's a fact whether it matters or not.

3) The subject contains Spamgourmet's personal message. Why on Earth is it the spammer's ISP business?

All of these rules are things the spam didn't contain when it left A and reached B. Thus it makes no sense - and has only bad potential - to report them. And I wanted Spamcop to undo them and report the original "A to B" connection.