Jump to content

"AUTO" Reporting via Email, preferences


sfatula

Recommended Posts

So, I have read a lot of messages and not sure I get it yet. Read various FAQs, still not certain.

Here is what it boils down to. I am intending to report spam to my domains email accounts to Spamcop. We host our own email servers. So, there is a preference settings I am still not clear on. It is the spam Munging option.

So, here is what I THINK happens based on various threads:

Obscure - This will always be used to add more blocks, it may not be sent to an ISP if the ISP does not accept munged reports. I believe spammer could still figure out the reporting email and therefore there is some risk of retaliation.

Leave Intact - These always go to the ISP and definite risk of attack, always counted

Mole - These are never used to add more blocks.

So, presuming we have an email folder where we move clearly spam messages read by human eyes, and, that folder sends those emails to SPAMCOP to our reporting address, do the above preferences affect the report that are sent out?

The goal of reporting is to make sure new IPs get added to the block list if necessary.

So, do I understand the preferences correctly, and, is it useful to report for these purposes? I have checked various mail servers we get spam from, and, they are not all on the block lists.

Is it wise to send leave intact reports?

Link to comment
Share on other sites

IMHO, spammers do not attempt retaliation any more against individual reporters. They are too busy adding names to their lists and creating botnets to bother. There are too many reporters to single one out.

However, that's just an opinion. A fact is that if you are getting spam, the spammer already has your email address and if you have a domain, plus all those on his list that he has combined with your domain name.

If you only send reports to the source IP address, you are unlikely to be sending reports to the spammer. I think spamcop does try to not send reports to known spammer abuse addresses - not completely guaranteed, of course. However, many spammers do not accept spamcop reports anyway.

There have been a couple of attempts to scientifically document whether munging makes any kind of impact on spam count. However, while it may increase spam (because the idiots add every address in the report to their lists), it doesn't seem to really affect much in the long run. If some spammers remove a reporting address, others add it so the count isn't affected much over all.

Mole reporting does not put any spammer on the blocklist. Both munged and unmunged reports are counted toward the bl for the source (where the email came from), but not for the spamvertised sites in the body of the email.

However, if the IP addresses of the spam are not now on the spamcop bl, they may not be added just because you start reporting. It takes reports from two reporters. Did you look at other blocklists? Some of the rotating ones don't get listed by spamcop, but appear on more conservative lists. I am assuming that you know how to read headers so that you have chosen the proper IP address or have run them through the parser to get the proper IP address.

HTH

Miss Betsy

Link to comment
Share on other sites

However, if the IP addresses of the spam are not now on the spamcop bl, they may not be added just because you start reporting. It takes reports from two reporters. Did you look at other blocklists? Some of the rotating ones don't get listed by spamcop, but appear on more conservative lists. I am assuming that you know how to read headers so that you have chosen the proper IP address or have run them through the parser to get the proper IP address.

Yes, I would HOPE just because I report and no one else does, it would not be added. Of course. Yes, I have reviewed a ton of blacklists via various tools. Half of the spam I have received in the last 4 weeks are from addresses only found on FIVETEN. FIVETEN, according to reports all over the place, blocks more good mail than bad, so, don't want to use them.

I do just want to participate in the efforts to block spam though. The spam almost never makes it into our inboxes, >99.99% are properly filtered. So, it's more just wanting to help out.

Link to comment
Share on other sites

...I do just want to participate in the efforts to block spam though. The spam almost never makes it into our inboxes, >99.99% are properly filtered. So, it's more just wanting to help out.
Thanks Steve, yes your efforts will make a difference but, as you appreciate, not a direct one-to-one difference, more an 'adding to the weight of evidence' difference. The official word on the working of SCBL listing is at http://www.spamcop.net/fom-serve/cache/297.html as you've probably seen.

