|
| Re: This spam not correctly parsed by spamcop |
 |
Sun, 10 Dec 2006 17:29:27 -080 |
By convention, spamcop.spam is not a discussion group, and if you
properly present a tracking URL, which you have done, the discussion can
take place in spamcop or spamcop help.
posted to .spam and spamcop; f/ups to spamcop
Phil Scadden wrote:
> Tracking URL
www.spamcop.net/sc?id=z1162076832z567d619c87758c75ca5a77785d4324b6z
> This spam skipped past all our blacklist and content filters. When
> sent to spamcop, the
> analyser incorrectly put the source as our ISP. Looks like a spammer
> getting clever at
> obfuscating the source.
Spamcop's algorithm broke the chain prematurely.
Abbreviated Received tracelines *comment
from pat.gns.cri.nz ([131.203.7.45]) by dndm1.gns.cri.nz *serves
recipient
from omega.gns.cri.nz by pat.gns.cri.nz *serves recipient
from (pool-72-64-136-145.tampfl.fios.verizon.net [72.64.136.145]) by
omega.gns.cri.nz *sourceline, open proxy
from omjih ([72.64.143.115]) by
pool-72-64-136-145.tampfl.fios.verizon.net *bogusline
SC named the firstline as source instead of the 3rd line from the top.
There are a number of contributory factors to that premature chain
break, not the least of which is that the reporter didn't have mailhosts
configured. When mailhosts is not configured, SC has to perform on the
basis of the fallible MX information. This is problematic because MX
information doesn't necessarily correspond with the configuration of the
lines in the headers and the MTAs in the headers may not be handling
their lines compliantly and they may not properly configured with their
nameservice.
The MX for gns.cri.nz is mx1.gns.cri.nz DNS 161.65.52.34 - which IP
doesn't even appear in the gns.cri.nz headers.
The IP which /does/ appear 131.203.7.45 rDNS pat.gns.cri.nz which
pat.gns.cri.nz doesn't have an MX, so the only MX to use is as above,
which isn't even in the same ballpark. There's no way that an algorithm
can chain from 131.203.7.45 to omega.gns.cri.nz which DNS 161.65.52.34
The point of this long discussion about what is going on in the headers
is that if you are going to have your MTAs and their MX configured in a
'squirrely' way, then it is imperative that you also configure for
mailhosting before you do any spam reporting.
--
Mike Easter
kibitzer, not SC admin
|
| Post Reply
|
| Re: This spam not correctly parsed by spamcop |
 |
Sun, 10 Dec 2006 17:29:27 -080 |
By convention, spamcop.spam is not a discussion group, and if you
properly present a tracking URL, which you have done, the discussion can
take place in spamcop or spamcop help.
posted to .spam and spamcop; f/ups to spamcop
Phil Scadden wrote:
> Tracking URL
www.spamcop.net/sc?id=z1162076832z567d619c87758c75ca5a77785d4324b6z
> This spam skipped past all our blacklist and content filters. When
> sent to spamcop, the
> analyser incorrectly put the source as our ISP. Looks like a spammer
> getting clever at
> obfuscating the source.
Spamcop's algorithm broke the chain prematurely.
Abbreviated Received tracelines *comment
from pat.gns.cri.nz ([131.203.7.45]) by dndm1.gns.cri.nz *serves
recipient
from omega.gns.cri.nz by pat.gns.cri.nz *serves recipient
from (pool-72-64-136-145.tampfl.fios.verizon.net [72.64.136.145]) by
omega.gns.cri.nz *sourceline, open proxy
from omjih ([72.64.143.115]) by
pool-72-64-136-145.tampfl.fios.verizon.net *bogusline
SC named the firstline as source instead of the 3rd line from the top.
There are a number of contributory factors to that premature chain
break, not the least of which is that the reporter didn't have mailhosts
configured. When mailhosts is not configured, SC has to perform on the
basis of the fallible MX information. This is problematic because MX
information doesn't necessarily correspond with the configuration of the
lines in the headers and the MTAs in the headers may not be handling
their lines compliantly and they may not properly configured with their
nameservice.
The MX for gns.cri.nz is mx1.gns.cri.nz DNS 161.65.52.34 - which IP
doesn't even appear in the gns.cri.nz headers.
The IP which /does/ appear 131.203.7.45 rDNS pat.gns.cri.nz which
pat.gns.cri.nz doesn't have an MX, so the only MX to use is as above,
which isn't even in the same ballpark. There's no way that an algorithm
can chain from 131.203.7.45 to omega.gns.cri.nz which DNS 161.65.52.34
The point of this long discussion about what is going on in the headers
is that if you are going to have your MTAs and their MX configured in a
'squirrely' way, then it is imperative that you also configure for
mailhosting before you do any spam reporting.
--
Mike Easter
kibitzer, not SC admin
|
| Post Reply
|
| Re: This spam not correctly parsed by spamcop |
 |
