rannday Posted May 5, 2017 Share Posted May 5, 2017 How should I read this trace? 0 being the first occurrence, 3 the last? Or vice-versa? Which IP did this spam originate from, is what I really want to know. Quote 0: Received: from www.somedomain.com (www.somedomain.com. [1.1.1.1]) by mx.google.com with ESMTP id 16si24318443iop.192.2017.05.04.14.13.00 for <x>; Thu, 04 May 2017 14:13:01 -0700 (PDT) Hostname verified: www.somedomain.com Gmail/Postini received mail from some domain com ( 1.1.1.1 ) 1: Received: from www.anotherdomain.com (www.anotherdomain.com [2.2.2.2]) by www.somedomain.com (8.14.2/8.14.2) with ESMTP id v44LD0jF025845 for <x>; Thu, 4 May 2017 15:13:00 -0600 (MDT) Hostname verified: www.anotherdomain.com some domain com received mail from anotherdomain.com ( 2.2.2.2 ) 2: Received: from www.yetanotherdomain.com (ww3.yetanotherdomain.com [3.3.3.3]) by www.anotherdomain.com (8.15.2/8.15.2) with ESMTP id v44LCwJT095696 for <x>; Thu, 4 May 2017 15:12:59 -0600 (MDT) (envelope-from dudesemail@email.com) Hostname verified: ww3.yetanotherdomain.com anotherdomain.com received mail from sending system 3.3.3.3 3: Received: from [10.0.0.4] ([4.4.4.4]) by mwinf5d41 with ME id GMBW1v00E182GJF03MCvxY; Thu, 04 May 2017 23:12:57 +0200 No unique hostname found for source: 4.4.4.4 Trusted site { 1.2.3 } received mail from 4.4.4.4 This is from an actual trace, I just obfuscated everything revealing. Link to comment Share on other sites More sharing options...
Lking Posted May 5, 2017 Share Posted May 5, 2017 A tracking URL would help the rest of us see the results from the parser AND the original spam submitted. Without that, you can compare the trace with the original and see that the "Received" at the top of the header is the one that addresses you/your ISP apposed to the ones further down the header. Link to comment Share on other sites More sharing options...
Dave_L Posted May 5, 2017 Share Posted May 5, 2017 2 hours ago, rannday said: ... 0 being the first occurrence, 3 the last? Or vice-versa? ... The date/time stamps generally help here, although they're not always 100% reliable. For example: The timestamp in "0" is Thu, 04 May 2017 14:13:01 -0700 (PDT), which is four seconds later than the timestamp in "3", Thu, 04 May 2017 23:12:57 +0200 (21:13:01 GMT - 21:12:57 GMT = 4 seconds). Link to comment Share on other sites More sharing options...
rannday Posted May 5, 2017 Author Share Posted May 5, 2017 Dave_L, do you have some website you use to convert/compare GMT timestamps? Or you just have all that memorized? Link to comment Share on other sites More sharing options...
Dave_L Posted May 5, 2017 Share Posted May 5, 2017 14:13:01 -0700 (PDT): The "-0700" means seven hours earlier than GMT. To convert to GMT, add seven hours. 23:12:57 +0200: The "+0200" means two hours later than GMT. To convert to GMT, subtract two hours. Link to comment Share on other sites More sharing options...
AJR Posted May 23, 2017 Share Posted May 23, 2017 As an email makes its way from the sender to the recipient, it will pass through multiple mail servers. Each server adds a "Received" header to the top of the message, and so you can (in theory) follow the route of the message from the sender to you by reading these headers from the bottom upwards. (Aside: Some servers will add other headers as well as their "Received" one, e.g. a server that's using SpamAssassin for filtering will add headers with the test results, and these often appear immediately below that server's "Received" header in the raw message, though these are not included in the SpamCop trace.) There are two main things that can go wrong with this: firstly, the headers can get mangled or re-ordered by systems that are handling the emails (some versions of Outlook had a habit of doing this), and secondly, malicious senders can add extra headers to try to point to blame onto someone else (which is essentially impossible for a server further along the chain to distinguish from round-about forwarding/routing of mail.) The first of these can't really be dealt with automatically unless you build a system specially to handle those mangled headers, but the second can be handled by reading the headers from the top down, which is what SpamCop does. By reading from the top down, you start with the Received header added by the mail server where your inbox lives, which is a server that you trust (well, if you don't trust it then you're a bit stuffed) and then follow the chain backwards until you reach the origin of the message - though this can be quite hard to define (do you care about the routing between the sender's mail servers? For spam reporting, probably not, but for other purposes that can be useful.) When you've registered mailhosts on your SpamCop account, it knows which lines are added by your mail provider's servers and which were added by the sender, and uses that knowledge to determine which servers to report. In the case of a Gmail account, it is the one that says "by mx.google.com" (marked 0 in your example) that shows which server handed the message off to Gmail, though whether this is the one that's reported depends on how your email is set up (e.g. if you have a you@yourdomain address forwarding to your Gmail account, the server listed in that line is the one doing the forwarding and SpamCop will know from your mailhosts configuration that it needs to follow the chain further.) TL;DR version: To answer "Which IP did this spam originate from?", read the "Received" headers from the top down until you reach the earliest one that was added by a server belonging to your email provider, and take the sender IP address listed there. This may or may not be the actual origin, but it's a suitable point to use for spam reporting. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.