Constantly receiving spam/apparently of same origin

[db17]

Could be I don't completely understand how getting someone who is hosting spam to stop or getting them shut down.

These two constantly appear in spam processing, and have been reported on numerous occasions, but they keep coming back relentlessly. When I do a search for ladislav.kendik[at]cityofprague.cz, it appears to be the name of some legitimate city office holder, so don't understand the function in spamming, unless the address is spoofed. Since I'm sure I must not be the only one, does this mean there are no legal steps or otherwise to shut this down? What does anyone know about these?

ladislav.kendik[at]cityofprague.cz

postmaster[at]conware.de

http://i57.tinypic.com/e7me77.png

[Farelf]

Part of the puzzle is that it takes more than one reporter's efforts to get an IP address on the list - see https://www.spamcop.net/fom-serve/cache/297.html

Next the list is based on IP addresses and this spammer is changing the originating IP address constantly.

Possibly good news - "spamvertized" websites are handled by SC only to the extent of sending courtesy reports to the host networks (who mostly don't want to know anyway) BUT the SURBL takes part of its feed for those from SC. Check that to see if the stuff you're reporting has been listed there.

Listing in the SCbl or SURBL isn't going to shut down the spammers overnight - but it allows individual spamsufferers and entire networks to block them and presumably impacts their profitability.

[db17]

Thanks for the info. None of the 4 IPs in that screenshot are being blocked by SURBL. This idea won't help to get these spammers shut down or blacklisted at SURBL, but since all this spam is orginating from an IP range of 153.92.194.0 - 153.92.194.255, I am looking into some way of blocking that entire incoming range at my router, Shibby Tomato, from the Dnsmasq page. Doing this from the router will keep this garbage off my network and clients entirely. I don't run my own email server, so using SC's blacklist won't work. And no way to block IPs or an entire IP range at my ISP mail server.

Or, if you know of some other way?

[Farelf]

Just to be clear, there is only one IP address for the one spamvertized web site - ilgrandecomunicatore.com = 193.86.21.118 But you are right - it is not listed, nor is the domain. Again, I think it may be that a certain incidence is required to list. ("Source" is the IP address of the origin of the e-mail conveying those irresistible offers to you.)

IP A/Domain are not listed in The URIBL either but there one can register and request listing - I'm fairly sure there's some distance between an individual request and listing though, to guard against the games people play.

Oh well ...

[Farelf]

Or, if you know of some other way?

Oh, there are "end user" solutions to using RBLs and other selective blocks. (Some) people here are always raving about Mailwasher. Just don't EVER use the "fake bounce" feature which used to be configured as a default selection for spam "handling" by that product, maybe still is. If you do, we shall collectively hunt you down and castigate you so comprehensively that any thought of future gene dilution on your part would remain forever an impossible dream.

Or there are are other "consumer level" filters like http://wiki.spamihilator.com/doku.php and http://keir.net/k9.html - you would need to do some homework to see whether those can be configured to your installations and see whether their features suit you.

[db17]

Just to be clear, there is only one IP address for the one spamvertized web site - ilgrandecomunicatore.com = 193.86.21.118 But you are right - it is not listed, nor is the domain. Again, I think it may be that a certain incidence is required to list. ("Source" is the IP address of the origin of the e-mail conveying those irresistible offers to you.)

IP A/Domain are not listed in The URIBL either but there one can register and request listing - I'm fairly sure there's some distance between an individual request and listing though, to guard against the games people play.

Oh well ...

Thanks again. So, seems I need a bit of education about reading spam reports: can you please explain why I disregard any of the listed 153.92.194.xxx, which are shown in the raw headers, as well as in the SC spam reports, and use 193.86.21.118 instead. In fact, how did you find 193.86.21.118? I'm not seeing that anywhere in the raw headers, or in any of the SC spam reports. And when I do a Whois for the that IP, it comes up with "no host name." Is it safe to assume that that domain name ilgrandecomunicatore.com is completely faked? Apparently, if I try blocking conware.de or any 153.92.194.xxx, that won't do the trick.

And can you also please explain why all four of these spam messages (and many more I've gotten) show conware.de and ladislav.kendik[at]cityofprague.cz? What are all those doing there?

And if the originating IP, in this case 193.86.21.118, is constantly changing, or doesn't remain within a certain IP range, does it seem likely that it would be impossible to block by IP?

And thanks for the tip about Mailwasher. Unfortunately, can't use it as I'm running OSX/Mac. The Mac bayesian junk mail filter works quite well, but problem is it's only on the one Mac and nowhere to be seen on the iPad. So best soution is to accomplish all blocking at the WAN source, at the router.

[Farelf]

SC, in that graphic of your Past Reports, was offering to send them to the network/DNS owners of the spamvertized websites at ilgrandecomunicatore.com which DNS records presently show to be hosted on:

C:\Documents and Settings\Admin>nslookup ilgrandecomunicatore.com 8.8.8.8
Server: google-public-dns-a.google.com
Address: 8.8.8.8

Non-authoritative answer:
Name: ilgrandecomunicatore.com
Address: 193.86.21.118

I'm fairly sure that the original parse (which you can pull up from the Report ID for the sources, would have shown that IP address in fact - it is the starting point (after any resolution of link obfuscation) to finding responsibe parties to which to report. It is subject to change - there's a FAQ on it somewhere - here: https://www.spamcop.net/fom-serve/cache/32.html. I'm currently showing "% Abuse contact for '193.86.21.0 - 193.86.21.255' is 'nic[at]t-mobile.cz' (RIPE Database query service).. SC often prefers an abuse.net abuse address or a cached one, for whatever reasons. Sometimes they (SC) will accept a reporter suggestion to use a RIPE (etc.) one instead. Reporting addresses can flop around from one day to the next (even - perhaps especially) within SC's reporting system), I think you just caught ilgrandecomunicatore.com in the process of "change". Maybe your reports helped force that?

You don't really need to educate yourself on reading the parses - but I confess one probably needs to look at quite a few of them to understand any, in this "feature rich and dynamic" environment.

[db17]

I've put the raw headers of the SUV spam into SC Process spam again (but as already submitted, didn't use report button). Not seeing 193.86.21.118 anywhere in the resulting output, nor in the raw header on my mail client. I am seeing ilgrandecomunicatore.com, but as I said, I can't get an IP from that, as that domain is not recognized by Whois. So perhaps if you don't mind can you explain, dumbed down if necessary, how you saw that IP, and what makes that the originating IP instead of the 153.92.194.xxx

EDIT: and just now 8 more with originating IPs all from 153.92.195.xxx, instead of 153.92.194.xxx Again, all associated with conware.de

http://i59.tinypic.com/15my0yp.png

And

If reported today, reports would be sent to:

Re: 153.92.195.98 (Administrator of network where email originates)

[Farelf]

Sorry - probably can't be explained at an appropriate level without proper assessment of where you are in the learning curve (which most of us are still climbing which complicates things a bit as well) but rest assured it can be understood to a useful level by most with some little effort. For a digestible overview of the spam "industry" with layers of optional detail look at Rick Conner's http://www.rickconner.net/spamweb/

The "source address" address, as said before, is the address of the computer sending you the email. That is not the same as the server hosting the spam-advertized website(s) "payloads" with the ilgrandecomunicatore.com domain name. Utterly different beasts.

153.92.194.xxx (and 153.92.195.xxx) are part of a HUGE netbloc (153.0.0.0/8) directly allocated by InterNIC before the Regional Internet Registries were established (look those up if you want but it's just blah-blah). EXCEPT that makes tracking down who-ever is using/abusing them at any given time (using RIR-referred resources) a little more difficult - and if swapped around from spam to spam can degrade the value of any cached abuse.net addresses. Which is why spammers like using those IP addresses. All 16 million and a good many more possible addresses. Because people complain about the spamming abuse from them, one-by-one. SpamCop is evidently picking up abuse addresses via forwards-backwards verification of the accepted sending domain (from the accepted IP address and corresponding server name) and reaching into abuse.net (or is otherwise using the correct RIR, however established).

Website servers are a little less easily shuffled around than are e-mail servers but, as discussed, sometimes they have to be moved anyway due to reporter pressure (or non-payment of accounts more likely ).

You can see what is in the parse by going into your "Past Reports". Just click on that Report ID field that you have carefully blanked out in the images (needn't bother, only you and SC staff can use that) alongside one of (there can be several) the SOURCE IP address reports, as previously stipulated. That brings up the submitted spam, with a link to the parse at the very top. Follow that link and towards the top of the parse page there are a couple of lines looking like:

"Here is your TRACKING URL - it may be saved for future reference:
http://www.spamcop.net/sc?id=z641303267z045b750a0c3cf8aa3bfef3b3d92488bfz"

That tracking URL can safely be posted here, in public, for discussion of the content and process. Ensures everyone sees the same thing at every level, preserves confidentiality and removes the risk of spreading the payload. It has a life of 90 days,

That parse (a re-run) will show you the spam payload (website) IP address used for abuse address location NOW but it will ALSO show you the difference, if any, between the original report address ("Reports regarding this spam have already been sent:") and now. You can run a basic DNS check (the command-line nslookup procedure in an earlier post here - or there are any number of web-based services to do the same) of any such different domain (as sometimes indicated by the report address domain - or there are "other ways", no doubt).

As you have correctly deduced, understanding the headers is a BIG THING, understanding the elements of the parse is an even bigger one and the effort needed is correspondingly greater. Reviewing the changes to reporting addresses puzzles many and is key to getting under the hood of the whole spam problem.

You will understand none of us can individually spend such amounts of time with every 'enquiring mind" (would love to but time is precious and running serious risk of exposing limits of own knowledge already with concurrent risk of corrupting a whole new generation of Reporters). Which is a kindly-meant (and as self-deprecating as I get) way of saying for a précis of the "self help" resources, don't forget http://forum.spamcop.net/forums/topic/14783-what-is-spamcop/

But there will always be those niggling little queries - that is understood and perfectly acceptable. And others who are prepared to step in and offer guidance. The point I am trying to stress is - though reporting effort mightn't seem to do much good it has a hidden effect, both for the originating source and the spamvertized payloads - it inconveniences spammers and forces them to continually run hard just to stay in place. All of which I contend might be illustrated by your examples which a casual observer might conclude shows just the opposite.

Steve

[db17]

Sorry for not having gotten back sooner. Was a bit preoccupied with some non-spam business. First, thanks for that link. I will study that. I tried following your instructions for parsing the spam, and basically what I ended up doing was an nslookup for the originating site of one of the newest spams, lapostaeletronica.com. It came back with an IP of 193.86.21.118 (193.86.21 - Czech Republic - Cznet-a). That 193.86.21 agrees with what you found earlier for another message (ilgrandecomunicatore.com = 193.86.21.118). So I'm thinking that that's what really needs blocking--unless those are the specific addresses of botnetted computers, and that whole IP range will keep changing, making this enterprise of blocking IP ranges entirely futile. (In other words, plus ca change, plus c'est la meme chose).

What I had done earlier was to use iptables in my router firewall (Tomato) to block the entire IP range of 153.92.0.0/16, but since I just got 7 new spams, all from that same IP range, that doesn't seem to be the ticket; the 153.92.0.0/16 must be a red herring. I've now decided to add to iptables the entire range at 193.86.0.0/16. It may be overkill, but don't think I'll be missing anything if it is. Does that sound like the way to go?

Thanks for all the help with this.

[db17]

No longer seeing the edit button: Just got four more after blocking 193.86.0.0/16. So now blocking only the specific subnet from which all this crap appears to be coming, 193.86.21.0/24. But I have the feeling that, for whatever reasons, this blocking strategy is not working.

[Farelf]

Alas, I know nothing about the use of iptables but to keep stuff out of your inbox it is good to divert (with the subsequent opportunity to examine) the undesirable rather than to simply block. Seeing exactly what would otherwise be dropped adds a dimension to diagnosing what is happening. And allows reporting "in the greater good" because of course blocking by one account has no traction at all to affect the spam operations of the perpetrators whereas, as I have said, I think the various RBLs (and exercise of abuse addresses in conjunction with the SCbl at least) do have a detrimental effect on them over-all, though not necessarily an immediate one.

Have you looked at SpamAssassin? Not being a Mac user I keep forgetting about it but I understand there is a long association with SpamCop, Past topics can easily be found by searching these forums.

[db17]

I discovered that iptables at the router won't block emails coming directly from my ISP, who handles my email, to my mail client, Apple Mail, only secondary trackers embedded in the message or images (never allow those to load). So blocking that way is completely useless. The problem with SpamAssassin, or anything like it that I could install at the Mac, is that it won't prevent spam getting to my wife's iPad (or any other client) also on the same LAN. Actually, as far as things go at the Mac end, I'm not quite so bothered about the spam, as I have the bayesian filtering in Apple Mail quite well trained to move spam into the junk mailbox, or just delete it--though not quite ready to trust that option. The idea that I can't stop this garbage is what really drives me crazy.

I just discovered and was quite surprised to see that Blocked Senders at my ISP will accept an IP, not just a standard email address. I've entered 193.86.21.118, which is from where all the recent stuff appears to be originating. I don't know if that means it's really blocking that IP, or just allowing an IP to be entered, but won't actually do anything with it. Will also see if it lets me enter an address range such as 192.168.1.1-192.168.1.255, but I kind of doubt that it will.

One other question: I've looked through all the SC documentation about how to report spam, and I"m still puzzled about whether I'm doing it correctly. Please check me on this. I'm doing this via the web. First I enter the entire raw header into the Paste entire spam field, then hit the Process spam button, then, after the page refreshes (at which point I'm seeing three postmaster[at] checkboxes already checked--and does that mean that SC on its own will be contacting those three addresses with abuse messages?), I hit Send spam reports now. Is that it? Is there anything I'm leaving undone?

Also, still sorrily confused about the 193.86.21.118 all these bogus "from" domain names resolve to from an nslookup. You said that that's the IP of the source computer. But I'm also quite often seeing postmaster[at]conware.de in the SC report. So does SC send an abuse message, including the threat to blacklist, to conware.de, if that's the host of that source? (And, considering that these spammers quite often employ botnets, is it really possible that all these bogus domain names are resolving to that one IP source address, 193.86.21.118? Or is that IP completely forged along with the bogus domain name.)

And still another confusion--apologies if this has already been explained: if the source is 193.86.21.118, what's the X-Originating-IP: [153.92.196.xxx] that I'm seeing in almost all of these? Please forgive me if I'm not getting all this right away. I am reading Rick's spam Digest, but still need some help with the specifics of what I'm seeing with this actual spam.

[db17]

Editing no longer working properly: from what I just read in Rick's spam Digest, it is likely these messages are direct-to-mx coming from a sole computer and dropped directly into my ISP/email handler? If that's the case, then SC sending abuse messages (to the bogus153.92.xxx.xxx, or anywhere for that matter) will be pointless because there is no host and all those 153.92.xxx.xxx host are totally bogus. Do I have that right? So this is just one computer at one public IP doing all the recent spamming? Would his ISP /email provider get an abuse report from SC?

I know you prefer identifying spammers and getting them shut down to blocking them, but I was able to enter 192.168.1.1-192.168.1.255 in Blocked Senders at my ISP. We really need some immediate relief from this recent onslaught.

[Farelf]

I discovered that iptables at the router won't block emails coming directly from my ISP, who handles my email, to my mail client, Apple Mail, only secondary trackers embedded in the message or images (never allow those to load). So blocking that way is completely useless. ...

Thanks for the explanation.

... One other question: I've looked through all the SC documentation about how to report spam, and I"m still puzzled about whether I'm doing it correctly. Please check me on this. I'm doing this via the web. First I enter the entire raw header into the Paste entire spam field, then hit the Process spam button, then, after the page refreshes (at which point I'm seeing three postmaster[at] checkboxes already checked--and does that mean that SC on its own will be contacting those three addresses with abuse messages?), I hit Send spam reports now. Is that it? Is there anything I'm leaving undone?

Looks good - only thing is, you MUST HAVE one or more (blank) lines following the headers, followed in turn by some sort of message body. If there is a way to copy and paste the entire "message source" (AKA the "full, unmodified email") then the blank line(s) and body following the headers is all taken care of for you. The body is where the parser picks up the links to any spam-advertized content, You should find the details of how to capture that "full, unmodified email" within https://www.spamcop.net/fom-serve/cache/19.html. Looks easy enough, you've been doing that already to get to the "raw headers" I think? Just keep the full message that follows those too, for pasting in.

...Also, still sorrily confused about the 193.86.21.118 all these bogus "from" domain names resolve to from an nslookup. You said that that's the IP of the source computer. But I'm also quite often seeing postmaster[at]conware.de in the SC report. So does SC send an abuse message, including the threat to blacklist, to conware.de, if that's the host of that source? (And, considering that these spammers quite often employ botnets, is it really possible that all these bogus domain names are resolving to that one IP source address, 193.86.21.118? Or is that IP completely forged along with the bogus domain name.)...

We're in danger of "overthinking" this I reckon. The whole parser system is designed to work out (to the extent necessary) what is bogus and what is not, especially once you have your mailhosting configuration set up. Until you try a parse you are perhaps needlessly "second-guessing"?

... And still another confusion--apologies if this has already been explained: if the source is 193.86.21.118, what's the X-Originating-IP: [153.92.196.xxx] that I'm seeing in almost all of these? Please forgive me if I'm not getting all this right away. I am reading Rick's spam Digest, but still need some help with the specifics of what I'm seeing with this actual spam.

193.86.21.118 appeared to be the host of a spam-advertized website payload from within the body of the spam - nothing to do with the source of the message which is what SC is good at detecting. The parser is designed to take care of both message source and "spamvertized" wesite resolution and usually lets you report to their respective administrators/abuse desks. The SCbl is for message sources (single IP addresses) only. There is no blacklist for those spamvertized websites. The SURBL has a blocklist served in part from SC submissions but is a separate entity. SC doesn't threaten anyone - not with blacklisting nor anything else. Used properly, SC reports should actually help those mail administrators inadvertently hosting spammers by giving them an early "heads up" before they fall into the clutches of other, sterner RBLs.

The "X-Originating-IP:" header should (and mostly does) show the message (spam) source. But a little caution is needed (were it otherwise!), it can be "trivially", as they say, forged.

Editing no longer working properly: from what I just read in Rick's spam Digest, it is likely these messages are direct-to-mx coming from a sole computer and dropped directly into my ISP/email handler? If that's the case, then SC sending abuse messages (to the bogus153.92.xxx.xxx, or anywhere for that matter) will be pointless because there is no host and all those 153.92.xxx.xxx host are totally bogus. Do I have that right? So this is just one computer at one public IP doing all the recent spamming?

And, possibly very cool, I was able to enter 192.168.1.1-192.168.1.255 in Blocked Senders at my ISP. Just hope it works.

Editing your own posts operates in an "edit window", as is the case with almost all forums that allow member edits. Not sure of the window "here" off-hand. It has been discussed in the past ad the answer should be "findable" by searching. But is is also very easy to get "lost" in multiple pages and lose hours of editing by dismissing the wrong one. I do that far too often myself.

Direct to MX spam with extensively-forged headers is one kind of spam (in many varieties, a bit "old hat" these days in gerenal) but the parsing service has evolved to see through all of that malarkey. Of course the parser is not perfect but conjecture and second-guessing is fruitless. Just try some submissions (you can cancel them without sending reports if not confident) and discuss any specific cases here or with the SC staff directly by mail - be sure to use the Tracking URLs.

[db17]

Looks good - only thing is, you MUST HAVE one or more (blank) lines following the headers, followed in turn by some sort of message body. If there is a way to copy and paste the entire "message source" (AKA the "full, unmodified email") then the blank line(s) and body following the headers is all taken care of for you.

I've been usng Raw Source from Apple Mail. I haven't been pasting in the message body, since, without loading images, there's hardly anything there beyond the subject, and that already appears in the Raw Source. Here's the Raw Source for a recent one. The only thing in the body that isn't an impossible to paste in text link is "Get up to $15,000 Overnight!" (My address, including any extract from that has obviously been obfuscated.)

Just try some submissions (you can cancel them without sending reports if not confident) and discuss any specific cases here or with the SC staff directly by mail - be sure to use the Tracking URLs.

You asked for it. Here goes. This is all what I have been pasting in to the Process spam field.

Return-path: <"ZippyLoan..Loan.Department"[at]perlapostaeltronica.com>

Received: from whofavoonnjofy ([153.92.197.71]) by vms172065.mailsrvcs.net

(Oracle Communications Messaging Server 7.0.5.34.0 64bit (built Oct 14 2014))

with ESMTP id <0NM600K24UAUWA70[at]vms172065.mailsrvcs.net> for

xxxxx[at]xxxx.bvcxd; Thu, 02 Apr 2015 11:45:48 -0500 (CDT)

Date: Thu, 02 Apr 2015 12:40:06 -0400

From: "ZippyLoan - Loan Department"

<ZippyLoan..Loan.Department[at]perlapostaeltronica.com>

Subject: Get up to $15,000 Overnight!

X-Originating-IP: [153.92.197.71]

To: "ZippyLoan - Loan Department"

<ZippyLoan..Loan.Department[at]perlapostaeltronica.com>

Message-id: <0NM600K2CUAUWA70[at]vms172065.mailsrvcs.net>

MIME-version: 1.0

Content-type: text/html

Content-transfer-encoding: 7BIT

X-CMAE-Score: 0

X-CMAE-Analysis: v=2.1 cv=facaEPVt c=1 sm=1 tr=0 a=acfMYBzekuJ6FRcBufNvsA==:117

a=acfMYBzekuJ6FRcBufNvsA==:17 a=nvtT5I8P45IA:10 a=nFrPLkdbAAAA:8

a=oR5dmqMzAAAA:8 a=-9mUelKeXuEA:10 a=e9J7MTPGsLIA:10 a=0WI6ukaWgWQhu0mUN_sA:9

a=m0BzW7v_MEcA:10 a=NWVoK91CQyQA:10 a=sfSThe1-LI4A:10 a=-rN3cgRaiQgA:10

Original-recipient: rfc822;xxxxx[at]xxxx.bvcxd

<center>

<a href="http://perlapostaeltronica.com/r21iu3rf6ybn/3187298a8551/l4mtjvi9ndhd">

<img src="http://perlapostaeltronica.com/asx473iaodkx/U7/hc1o6hxx0r7r" border="0" />

</a>

<br><br>

<a href="http://perlapostaeltronica.com/jn9ny07aqttf/3187299a8551/4bivb5gehc0r">

<img src="http://perlapostaeltronica.com/1y2cfr03uqk1/Mo/0urtk5kebuum" border="0" />

</a>

</center>

(Doing an nslookup for perlapostaeltronica.com resolves to my old friend 193.86.21.118). But blocking that isn't the ticket?

Here's a link to a screenshot of that one after being processed.

http://i58.tinypic.com/2qthe79.png

193.86.21.118 appeared to be the host of a spam-advertized website payload from within the body of the spam - nothing to do with the source of the message which is what SC is good at detecting.

Now really confused. I thought we had decided that 193.86.21.118 was really the source IP. Didn't you say that above, or did I misunderstand? So blocking 193.86.21.118 at my email provider will have no effect on these? Also, what's the definiton of host of a spam-advertized website payload? So if that's nothing to do with the source of the message, does SC give me that? If so, when and where? And is that what I need to block, if it can be blocked? To get down to specifics in that specific spam, if I'm going to do any blocking, what should that be?

The parser is designed to take care of both message source and "spamvertized" wesite resolution and usually lets you report to their respective administrators/abuse desks.

I do the reporting? I thought SC did that. So in the linked screenshot of the processed spam header, I report to postmaster[at]conware.de? But I thought that conware.de was bogus or spoofed, along with any of the 153.92.xxx.xx.

The "X-Originating-IP:" header should (and mostly does) show the message (spam) source.

So, then, in the linked screenshot it's really 153.92.197.71 after all? So, since that's changing all the time, if I'm going to try doing any blocking, I should be blocking the entire range 153.92.194.0-153.92.194.255 ?

The whole parser system is designed to work out (to the extent necessary) what is bogus and what is not, especially once you have your mailhosting configuration set up.

Knew nothing about that. I've looked at a lot of the documentation, but I may simply have missed it or it isn't obvious that that needs to be done.

I apologize in advance if someone has already done this and I missed it, but I think what would be really great, and what might eliminate a lot of this confusion, is if someone did a walk-through with screenshots of the process from beginning to end. I think there is something along these lines for submitting spam, but maybe quite abbreviated, via email, but I haven't seen anything that really explains the process for submitting via the web, as I have been doing. As it is, the documentation, in general, is all over the place. I've looked through the relevant FAQs and anything else about how to report spam and I'm still miserably confused. If you still have any more patience for this, maybe we can start with a walk-through of this one.

[Farelf]

(Excessive whitespace removed above).

Sorry db17 - I have managed to confuse you quite comprehensively it seems. My fault - I just get too "wordy" the harder I try to explain, it's all "in there", just not clearly enough. Is it still confusing when you re-read it all? Doesn't matter, we can fairly-well start afresh now.

I have been asking you to run the parser on some current sample spam and post the result.

The header data you have provided is fine. The body text is "close enough" to parse. Here is what the Tracking URL looks like for that data:

https://www.spamcop.net/sc?id=z6087547245z98b4e3c92fc33092e01fb750ffd6de02z

This is a very straight-forward type of spam, a type successfully handled by the parser in great numbers every minute of every day. "My" parse works slightly differently to what yours might because I do not (and cannot) have your mailhosts set up. That makes it a little more vulnerable to "clever forgery" than yours would be. Don't worry about that, this is not a clever spam (few are).

The details:

• the message source is 153.92.197.71
  • that's the one you want to block to stop spam from that source reaching you
• there are no bogus "Received:" lines
• SC finds an abuse address postmaster[at]conware.de
• SC finds the "payload" spam advertized website is hosted on 193.86.21.118
• SC has no suggested abuse address for that server
  • that doesn't matter, still worth resolving in case the SURBL or others can use the data

SC offers to report - it is up to the reporter whether or not reports are sent. Always, it is YOUR responsibility. You can cancel (as I did) or send. Whether you report or don't, you can use the information for other purposes, such as blocking. No reason you shouldn't do both on a case-by-case basis.

The walk-around idea is a sound one and has been done before. The only problem is things change. Here is the previous main attempt

http://forum.spamcop.net/forums/topic/2385-how-we-use-spamcop/

Many of those examples of differnt users with different systems and approaches involve the integrated SC mail system which no longer exists - though e-mail submission from other providers still works (alternative to using the paste-in webform). Neither does the "more user-friendly" version of the walk-around mentioned in that topic exist (we lost SCWiki in the last forum upgrade). But some of the information may be worth your review. I have the patience to try an update but I have neither the time nor the specific knowledge of your systems. Perhaps another user can help with Mac-OSX Mail or whatever it is. If there's a way to capture the raw text of entire message (including body) without opening the spam that would be good to know ...

Too many words again - but please have a go at reading the parser detail in the Tracking URL and ask questions based on that to prevent us going around in circles. Don't worry if a message is included in the parse saying the information is too old to report (happens 48 hours after the message was first received by your provider. Parsing and reporting are different processes.

[turetzsr]

<snip>

SC offers to report - it is up to the reporter whether or not reports are sent. Always, it is YOUR responsibility. You can cancel (as I did) or send.

<snip>

&nbsp &nbsp&nbsp&nbsp&nbsp You may also:

• Uncheck the "abuse" addresses to which SpamCop offers to report but you would prefer that it not and let it send to the others (which you would leave checked).
• Select from among those "Public standard report recipients" you have added to your reporting preferences to whom you wish SpamCop to send a report for the spam whose parse you are reviewing.

[db17]

Thanks Farelf and Steve T, much clearer now, but a few questions remain: Re. "the "payload" spam advertized website is hosted on 193.86.21.118." What does "payload spam advertized website" mean exactly? Is that another way of referring to the fake Return Path? And what is the difference between that, 193.86.21.118, and the "message source, 153.92.197.71?" And if I should not also be blocking 193.86.21.118 (the payload spam advertized website), why not? Also curious to know how an nslookup can determine an IP for what appears to be a completely fabricated (and changing--there was another name earlier that resolved to that same IP) domain name?

May have some more questions later, but I'll be able to sleep tonight.

[Farelf]

The payload is what the spammer wants you to see and do - in this case follow the link he is advertizing in the spam. It is perfectly common for one server/IP address to host any number of different websites within different domains, Those domains are not fake - the links wouldn't work if they were and there would be no point in advertizing them. You can look at the perlapostaeltronica.com domain from your example using https://www.robtex.com/ (select the first result) and just look at all the different sites on the one IP address under the "Shared" section, "Domains using the same mailservers as perlapostaeltronica.com" item (it takes a while to load). And that is only the first 100 of them, there will be more.

You can filter on the IP addresses of "payload" websites from the spam body (it is arguably more efficient than filtering/blocking on the server addresses sending the spam - the source) but in your circumstance it would be more complicated, it would take an extra layer of processing through whatever filter or blocklist comparison you would need to be using, Far simpler to work with what is in the headers (the message source) since you already have direct access to that layer of information.

[db17]

Great information, thanks. The reason why I thought perlapostaeltronica.com was fake was because I had done a different robtex whois for it, the one where you put the name or IP in the address bar after the forward slash; not really sure what that one is good for now). It came back with "No whois server is known for this kind of object." I did realize that that link had to go somewhere, even if, mistakenly, I thought the name was fake. I didn't think it mattered if the spammer used a real name or not, that the underlying link was what mattered. Of course, an nslookup couldn't find anything from a complelely fabricated name.

You can filter on the IP addresses of "payload" websites from the spam body (it is arguably more efficient than filtering/blocking on the server addresses sending the spam - the source) but in your circumstance it would be more complicated, it would take an extra layer of processing through whatever filter or blocklist comparison you would need to be using, Far simpler to work with what is in the headers (the message source) since you already have direct access to that layer of information.

It's really quite simple for me to enter that IP, or even domain name, into the Blocked Senders at my ISP/email provider--that is, if it works there. The jury is still out on that one. But so far, either because of my SC reporting or the blocking, or both, no more spam of that kind. (You know the story of the man who jumps off a 100 story building, and on the way down, at the 65th story, says, "so far, so good.")

[db17]

Hi Farelf,

Quick (hopefully) follow-up question: even though my email provider (misleadingly) allows entering IP addresses, including an entire IP range in Blocked Senders, they told me that unless it was in email address format or as a domain name, e.g., xxx.com, nothing would be blocked. I'm seeing a number of new spams which send reports to abuse[at]servermania.com (whose IP keeps changing, but stays in the same range). Since the spamadvertised name may change from one spam to another, but always refers to the same Tracking message source IP range, ideally I would like to enter an entire range (104.144.141.0-104.144.141.255) in order to block all these different IPs with each new spam from this source. But since that's impossible, would entering servermania.com in Blocked Senders be effective to block these coming from this IP range? Or any other ideas about what to block in domain name format, which it looks like what I'm stuck with?

Of course, I'm continuing to send reports, as well as trying to block.

Here's the entire output, including Tracking URL, if it will be helpful.

https://www.spamcop.net/sc?id=z6091701067z28d061ebd373c0f651da51b2f2a21d9dz

[Farelf]

Hi db17,

I'm afraid I don't know enough about your system/setup to suggest anything more in the way of filtering without adding a third-party solution (such as SpamAssassin) which you have already said is not suitable. There really ought to be a way to meet your needs with one of those but I'm afraid I don't know enough about that either. Perhaps some other helpful member could step in and advise ... I'm sure there are some who have their heads around the configuration you are using and practical solutions.

Now, you haven't quite grasped the use of the Tracking URL - the URL is the only reference to post here in public, as now amended. When you post the text of the parse AS WELL, you are also posting the spamvertized links from the original spam and you are doing the spammer's job for him, except 1,000 times more effectively than he did in a single e-mail to you. And you are making this forum look spammy and unsafe to search engines and other monitors.

Don't worry, lots of other people make the same mistake of not thinking through the consequences (or realize that the forum posting process converts plain text to live links) - just don't do it again, please. Use the URL of the parsing and report process page only, nothing else.

Sure hope someone comes along with some ideas to keep that spam out of your inbox.

[turetzsr]

&nbsp &nbsp&nbsp&nbsp&nbsp My expectation would be that pretty much everyone here is likely to be in the same situation as Steve (Farelf) and that db17's question would be best put to her/ his own e-mail provider. A simpler approach might be to just try adding the offending domain name to the blocked senders list and see what happens. The only drawback I can think of is that this might result in blocking mail that is wanted and unless some such unintentionally blocked mail were identified by its failure to arrive when expected, that situation might not be discoverable.

[db17]

Hi db17,

I'm afraid I don't know enough about your system/setup to suggest anything more in the way of filtering without adding a third-party solution (such as SpamAssassin) which you have already said is not suitable. There really ought to be a way to meet your needs with one of those but I'm afraid I don't know enough about that either. Perhaps some other helpful member could step in and advise ... I'm sure there are some who have their heads around the configuration you are using and practical solutions.

Now, you haven't quite grasped the use of the Tracking URL - the URL is the only reference to post here in public, as now amended. When you post the text of the parse AS WELL, you are also posting the spamvertized links from the original spam and you are doing the spammer's job for him, except 1,000 times more effectively than he did in a single e-mail to you. And you are making this forum look spammy and unsafe to search engines and other monitors.

Don't worry, lots of other people make the same mistake of not thinking through the consequences (or realize that the forum posting process converts plain text to live links) - just don't do it again, please. Use the URL of the parsing and report process page only, nothing else.

Sure hope someone comes along with some ideas to keep that spam out of your inbox.

Sorry about that. Not sure how I missed that, but I hadn't seen any live links when I looked through it. I'm usually very conscious of things like that.

Re. my setup, I'm not sure you really need to know all that much, or maybe I don't understand what you are asking about my setup. Maybe more what you would need to know is how or in what form email arrives at my email provider, and what my email provider does with that as it's sent on its way--and perhaps you can't know the specifics, but maybe you do know in general terms. The email client on the Mac is Apple Mail, set to connect to my email provider/ISP. Incoming is POP Port 995 SSL and outgoing is SMTP Port 465 SSL. The question really is, if the spammer is hosted at badorcluelesshost.com, will blocking that domain name in the Blocked Senders at the ISP/email provide keep out the spam? I suppose my question arises because I don't know if it arrives at my email provider with badorcluelesshost.com to be seen in some form as a blockable host. I thought that perhaps from the message details I provided, you would be able to know if it arrives that way or not. Boiled down to a general question: can a hosting service--the host of a specific incoming message (incoming to the email provider, that is) at least in principle, be blocked ?

I would love to be able to use SC's block list, but I have no way of employing that, as all the email comes in by way of the server at the ISP/email provider, and obviously I can't put anything in front of that. And, as I said, SpamAssassin would do quite nicely on the Mac client, but can't be installed on my wife's iPad, where the identical spam is also being received.

I've tried putting badorcluelesshost.com in Blocked Senders at the email provider's end, and I'll see what comes of this (at least until this or another spammer uses a different host), but perhaps now you may have a better idea about the setup, or have a suggestion.