Sun, 10 Dec 2006 17:56:32 -080 |
Mike Easter wrote:
> Spamcop's algorithm broke the chain prematurely.
> SC named the firstline as source instead of the 3rd line from the top.
> There are a number of contributory factors to that premature chain
> break, not the least of which is that the reporter didn't have
> mailhosts configured.
> The MX for gns.cri.nz is mx1.gns.cri.nz DNS 161.65.52.34 - which IP
> doesn't even appear in the gns.cri.nz headers.
> The point of this long discussion about what is going on in the
> headers is that if you are going to have your MTAs and their MX
> configured in a 'squirrely' way, then it is imperative that you also
> configure for mailhosting before you do any spam reporting.
If you are in control of how the MTAs stamp their lines, having the
lines stamped compliantly would also help to solve the problem.
http://www.spamcop.net/sc?id=z1162294815z62ec8977bb88cc665864945062265beaz
That is a tracker for an 'artificial' set of headers which are
compliantly configured and look like this abbreviated:
Abbreviated Received tracelines *comment
from pat.gns.cri.nz ([131.203.7.45]) by dndm1.gns.cri.nz *serves
recipient
from omega.gns.cri.nz ([161.65.52.34]) by pat.gns.cri.nz *serves
recipient
from (pool-72-64-136-145.tampfl.fios.verizon.net [72.64.136.145]) by
omega.gns.cri.nz *sourceline, open proxy
from omjih ([72.64.143.115]) by
pool-72-64-136-145.tampfl.fios.verizon.net *bogusline
... and SC correctly parses those lines with this result:
If reported today, reports would be sent to:
Re: 161.65.52.34 (Automated open-relay testing system(s))
Re: 72.64.136.145 (Administrator of network where email originates)
... because SC recognizes the gns.cri.nz MTA as the MX which is relaying
and properly sends it to the open relay testers and thus is able to
chain down to the sourceline.
SC is able to chain from the top 'from' field thru' the 2nd 'by' field
and then from the 2nd 'from' field to the 3rd 'by' field to derive the
correct source at the open proxy, which it does not chain beyond.
The algorithm works if the lines are compliant and reflect the status of
the MTAs when they differ from the MX.
--
Mike Easter
kibitzer, not SC admin
|
| Post Reply
|
| Re: This spam not correctly parsed by spamcop |
 |
Sun, 10 Dec 2006 19:54:57 -050 |
Phil Scadden wrote:
> Tracking URL
> http://www.spamcop.net/sc?id=z1162076832z567d619c87758c75ca5a77785d4324b6z
>
> This spam skipped past all our blacklist and content filters. When
> sent to spamcop, the
> analyser incorrectly put the source as our ISP. Looks like a spammer
> getting clever at
> obfuscating the source.
The short answer: use Mailhosts. The long answer: follows.
From the Parse:
Received: from pat.gns.cri.nz ([131.203.7.45]) by dndm1.gns.cri.nz
(Lotus
Domino Release 5.0.13a) with ESMTP id 2006121109410046:156905
; Mon, 11 Dec 2006 09:41:00 +1300
Received: from omega.gns.cri.nz (unverified) by pat.gns.cri.nz (Clearswift
SMTPRS 5.2.5) with
ESMTP id <T7c7d4b882d83cb072d15e0@pat.gns.cri.nz> for <x>; Mon, 11
Dec 2006 09:40:46 +1300
Received: from pool-72-64-136-145.tampfl.fios.verizon.net
(pool-72-64-136-145.tampfl.fios.verizon.net
[72.64.136.145]) by omega.gns.cri.nz (8.10.2-20030919/8.10.2) with SMTP id
kBAKeoA02779 for <x>; Mon, 11 Dec 2006 09:40:51 +1300 (NZDT)
Received: from omjih ([72.64.143.115]) by
pool-72-64-136-145.tampfl.fios.verizon.net
(8.13.4/8.13.4) with SMTP id kBBKignF075842; Mon, 11 Dec 2006 15:44:42
-0500
...
72.64.136.145 discarded as a forgery, using 131.203.7.45
There are more than a few problems here.
0. It appears that Phil Scadden has not followed SpamCop's recommendation
of using the Mailhosts feature of the SpamCop Parsing and Reporting System.
1. It appears that the SpamCop Parser is subject to confusion and sometimes
(in the case of email received by omega.gns.cri.nz) consequently buggy
two-steps-back interpretation when its Mailhosts feature is not used.
2. It appears that a user of gns.cri.nz and therefore omega.gns.cri.nz is
forwarding its spam email to its accounts at pat.gns.cri.nz and
dndm1.gns.cri.nz and then Phil Scadden is attempting to use SpamCop to
Report that spam email without using the Mailhosts feature.
3. It appears that omega.gns.cri.nz has not been trusted to relay by a
SpamCop Deputy or SpamCop Admin.
4. It appears that the WHOIS record for inetnum 131.203.0.0 -
131.203.255.255 was changed on 2006-09-29 by the APNIC Hostmaster. I asked
SpamCop's Parser to refresh its WHOIS cache, which changed the attempted
report recipients from p.whimp[at]comnet.co.nz to abuse[at]fx.net.nz.
5. In order not to confuse the SpamCop Parser, if Phil Scadden wants to
continue to use said Parser for testing without Mailhosts (which I don't
recommend) for email "Received: ... by omega.gns.cri.nz ...", he
should chop
off all "internal handoffs" before test Parsing; that is, start with a
"Received: ... by omega.gns.cri.nz ..." line. Use of the Parser for
sending
actual SpamCop Reports with this configuration would be a no-no,
specifically a violation of the "material alteration" rule.
6. The original post should have been posted to the spamcop newsgroup; I
have redirected followups there.
--
Best Regards, Jeff G.
http://forum.spamcop.net/forums/index.php?act=findpost&pid=37585
Wazoo and dbiel, as always, have my permission to post my SpamCop
Newsgroup posts in the SpamCop Forum and Wiki without this paragraph.
|
| Post Reply
|
| Re: This spam not correctly parsed by spamcop |
 |