The general consensus (as Miss Betsy has said) is that 'unmunged' reports are not a significant risk and will serve to alert more admins with compromised systems in their networks - but won't affect the SCBL listing. As you also appreciate, munging is anyway a notionally flimsy 'defence', taking the fully paranoid view, so it's probably a 'may as well be hung for a sheep as for a lamb' situation, though that particular expression seriously overdramatizes it - they've already got your addresses in any event. As always, risk has to be considered as a matter of [probability x consequence], so your 'numbers' there will be a little different from those of a reporter with a single address to consider (but only ordinary resources). Mole reporting is totally safe but has correspondingly little effect on the BL - just affects reputuation points IIUC.

You're maybe being nudged in a certain direction by 'advisors' with no responsibility for the outcome - well, this discussion has reminded me to set my own reporting preferences in 'Report Handling Options' to 'Leave spam copies intact' under 'spam Munging', which I've been meaning to do for some time :D .

Link to comment
Share on other sites

The general consensus (as Miss Betsy has said) is that 'unmunged' reports are not a significant risk and will serve to alert more admins with compromised systems in their networks - but won't affect the SCBL listing.

Ok, so, why would it not affect the SCBL? It should count, right, and therefore, possibly affect the SCBL? The same would be true of munged, or unmunged, right?

Link to comment
Share on other sites

Ok, so, why would it not affect the SCBL? It should count, right, and therefore, possibly affect the SCBL? The same would be true of munged, or unmunged, right?

Farelf provided a link, that data also exists within the SpamCop FAQ and the SpamCop Wiki as found 'here' .... the basic title is What's on the Blocking List? That list is based on a ration of good/bad (though actually reported/un-reported) traffic seen coming from an IP Address.

The munging options in your Preferences is targeted to attempting to remove identifiable/personal data from the parser results/Report. There is no connection there to the IP Addresses in use .... the background 'here' is that IP Addresses are not considered personal/private data.

Mole Reporting is something else entirely, and when the man involved with writing the code adds into the definition what's the use? ....???? Basically, all it does is add to some statistics that can then be seen by some ISP Accounts in a Summary Data result (usually complained about because there is no specific detail offered) and the Deputies, useful in making some decisions about the addresses and folks involved with the actions or inactions taken in response to Reports.

Link to comment
Share on other sites

Farelf provided a link, that data also exists within the SpamCop FAQ and the SpamCop Wiki as found 'here' .... the basic title is What's on the Blocking List? That list is based on a ration of good/bad (though actually reported/un-reported) traffic seen coming from an IP Address.

So, the bottom line is, it affects the SCBL if you report, unless you are mole reporting (though in some way it is possible that might also). I did read that FAQ, and the way I read it, reporting does do something.

I simply was unclear as to why he said does not affect the SCBL. Perhaps he meant munged vs unmunged makes no difference.

Link to comment
Share on other sites

So, the bottom line is, it affects the SCBL if you report, unless you are mole reporting (though in some way it is possible that might also). I did read that FAQ, and the way I read it, reporting does do something.

Again, the 'only something' that Mole Reporting does is to add to a statistical portion of the database in use ... ISP Account holders can ask for a Summary Report which lists the numbers and types of Reports made against an IP Address or Spamvertised URL ... Only the Deputies have access to the actual contents of that database.

I simply was unclear as to why he said does not affect the SCBL. Perhaps he meant munged vs unmunged makes no difference.

Yes, again, both munged and un-munged reports add to the 'traffic' statistics against an IP Address and spamvertised URLs .. only the IP Addresses are involved with a listing on the SpamCopDNSBL ... and again, Mole Reports do not contribute to the math involved in getting listed/un-listed in this BL.

Link to comment
Share on other sites

Hi sfatula!

Welcome along.

That you are asking questions and attempting to understand the spam reporting process is great! If only others would do the same.

I see the subject of this topic is: '"AUTO" Reporting via Email, preferences'

Can I suggest that you get to grips with manual reporting before you leap into some automated approach you have in mind? There are lots of things that can go wrong for new reporters and sorting those out using manual reports first is a great way both or learning and ensuring you do not misreport.

