Farelf

Yes, we need advice. deputies[at]admin.spamcop.net remains a valid, deliverable address through CISCO - vmx.spamcop.net (184.94.240.112) - which is not the same MX as [at]spamcop.net/cesmail.net/cqmail.net and presumably doesn't require forwarding (and whatever it does with incoming, it certainly sends a lot of mail out) but I guess there's a reason Don changed his address.

Thanks Lou. Calvin, there is a real problem with the internet address for that site. Finding the authoritative name servers: - and applying one of those to find the address - (the IP address is just that of the name server) the site's own nameservice doesn't know where it is right now. That could be symptomatic of all sorts of things but in any event may explain why the parser didn't find it and, if there are cached results on other (non-authoritative name servers) there are variable results with (supposed) resolution. To take up on Lou's point, for future reference - it is best, for that and other reasons to discuss report results by referencing the Tracking URL from the head of the parser, That's from the bit (like): Regards, Steve S

I'm guessing there is no "MY_SERVER_NAME" otherwise the AOL header would have shown it? rDNS is another matter - as also whether or not "MY_SERVER_IP" is in the Spamhaus PBL or the equivalent in sorbs.net (which feeding it into the senderbase lookup would also show, for both//either). None of which, whatever the results and whatever the implications for messaging from the O/P's server IN GENERAL, answers the question why the particular transaction was not picked up in the O/P's outgoing logs. That sounds like a hack of some sort - another server using "MY_SERVER_IP" as a proxy, perhaps. I don't know how that is even possible or what traces of such abuse might exist (or where, presumably that would be with the ISP). In any event, checking "MY_SERVER_IP" in the senderbase.org lookup is a very good starting point, good call petzl.

If there was a forged header improperly implicating you in a SpamCop report you could try writing to the SpamCop administrator, Don D'Minion (spamcop[at]spro.net). If he can verify the forgery (and he sees more of this stuff than any of the rest of us) that might help with your ISP. On the external evidence MY_SERVER_IP would definitely be seen as the apparent source - the SC parser would pick that from the first "Received:" line.

Seems like it biripada - but usually the originating IP address is taken from the first "Received:" line ("X-....:" lines should never be trusted, too easy to forge), often in the form I assume you have checked your IP address in the CBL for any evidence of compromise/relay?

Looks like they do all their magic internally Dave - as perhaps also indicated by the Mailhosting system accepting the domain - so, unless someone knows better, no special requirements for reporting spam to a Sneakemail account. I'm sure we've had other members reporting spam to Sneakemail addresses before (though at least one of those was severely challenged to comprehend the ineffable stupidity of the spammers involved IIRC).

a pungent commentary indeed. Good to know someone at SC can be provoked by twitter's blatant hypocrisy (placing onus on phishing and hacking avoidance squarely with the user). Using VirusTotal (https://www.virustotal.com/en/url/e98b2e7fa5de739620fda804cb2230e90598b69d2fdc37ef81f175761d85a64b/analysis/1415333536/) we can find where the t.co shortener involved redirects, we can get a VT analysis of the target from the link in the first analysis - (http://www.virustotal.com/url/1cd60dbd451fd9e15458d7a596a82e47430faad8996e9deb67d5e07d8c0d1fca/analysis/) - we can get quttera.com file analysis and commentary for both from the links provided in the VT reports and any details of any blacklists (t.co).

Fixed

Further discussion on the general problem of spammed Registrant addresses split to new topic at http://forum.spamcop.net/forums/topic/14508-spam-to-domain-registrant-contact-address/ in the Lounge.

Good opportunity to see how things work in this implementation of the IPB BB. Indeed, notifications are left behind with the original topic. anyone8 will need to unsubscribe to that one and subscribe to this (notifications should then work in relation to this topic). PMs sent to O/P and to anyone8.

Those Cyrillic domains have been discussed before (you might find the discussion in previous topics in this section) and I think where we left off was that you can use something like http://centralops.net/co/DomainDossier.aspx to resolve and look for an abuse address to send a user-specified reporting address. That one resolves to 112.145.153.59 (KR) and the nearest thing to an address that might receive reports seems to be security[at]powercomm.com