Sun, 10 Dec 2006 19:54:57 -050 |
Phil Scadden wrote:
> Tracking URL
> http://www.spamcop.net/sc?id=z1162076832z567d619c87758c75ca5a77785d4324b6z
>
> This spam skipped past all our blacklist and content filters. When
> sent to spamcop, the
> analyser incorrectly put the source as our ISP. Looks like a spammer
> getting clever at
> obfuscating the source.
The short answer: use Mailhosts. The long answer: follows.
From the Parse:
Received: from pat.gns.cri.nz ([131.203.7.45]) by dndm1.gns.cri.nz
(Lotus
Domino Release 5.0.13a) with ESMTP id 2006121109410046:156905
; Mon, 11 Dec 2006 09:41:00 +1300
Received: from omega.gns.cri.nz (unverified) by pat.gns.cri.nz (Clearswift
SMTPRS 5.2.5) with
ESMTP id <T7c7d4b882d83cb072d15e0@pat.gns.cri.nz> for <x>; Mon, 11
Dec 2006 09:40:46 +1300
Received: from pool-72-64-136-145.tampfl.fios.verizon.net
(pool-72-64-136-145.tampfl.fios.verizon.net
[72.64.136.145]) by omega.gns.cri.nz (8.10.2-20030919/8.10.2) with SMTP id
kBAKeoA02779 for <x>; Mon, 11 Dec 2006 09:40:51 +1300 (NZDT)
Received: from omjih ([72.64.143.115]) by
pool-72-64-136-145.tampfl.fios.verizon.net
(8.13.4/8.13.4) with SMTP id kBBKignF075842; Mon, 11 Dec 2006 15:44:42
-0500
...
72.64.136.145 discarded as a forgery, using 131.203.7.45
There are more than a few problems here.
0. It appears that Phil Scadden has not followed SpamCop's recommendation
of using the Mailhosts feature of the SpamCop Parsing and Reporting System.
1. It appears that the SpamCop Parser is subject to confusion and sometimes
(in the case of email received by omega.gns.cri.nz) consequently buggy
two-steps-back interpretation when its Mailhosts feature is not used.
2. It appears that a user of gns.cri.nz and therefore omega.gns.cri.nz is
forwarding its spam email to its accounts at pat.gns.cri.nz and
dndm1.gns.cri.nz and then Phil Scadden is attempting to use SpamCop to
Report that spam email without using the Mailhosts feature.
3. It appears that omega.gns.cri.nz has not been trusted to relay by a
SpamCop Deputy or SpamCop Admin.
4. It appears that the WHOIS record for inetnum 131.203.0.0 -
131.203.255.255 was changed on 2006-09-29 by the APNIC Hostmaster. I asked
SpamCop's Parser to refresh its WHOIS cache, which changed the attempted
report recipients from p.whimp[at]comnet.co.nz to abuse[at]fx.net.nz.
5. In order not to confuse the SpamCop Parser, if Phil Scadden wants to
continue to use said Parser for testing without Mailhosts (which I don't
recommend) for email "Received: ... by omega.gns.cri.nz ...", he
should chop
off all "internal handoffs" before test Parsing; that is, start with a
"Received: ... by omega.gns.cri.nz ..." line. Use of the Parser for
sending
actual SpamCop Reports with this configuration would be a no-no,
specifically a violation of the "material alteration" rule.
6. The original post should have been posted to the spamcop newsgroup; I
have redirected followups there.
--
Best Regards, Jeff G.
http://forum.spamcop.net/forums/index.php?act=findpost&pid=37585
Wazoo and dbiel, as always, have my permission to post my SpamCop
Newsgroup posts in the SpamCop Forum and Wiki without this paragraph.
|
| Post Reply
|
|
|