Also, please note that new reporters do not have the ability to use the Quick Reporting service. So, initially at least, reporting is a two stage process. You send the reports then you have to return in a few moments and confirm each report. This ensures that you only report spam that is confirmed.

Once you have built up confidence and accuracy you can ask for Quick Reporting privileges. But you really need to be sure that you aren't reporting your own servers or legitimate Email.

For me, Auto Reporting rings some warning alarm bells.

Please note, too, that these forums are almost entirely served by otehr SC users. The owners of the SpamCop blocklist and associated reporting system are largely absent here except for one staff member who visits from time to time and who will happily help you out if needed.

So, welcome along, your reports are welcome but please take things forward carefully and cautiously. Thanks, indeed, for attempting to be fully informed. Much appreciated.

Andrew

Link to comment
Share on other sites

So, the bottom line is, it affects the SCBL if you report, unless you are mole reporting (though in some way it is possible that might also). I did read that FAQ, and the way I read it, reporting does do something.

I simply was unclear as to why he said does not affect the SCBL. Perhaps he meant munged vs unmunged makes no difference.

The SCBL is constructed using data from reporters reporting spam - munged or unmunged - and contains only the IP addresses that actually sent the spam. It does not contain the IP addresses of URLs found in the body of the spam. The SCBL is also fed by spam traps (that do not send reports).

Mole reporting simply adds to a statistical database (as explained by some other poster). It does not feed the SCBL. No one gets a 'report' except as an aggregate so it does neither of the things spamcop does really well.

One value of reporting via spamcop is that the SCBL identifies the IP address of the source of spam while it is spewing spam and since the SCBL is considered aggressive, the IP address may not be on other blocklists yet. I don't know how you filter spam, but I understand that other server admins use the SCBL in conjunction with other bls. (I am not a server admin)

The other value is that, occasionally, it alerts a responsible server admin to a spam leak - most often nowadays alerting someone to an infected computer, but still sometimes to a mistake. If the server admin is responsible, the problem can be fixed before the IP address gets on more conservative blocklists. Since the SCBL is automatic - once the spam stops, the SCBL no longer lists the IP address, reporting to someone who actually pays attention, helps them from having to contact a bunch of bls.

Spamcop is a tool. Like a calculator, one needs to know how to add and subtract so that one can recognize a 'wrong' result. Once you understand how the parser works, know what to look for if something gets off track, then you can do QuickReporting. There is no need to reinvent the wheel - if that's what the AUTO in the subject means.

Miss Betsy

Link to comment
Share on other sites

AUTO = not as auto as you all are thinking! I just mean not having to hit forward with attachment, then change the sender, then, put in the send to address, then hit send, then delete the message...

Instead, users move to a folder, and, done. It gets emailed and I (only) approve them. Quite cautious. So, do not worry!

Thanks for all the help

Link to comment
Share on other sites

AUTO = not as auto as you all are thinking! I just mean not having to hit forward with attachment, then change the sender, then, put in the send to address, then hit send, then delete the message...

Instead, users move to a folder, and, done. It gets emailed and I (only) approve them. Quite cautious. So, do not worry!

Thanks for all the help

Just be careful as many people have gotten stuck at the "forward as attachment automatically" step.

Link to comment
Share on other sites

Just be careful as many people have gotten stuck at the "forward as attachment automatically" step.

Not sure what you mean, seems to work fine. They move to folder, scri_pt picks it up hourly and mails it. Works great thus far. I suppose you just mean some have problems getting it to work? Well, we do shell scripts! In fact, it worked first try.

Or, do you mean something else?

Link to comment
Share on other sites

Not sure what you mean, seems to work fine. They move to folder, scri_pt picks it up hourly and mails it. Works great thus far. I suppose you just mean some have problems getting it to work? Well, we do shell scripts! In fact, it worked first try.

Or, do you mean something else?

I mean, people start forwarding as attachment manually and it works, then they switch to their auto mode and the forward is no longer "as attachment", which leads to a "No IP found" because there is no attachment to parse. If that is working for you, great.

We have seen that problem many times over the years.

Link to comment
Share on other sites