Thanks for the feedback Dave, a useful discussion I think, especially how tracert and ping can work but specific website resolution won't (that was the key, really, those utilities work differently to browsers but collectively eliminate a number of possibilities). Don't know how many times I've "flushed" without achieving anything but of course sometimes it is the answer (maybe in combination with other things but this time it really seems to have done the job). Know all about the forgetting thing - the small consolation I accord myself is I have more important things to remember Amending topic title to assist future searches and marking "Resolved", Steve S

Thanks all responders and to TC for further detail and confirmation - this situation seems very strange to those encountering it for the first time but the topic is now "Resolved".

Don't despair Dave. Members.spamcop.net - spamcop.net are hosted by Akamai Technologies (totally different to forum.spamcop.net) and that hosting is quite complex (use something like http://centralops.net/co/DomainDossier.aspx with DNS records checked to see). Could just be some momentary glitch in the routing with your specific network (it happens), maybe jagged a bad primary nameserver cache or something. In which case it should/could clear quickly (haven't heard of longer-term generalised problem for years). Could be some sort of resolver problem in your own machine's DNS cache (look up and try ipconfig /flushdns) - or some unholy alliance of both. I'm sure you would be getting the same non-result with both http://www.spamcop.net/mcgi?action=loginform and http://members.spamcop.net/ entry points from what you say but mentioning both should you want to confirm. Interested in knowing how you get on and would welcome updates.

You may be right - but we still need that Tracking URL. [P.S.] I think the magic search phrase is "No source IP address found, cannot proceed." which is an actual, complete, parser exception declaration/error (perhaps the same one the O/P saw), often followed by "Add/edit your mailhost configuration". I currently get 102 hits within the forum using the complete "No source" phrase and the O/P may well find the answer within that lot. We may never know, TC hasn't subscribed to the topic and hasn't logged in since.

Steve - the native search facility is lousy, that's why we ended up with three different search facilities in the previous forum implementation. darkhours/TC - at the moment you can find some explanation of Tracking URLs at http://forum.spamcop.net/forums/topic/4473-spamcop-glossary/#TURL When you get an error that stops the process from going though to an actual report, that Tracking URL is still available. Until you dismiss the parser page. Unlike when a report is made, you cannot go back and retrieve it through your Past Reports. But you can parse it again and copy the URL to bring to the discussion. There are too many possibilities to sort out technical detail without seeing the source and the parsing and the Tracking URL combines both - without making your service provider and account details public.

I don't see that you've read the message I sent you Stu - but your follow up sounds (sort of) like you have?

Post to test whether or not David's notification works.

Board notifications are all through the same servers as far as I know. I just tried pushing a test e-mail to you through the diagnostics system. If you're getting any, you should be getting all (depending on how you have your "notifications" set up and I had a look at that, all seems to be in order). Try re-subscribing if it is not working for a particular topic. According to the forum you have not subscribed to ("followed") this topic.

SC IP Board Community "From:" address changed to something that sits with the IPB outgoing server(s). Should pass basic validation checks now, seems to be working for notifications and forum account e-mail authorisation messages to diverse networks.

Okay - my comment about forum notifications needs explanation - totally different server involved to that used for parser confirmation requests, it is just it could lead to anything purporting to come from ".spamcop.net" to be treated a little harshly by some networks right now. Good luck! P.S. also PM'd.

See http://forum.spamcop.net/forums/topic/14476-no-response-from-spam-submission-address/ - if that addresses your situation we will merge topics. If not - well, the contact page you link is working for me, maybe your network is having DNS issues? When you log-in to your http://members.spamcop.net/ page, do you find unreported spam waiting for you? Also, forum notifications are struggling to get through some (many?) networks at the moment. It's a sender authentication issue, probably, CISCO should be able to fix it. Well, Steve T has pointed to the link to this complete diagnostic process in that other "No response" post, so probably better if you work your way through that. Too many unknowns otherwise.

http://kb.mozillazine.org/Security.tls.version.* security.tls.version.max = 3 3=TLS 1.2 is the minimum required / maximum supported encryption protocol.... SSL 3.0 is specified by 0 in those settings. Yes, I know Another checker, mentioned in Mozilla pages, is https://www.ssllabs.com/ssltest/viewMyClient.html

Thanks, Internet Explorer was vulnerable (IE8, I just use for a few MS things - usually), that fixed it.

Interesting ... Firefox (32.0.3) was vulnerable (vulnerability patch due 25 Nov with 34 or get the add-on) but SeaMonkey (2.30) not.