wrongly parsed header?

[reciprocity]

Forwarded a spam to SpamCop submission and processed it. I noticed it said:

> Reports regarding this spam have already been sent:
> Re: 37.9.53.106 (Administrator of network where email originates)
>    Reportid: 6253618553 To: admin[at]pinspb.ru

Looking at the spam it says:

> From tayson[at]gavle.to  Sat Jan 17 14:57:05 2015                                                                                                                
> Return-Path: <tayson[at]gavle.to>
> X-Original-To: raymond[at]anotherwayband.com
> Delivered-To: rsk[at]duty.misinformation.org
> X-Greylist: delayed 6033 seconds by postgrey-1.31 at duty.misinformation.org; Sat, 17 Jan 2015 14:57:03 PST
> Received: from mail.gavle.to (h-214-100.a322.corp.bahnhof.se [85.24.214.100])
>         by duty.misinformation.org (Postfix) with ESMTP id 7462DCCC070
>         for <raymond[at]anotherwayband.com>; Sat, 17 Jan 2015 14:57:03 -0800 (PST)
> Received: from localhost (localhost [127.0.0.1])
>         by mail.gavle.to (Postfix) with ESMTP id DDB1F1995181C;
>         Sat, 17 Jan 2015 20:39:44 +0100 (CET)
> Received: from mail.gavle.to ([127.0.0.1])
>         by localhost (mail.gavle.to [127.0.0.1]) (amavisd-new, port 10024)
>         with ESMTP id K3955VYkbgS7; Sat, 17 Jan 2015 20:39:44 +0100 (CET)
> Received: by mail.gavle.to (Postfix, from userid 29122)
>         id C8DCE19A9FC05; Sat, 17 Jan 2015 19:19:04 +0100 (CET)
> X-spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.gavle.to
> X-spam-Level: **
> X-spam-Status: No, score=2.1 required=3.0 tests=ALL_TRUSTED,BAYES_00,
>         FREEMAIL_FROM,HK_RANDOM_ENVFROM,HTML_MESSAGE,SORTED_RECIPS,SUSPICIOUS_RECIPS,
>         URIBL_BLOCKED,URIBL_DBL_ABUSE_REDIR autolearn=no version=3.3.1
> Received: from onhu (unknown [37.9.53.106])
>         by mail.gavle.to (Postfix) with ESMTPA id 700E719951A48;
>         Sat, 17 Jan 2015 19:19:02 +0100 (CET)

etc. I note that the 37.9.53.106 IP doesn't appear until well into the headers, stuff that shouldn't be relied on. Did the parser read my mail wrong? Or is there something I'm missing?

[turetzsr]

Hi, reciprocity,

&nbsp &nbsp&nbsp&nbsp&nbsp It looks more-or-less correct to me, assuming that all the "Received" lines above the "Received: from onhu (unknown [37.9.53.106])" line is internal to your ISP and/ or e-mail provider and/ or services any of your providers use to handle incoming e-mail.

[lisati]

Looks more-or-less correct to me too, similar to what I saw on incoming emails when I ran my own email server a couple of years ago, with greylisting, malware scanning and assessment via spamassasin.

[Farelf]

The parser can show you the logic used in parsing your headers. Go to your reportting account preferences from your member log-in page and check "Show technical data" under "Reporting preferences" (Under the "Preferences" tab). Also check "Show technical details" under the "Report spam" tab (where you past-in/review your spam submission). You wil then see notes for the parse, including things like "Internal handoff" and "ignored" where it has worked down through the headers, within your hosting.

When it hits the edge of "your" network it will note something like "Nothing trusted past this point" and will nominate the first IP address past that as the spam source, You don't need to resubmit spam (once the preferences have "taken hold") simply pick up any reuired example from your "Past reports" tab (by clicking on the Report ID from the display - which covers up to 90 days' worth of them). Note you can discuss the detail in these forums by posting the Tracking URL from (near) the head of the parses you can pull up that way (that URL is clearly specified and is not quite the same as the page URL for the display). Tracking URLs are the preferred way to query, discuss and comment on these matters (and give you an extra layer of security when doing so).

Might seem a bit complicated/daunting at first but you will get on top of it in no time, just needs a litte "exploration" for familiarity and confidence.

Regards,

Steve S

[reciprocity]

> From tayson[at]gavle.to  Sat Jan 17 14:57:05 2015                                                                                                                
> Return-Path: <tayson[at]gavle.to>
> X-Original-To: raymond[at]anotherwayband.com
> Delivered-To: rsk[at]duty.misinformation.org
> X-Greylist: delayed 6033 seconds by postgrey-1.31 at duty.misinformation.org; Sat, 17 Jan 2015 14:57:03 PST
> Received: from mail.gavle.to (h-214-100.a322.corp.bahnhof.se [85.24.214.100])
>         by duty.misinformation.org (Postfix) with ESMTP id 7462DCCC070
>         for <raymond[at]anotherwayband.com>; Sat, 17 Jan 2015 14:57:03 -0800 (PST)
> Received: from localhost (localhost [127.0.0.1])
>         by mail.gavle.to (Postfix) with ESMTP id DDB1F1995181C;
>         Sat, 17 Jan 2015 20:39:44 +0100 (CET)