...It gets emailed and I (only) approve them. ...
That's the other stumbling block for some - they email the submission but don't approve/report to complete the process (doesn't apply to quick reporting). You have that under control. There is an age consideration when it comes to IP address listing in the SCBL (per the FAQ). My advice would be don't wear yourself out trying to always report everything at the earliest possible moment. If you have an hourly schedule that is great but don't become a slave to it (sounds like you're talking potentially considerable volumes). You can always switch to quick reporting once you are confident the parsing is always 'interpreting' your headers correctly.
Link to comment
Share on other sites

You guys are all too nice here. Thanks for all the tips! No, not high volume. Even if it was, I would take my time to make sure all is perfect first anyway for low volume.

Right now, we have our own block list that we maintained. I am going through it and removing blocks on those sites/ranges that are in various RBLs that we use. Then I will remove a few more just to get some spam, assuming they are still sending spam. Which is the problem with your own block lists, we don't know if the problem was resolved or not. Hopefully, in the end, we'll eliminate our own block list. Maybe that is not possible though for some hosts that send a *lot* of spam, we shall see.

Link to comment
Share on other sites

You guys are all too nice here. Thanks for all the tips! No, not high volume. Even if it was, I would take my time to make sure all is perfect first anyway for low volume.

Right now, we have our own block list that we maintained. I am going through it and removing blocks on those sites/ranges that are in various RBLs that we use. Then I will remove a few more just to get some spam, assuming they are still sending spam. Which is the problem with your own block lists, we don't know if the problem was resolved or not. Hopefully, in the end, we'll eliminate our own block list. Maybe that is not possible though for some hosts that send a *lot* of spam, we shall see.

It sounds to me like you're making a rod for your own back here... You can automate the initial submission of reports but the manual handling of spam will easily mount up to thousands of messages each day.

Also, how can you be sure that the messages trapped and submitted by your sc_ript are only spam? Your rely on a BL to catch a message but there's no guarantee that the message really is spam.

Personally I have found that the best reporting strategy, to avoid misreporting, is to:

1. Employ grey-listing - this stops most spam dead

2. Block against a few selected RBLs - discard failures

3. Filter based on SpamAssassin. I use a fairly open (by comparison to some other reporters) SA setting. I put SA as a third level check to reduce the server load filtering on message content. Discard failures.

4. Report only that mail that gets past these first three checks.

I can cope with the relatively small volumes of spam that reach stage 4. Previously I tried to report everything (and didn't use grey-listing) and not only did it eventually become too much, I found myself making regular mistakes and would start reporting an item that wasn't spam. Of course, catching the problem I was able to stop the report but it did become onerous and very time consuming.

Andrew

Link to comment
Share on other sites

I thought I specified this earlier in the thread, but, we already do the appropriate spam stuff. None of the spam we get actually makes it to our inbox, our filtering techniques work with >99.99% accuracy (ok, someone gets a real spam here and there in their inbox, but it is enormously rare). They go into a spam folder. It is that spam folder that is then manually reviewed and moved to the report folder, in most cases, the manual review process is trivial as you can tell by the subjects they are so obvious, so no time waste here really. It's very simple and we are doing that. only to report it and maybe make a difference. We don't have an issue with actually getting spam in our inbox, except very very rarely.

I want to report spam that makes it through the SMTP checks and RBLs that we use. I don't want them consuming bandwidth, so, I'd like someone to fix their server or be blacklisted. We do not get thousands of messages per day through our SMTP level filtering. So, much smaller than your problem apparently.

We found SpamAssassin too slow and use a few products, the most effective of which is dspam. It had a much higher percentage of detecting spam for us, after the training period than we ever got out of SpamAssassin.

Link to comment
Share on other sites

What you seem to be doing (auto-submitting) is asked for occasionally here. When you have it fully running, if you could provide an explanation of your systems and provide your scri_pt (or a sample one if there is anything specific you would not want to divulge), that would be appreciated.

It would probably need to be included here with a strong warning as to false reporting.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...