Well, I sure got their attention ..
.. but they're back. It looks like I took them down for a couple of days or so, or got them talked to by their provider, but they're back up and running.
So, here's the story:
Rash of really aggressive (up to 8 per day) spam emails coming from a single source, with obfuscated and rapidly rotated From: addresses that point to nonsense domains (like receptionistjobs.aceoue@wrtprx.fermine.com). Links in the emails are all from the same domains and expire when they're rotated. All of the payload content is in HTML remote images, which does two things: 1) mask the payload content from Bayesian filters, so they're free to include all the commercial spam crap they want without tripping the filter statistics, and 2) generate a free web-bug hit on the server the images are stored on, so they have proof of an ad presentation to whichever ad clients are paying for their services and they get a micropayment for each hit, along with a confirmation that someone is reading the email they sent. (And the URL's contain random and almost certainly unique tokens that can track which recipient they were sent to.)
These messages are individually addressed with no To: field in the header, which means they have their own captive SMTP server, and the speed with which they're rotating these short-TTL DNS entries suggests they probably have their own captive DNS server somewhere as well that's delegated from ARIN somehow.
But they have one weakness.
They can't (yet?) mask or spoof the X-Originating-Ip: header field, which I think is generated from the receiving MX and not their own SMTP server, and because they need to be sending from a real IP address, I'm betting they can't mask or spoof it. (I'm sure they could add their own, but that wouldn't block the receiving MX from appending its own or even replacing the one sent by the source -- they've got a choice, they can either be a peer SMTP server and get unrestricted port 25 access to the recipient MX, or they can be a client and have to go through all the port 25 blocking and SMTP AUTH on 587 like everybody else. I'm thinking they're stuck with it, which means I've got them nailed at least in terms of tracking them.)
The messages are all coming from more or less random IP's, but they're all in two fairly small nets:
184.164.128.0/19
184.171.160.0/20
Both of these nets belong to:
SECURED SERVERS LLC
2353 W University Bldg A
Tempe
AZ 85281
US
(This was the provider I sent a TOS email to, and it apparently took them down for about a day. I don't know if they sweet talked the provider into not shutting them down for spamming, or if they in fact don't have anti-spam clauses in their TOS. But either way, they're a spammer harbor. And it seems from a lot of reports I've run from spam-tracking services that 184.0.0.0/8 is pretty lousy with both spammers and malware hosts, so this didn't really surprise me very much.)
And there's funny stuff going on with DNS here. The IP addresses they use all resolve to "heard[n].netnine.yellowforceusa.com" (with n being a small random number, they apparently have two digits' worth of IP's with individual records), but here's one bit of funny business: the IP's resolve to hostnames (via PTR's) but the hostnames don't resolve to IP's (i.e. no A or CNAME records) .. so they're only providing the minimum amount of resolution they have to. (This apparently breaks SPF, by the way, possibly because SPF tries to resolve both ways?, so Received-Spf: never shows a "fail". In case you were filtering on that.) And those obfuscated hostnames in the actual email addresses and URL's? They only have MX records, no A or CNAME either, and only one each, a 10 of course.
The hostnames in the URL's, however (example: axhordxzl.wvw.fermine.com) do resolve. They have to, because they need to work for the images to be able to load. These, interestingly enough, seem to be in the 184. block as well -- 184.95.63.35 in this case, which is in 184.95.32.0/19 (and also owned by SECURED SERVERS LLC) -- and *do* reverse resolve, to a different named address: rossd35.omaha.wellspeakconf2.com ..
$ dig axhordxzl.wvw.fermine.com
; <<>> DiG 9.4.3-P3 <<>> axhordxzl.wvw.fermine.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41195
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;axhordxzl.wvw.fermine.com. IN A
;; ANSWER SECTION:
axhordxzl.wvw.fermine.com. 293 IN A 184.95.63.35
;; AUTHORITY SECTION:
fermine.com. 172335 IN NS ns2.fermine.com.
fermine.com. 172335 IN NS ns1.fermine.com.
It's kind of interesting that they *have* a PTR, but since I'm not using fermine.com's nameservers directly, I get a more "real" reverse resolution. (I'm sure if they could be authoritative for the PTR, they'd have a lot more ability to play shenanigans and maybe even completely defeat SPF. Pretty sure that's just outside their reach the way they're delegated.)
But anyway, there's my data. Anyone who wants to join in the fight with me is welcome to contact me offlist ..
So, here's the story:
Rash of really aggressive (up to 8 per day) spam emails coming from a single source, with obfuscated and rapidly rotated From: addresses that point to nonsense domains (like receptionistjobs.aceoue@wrtprx.fermine.com). Links in the emails are all from the same domains and expire when they're rotated. All of the payload content is in HTML remote images, which does two things: 1) mask the payload content from Bayesian filters, so they're free to include all the commercial spam crap they want without tripping the filter statistics, and 2) generate a free web-bug hit on the server the images are stored on, so they have proof of an ad presentation to whichever ad clients are paying for their services and they get a micropayment for each hit, along with a confirmation that someone is reading the email they sent. (And the URL's contain random and almost certainly unique tokens that can track which recipient they were sent to.)
These messages are individually addressed with no To: field in the header, which means they have their own captive SMTP server, and the speed with which they're rotating these short-TTL DNS entries suggests they probably have their own captive DNS server somewhere as well that's delegated from ARIN somehow.
But they have one weakness.
They can't (yet?) mask or spoof the X-Originating-Ip: header field, which I think is generated from the receiving MX and not their own SMTP server, and because they need to be sending from a real IP address, I'm betting they can't mask or spoof it. (I'm sure they could add their own, but that wouldn't block the receiving MX from appending its own or even replacing the one sent by the source -- they've got a choice, they can either be a peer SMTP server and get unrestricted port 25 access to the recipient MX, or they can be a client and have to go through all the port 25 blocking and SMTP AUTH on 587 like everybody else. I'm thinking they're stuck with it, which means I've got them nailed at least in terms of tracking them.)
The messages are all coming from more or less random IP's, but they're all in two fairly small nets:
184.164.128.0/19
184.171.160.0/20
Both of these nets belong to:
SECURED SERVERS LLC
2353 W University Bldg A
Tempe
AZ 85281
US
(This was the provider I sent a TOS email to, and it apparently took them down for about a day. I don't know if they sweet talked the provider into not shutting them down for spamming, or if they in fact don't have anti-spam clauses in their TOS. But either way, they're a spammer harbor. And it seems from a lot of reports I've run from spam-tracking services that 184.0.0.0/8 is pretty lousy with both spammers and malware hosts, so this didn't really surprise me very much.)
And there's funny stuff going on with DNS here. The IP addresses they use all resolve to "heard[n].netnine.yellowforceusa.com" (with n being a small random number, they apparently have two digits' worth of IP's with individual records), but here's one bit of funny business: the IP's resolve to hostnames (via PTR's) but the hostnames don't resolve to IP's (i.e. no A or CNAME records) .. so they're only providing the minimum amount of resolution they have to. (This apparently breaks SPF, by the way, possibly because SPF tries to resolve both ways?, so Received-Spf: never shows a "fail". In case you were filtering on that.) And those obfuscated hostnames in the actual email addresses and URL's? They only have MX records, no A or CNAME either, and only one each, a 10 of course.
The hostnames in the URL's, however (example: axhordxzl.wvw.fermine.com) do resolve. They have to, because they need to work for the images to be able to load. These, interestingly enough, seem to be in the 184. block as well -- 184.95.63.35 in this case, which is in 184.95.32.0/19 (and also owned by SECURED SERVERS LLC) -- and *do* reverse resolve, to a different named address: rossd35.omaha.wellspeakconf2.com ..
$ dig axhordxzl.wvw.fermine.com
; <<>> DiG 9.4.3-P3 <<>> axhordxzl.wvw.fermine.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41195
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;axhordxzl.wvw.fermine.com. IN A
;; ANSWER SECTION:
axhordxzl.wvw.fermine.com. 293 IN A 184.95.63.35
;; AUTHORITY SECTION:
fermine.com. 172335 IN NS ns2.fermine.com.
fermine.com. 172335 IN NS ns1.fermine.com.
It's kind of interesting that they *have* a PTR, but since I'm not using fermine.com's nameservers directly, I get a more "real" reverse resolution. (I'm sure if they could be authoritative for the PTR, they'd have a lot more ability to play shenanigans and maybe even completely defeat SPF. Pretty sure that's just outside their reach the way they're delegated.)
But anyway, there's my data. Anyone who wants to join in the fight with me is welcome to contact me offlist ..