(tracking URL; parse)

My server is duty.misinformation.org. Which is the receiver in only the very first listed Received header item. This is my network for mail purposes. I don't use my ISP (Comcast) for mail routing.

Isn't everything beyond that first Received header hearsay, then?

The IP that the SpamCop header parser found was from the fourth untrusted Received header.

[lisati]

> From tayson[at]gavle.to  Sat Jan 17 14:57:05 2015                                                                                                                
> Return-Path: <tayson[at]gavle.to>
> X-Original-To: raymond[at]anotherwayband.com
> Delivered-To: rsk[at]duty.misinformation.org
> X-Greylist: delayed 6033 seconds by postgrey-1.31 at duty.misinformation.org; Sat, 17 Jan 2015 14:57:03 PST
> Received: from mail.gavle.to (h-214-100.a322.corp.bahnhof.se [85.24.214.100])
>         by duty.misinformation.org (Postfix) with ESMTP id 7462DCCC070
>         for <raymond[at]anotherwayband.com>; Sat, 17 Jan 2015 14:57:03 -0800 (PST)
> Received: from localhost (localhost [127.0.0.1])
>         by mail.gavle.to (Postfix) with ESMTP id DDB1F1995181C;
>         Sat, 17 Jan 2015 20:39:44 +0100 (CET)

(tracking URL; parse)

Isn't everything beyond that first Received header hearsay, then?

Not necessarily: it's the Received lines inserted by other servers that are hearsay.

When I was running my own email server a couple of years ago, I used a combination of Postfix, Amavis, Clamav, and Spamassasin. It was normal for my server to add Received headers as the different processes passed the email around themselves. Barring configuration problems and mistakes, you can usually trust the headers inserted by your server, and skip over them to locate the header which identifies the email entering your system: it's difficult for the other server to forge or fake the IP address it uses to connect to yours. (Note: rDNS and hostnames are a different story.) Any header after that needs a degree of caution: what use you make of the information it contains depends on how much you trust the other person's server.

[reciprocity]

Not necessarily: it's the Received lines inserted by other servers that are hearsay.

Sorry not to be clear.

I'm trying to say that the first Received header is where my server enters the picture.

My server is duty.misinformation.org. The first my server heard of this email is noted in the first Received header.

The first Received header is the only one inserted by my server. The rest are given to my server by mail.gavle.to (h-214-100.a322.corp.bahnhof.se [85.24.214.100]). I don't know him from Adam.

[turetzsr]

&nbsp &nbsp&nbsp&nbsp&nbsp That seems a reasonable point. I would suggest that you refer this question to the SC Deputies (deputies[at]admin.spamcop.net) who are in a better position to explain the parser results than are we fellow users.

[lisati]

Sorry not to be clear.

I'm trying to say that the first Received header is where my server enters the picture.

My server is duty.misinformation.org. The first my server heard of this email is noted in the first Received header.

The first Received header is the only one inserted by my server. The rest are given to my server by mail.gavle.to (h-214-100.a322.corp.bahnhof.se [85.24.214.100]). I don't know him from Adam.

Good point. The way I interpret the headers you quoted in your first post, your server enters the picture with the line that begins "Received: from onhu (unknown [37.9.53.106])"

Must be lunch time, at least in the timezone I'm in at the moment.

All the best getting things sorted out.

[Richard W]

Forwarded a spam to SpamCop submission and processed it. I noticed it said:

> Reports regarding this spam have already been sent:
> Re: 37.9.53.106 (Administrator of network where email originates)
>    Reportid: 6253618553 To: admin[at]pinspb.ru

Looking at the spam it says:

> From tayson[at]gavle.to  Sat Jan 17 14:57:05 2015                                                                                                                
> Return-Path: <tayson[at]gavle.to>
> X-Original-To: raymond[at]anotherwayband.com
> Delivered-To: rsk[at]duty.misinformation.org
> X-Greylist: delayed 6033 seconds by postgrey-1.31 at duty.misinformation.org; Sat, 17 Jan 2015 14:57:03 PST
> Received: from mail.gavle.to (h-214-100.a322.corp.bahnhof.se [85.24.214.100])
>         by duty.misinformation.org (Postfix) with ESMTP id 7462DCCC070
>         for <raymond[at]anotherwayband.com>; Sat, 17 Jan 2015 14:57:03 -0800 (PST)
> Received: from localhost (localhost [127.0.0.1])
>         by mail.gavle.to (Postfix) with ESMTP id DDB1F1995181C;
>         Sat, 17 Jan 2015 20:39:44 +0100 (CET)
> Received: from mail.gavle.to ([127.0.0.1])
>         by localhost (mail.gavle.to [127.0.0.1]) (amavisd-new, port 10024)
>         with ESMTP id K3955VYkbgS7; Sat, 17 Jan 2015 20:39:44 +0100 (CET)
> Received: by mail.gavle.to (Postfix, from userid 29122)
>         id C8DCE19A9FC05; Sat, 17 Jan 2015 19:19:04 +0100 (CET)
> X-spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.gavle.to
> X-spam-Level: **
> X-spam-Status: No, score=2.1 required=3.0 tests=ALL_TRUSTED,BAYES_00,
>         FREEMAIL_FROM,HK_RANDOM_ENVFROM,HTML_MESSAGE,SORTED_RECIPS,SUSPICIOUS_RECIPS,
>         URIBL_BLOCKED,URIBL_DBL_ABUSE_REDIR autolearn=no version=3.3.1
> Received: from onhu (unknown [37.9.53.106])
>         by mail.gavle.to (Postfix) with ESMTPA id 700E719951A48;
>         Sat, 17 Jan 2015 19:19:02 +0100 (CET)

