I've sent this to deputies[at] but thought it's worth reporting here too.
SpamCop's not dealing with hex-obfuscated URIs (found in the current IRS phishing) as well as might be expected, e.g.:
Tracking link: http://0x7C.0xA.0x7F.0xA4/Internal.Revenue...refund-form.php
No recent reports, no history available
Cannot resolve http://0x7C.0xA.0x7F.0xA4/Internal.Revenue...refund-form.php
It's attempting to resolve something that is clearly not a domain name, because the TLD begins with a digit.
Really a report should go to the reporting address for 124.10.127.164, i.e. spam[at]anet.net.tw
Note that 2081062820 and 0x7C0A7FA4 (different ways of parsing the same IP address) are parsed correctly.
Full Version: Another parser challenge, but easier - hex IPs
QUOTE(Cedders @ Sep 9 2008, 02:33 PM) 
Tracking link: http://0x7C.0xA.0x7F.0xA4/Internal.Revenue...refund-form.php
No recent reports, no history available
Cannot resolve http://0x7C.0xA.0x7F.0xA4/Internal.Revenue...refund-form.php
It's attempting to resolve something that is clearly not a domain name, because the TLD begins with a digit.
No recent reports, no history available
Cannot resolve http://0x7C.0xA.0x7F.0xA4/Internal.Revenue...refund-form.php
It's attempting to resolve something that is clearly not a domain name, because the TLD begins with a digit.
No Tracking URL provided, so all that can be said 'here' is that hte data you present is out of context. The most glaring question would be what the headers and/or MIME-Boundary definition lines define this embedded stuff to be.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.