etc. I note that the 37.9.53.106 IP doesn't appear until well into the headers, stuff that shouldn't be relied on. Did the parser read my mail wrong? Or is there something I'm missing?

It's been a long time since I've hand parsed it took me a bit to get on top of this :-)

The parsing engine does act differently for users that have mailhost records in their account versus those that don't (you don't). It does rely a little more on chain verification, time stamp matches, things like that when there is no mailhost record. Note in the parsing there is a couple of statements:

mail.gavle.to and h-214-100.a322.corp.bahnhof.se have close IP addresses - chain verified

Possible relay: 85.24.214.100

Received line accepted

After that the received lines fail the chain test, so it falls back and takes the most recent accepted line, which is the handoff from 37.9.53.106, which does look like the correct target to me.

I looked at a bit of your report history to see how your network handles mail. Some other samples from this same source convinces me the right source was selected. If you had mailhosts in your account the parsing would probably have stopped at 85.24.214.100, but here it went one step further. Certainly not a wrong choice.

Richard

[reciprocity]

Ah, it hadn't occurred to me that Received lines beyond my server's could be trusted. But I guess you could apply some logic to see how sane the names, IPs, and timestamps are. Neat.

I wonder what kind of flexibility is in the timestamps (intra-server + inter-server processing time). There's about 11849 seconds between mail.gavle.to's receipt and my server's receipt. After you knock off 6033 seconds greylisting you have a delay of 5816 seconds / 1.6 hours. Maybe that's a reasonable delay from one mail system to the next. It's certainly better than some static, spoofed header that might be days or months off.

Do I trust the logic well enough to let it do its cleverness, or should I configure my mailhost?

[turetzsr]

&nbsp &nbsp&nbsp&nbsp&nbsp If nothing else, MailHosts will help prevent accidentally reporting your own provider as a spam source, however unlikely it would seem to be in your case. Of course, even MailHosts won't prevent it, as I've found on a couple of occasions, I guess due to my lack of attention after my provider added incoming servers.

[Farelf]

Ah, it hadn't occurred to me that Received lines beyond my server's could be trusted. But I guess you could apply some logic to see how sane the names, IPs, and timestamps are. Neat.

I wonder what kind of flexibility is in the timestamps (intra-server + inter-server processing time). There's about 11849 seconds between mail.gavle.to's receipt and my server's receipt. After you knock off 6033 seconds greylisting you have a delay of 5816 seconds / 1.6 hours. Maybe that's a reasonable delay from one mail system to the next. It's certainly better than some static, spoofed header that might be days or months off.

Do I trust the logic well enough to let it do its cleverness, or should I configure my mailhost?

My earlier post didn't pick up that your account is currently "non-mailhosted", sorry for that, my comments there were a little "off-beam" as a result.

I don't know that the timestamps play a part in the non-mailhosted parse logic - it is all/mostly about the validity of the relays used IIUC and, as such, may be fooled by "clever forgeries". The whole idea of mailhosting was to cut away that avenue of deception. It might be a good idea to review the pinned topics in the mailhosting forum, particularly http://forum.spamcop.net/forums/topic/4068-mailhost-system-configuration-explanation/.

In your case then, mailhosting would always stop the analysis at the border of your own servers and I can see how that may be a problem. Your reports would then be effectively saying "why are you relaying spam to me?" rather than "why are you hosting this spammer?". I think most (large) networks simply silently drop the stuff instead of assisting with the identification and elimination of the perpetrator - which is surely a large part of the reason for the progressive decline in reliability of e-mail communication (as a result, 85-90% of messages are supposed spam and are unseen by humans but it still gobble up resources and such filtering is prone to some degree to false positives with real mail precariously carried in a minority sub-set).

Part of the rationale for "bothering relays" (when reports are sent) is covered in SC FAQ (for network administrators and postmasters) https://www.spamcop.net/fom-serve/cache/99.html. The growth of botnets since the design of the original non-mailhosted parsing system no doubt contributes to the benefits of the mailhosted alternative. In any event, restricting reports to the entry point of your network (should you adopt mailhosting) has ramifications about which most of us know nothing. Perhaps you should talk direct to the SC staff - they may be able to advise - rather than you having to run the gauntlet of the "clever forgeries" which presumably are still out there (or, worse, give up on reporting).