[SC-Help] Re: Spamcop treats MX differently depending on where it appears in chain

[You have no need to know]

Abandoning the right to remain silent, Blammo at Sat, 02 Apr 2005 18:08:37
+0000 said:

> Oh, wait, you mean you have the headers reversed? I was thinking you had 
> them reversed, but I don't see why you would want to confuse us like that.

I think I'll go back to the original question (the one that Mike Easter
made sense out) of for me to explain what was going on. There are two
examples. I have deliberately given names in differing letter case for the
following reason.

SC appears to be doing a case sensitive match on DNS names. This is *not*
valid. When it comes to ASCII encoded names DNS is case insensitive.

(Aside: DNS names do *not* have to follow the rules for host names as
given in the RFCs. The only rules are that the whole name must not exceed
255 octets, that two dots may not be consecutive, and that no more that 63
non-dot octets can appear between dots. Octets are not constrained to be
0-9, A-Z, a-z, and '_'. This means DNS can handle names in codes other
than ASCII.)

=============================================

This is the first received line. Not the one closest to the top of the
headers. The one that shows the connect from outside the ISP.

Received: from 4dmail.co.uk (p548FF904.dip.t-dialin.net [84.143.249.4])
	by OTHERNAME.FOR.ISP.MX (Postfix) with ESMTP id 60BB36E; Tue, 29 Mar 2005
	05:56:46 +1000 (EST)

===

SC's analysis contains these lines relevant to that received line.

1.2.3.4 is not an MX for othername.for.isp.mx
host othername.for.isp.mx (checking ip) ip not found ; othername.for.isp.mx discarded as fake.
cannot find an mx for othername.for.isp.mx
cannot find an mx for isp.mx
....
host OTHERNAME.FOR.ISP.MX (checking ip) ip not found ; OTHERNAME.FOR.ISP.MX discarded as fake.
   Chain test:OTHERNAME.FOR.ISP.MX =? 1.2.3.4
   1.2.3.4 is not an MX for OTHERNAME.FOR.ISP.MX
   host OTHERNAME.FOR.ISP.MX (checking ip) ip not found ; OTHERNAME.FOR.ISP.MX discarded as fake.
   cannot find an mx for OTHERNAME.FOR.ISP.MX
   cannot find an mx for isp.mx
   Chain test failed
....
1.2.3.4 not listed in dnsbl.sorbs.net

===

SC then want to list 1.2.3.4 as the spam source.

=============================================

These are the first two received lines. Not the ones closest to the top of
the headers. The ones that show my ISP's mailhost accepting the mail from
smarthost3.tiscali.dk, and the earlier internal handoff within tiscali.

Received: from smarthost3.tiscali.dk (smarthost3.tiscali.dk [62.79.79.29])
	by OTHERNAME.FOR.ISP.MX (Postfix) with ESMTP id
	9B56E1E for <x>; Wed, 30 Mar 2005 10:15:40 +1000 (EST)
Received: from cpmail.dk.tiscali.com (mail.tiscali.dk [212.54.64.159])
	by smarthost3.tiscali.dk (8.13.1/8.13.1) with ESMTP id j2U0Bpuw026791;
	Wed, 30 Mar 2005 02:12:05 +0200 (CEST)

===

SC's analysis contains these lines relevant to those received lines.

Received:  from smarthost3.tiscali.dk (smarthost3.tiscali.dk [62.79.79.29]) by OTHERNAME.FOR.ISP.MX (Postfix) with ESMTP id 9B56E1E for <x>; Wed, 30 Mar 2005 10:15:40 +1000 (EST)
....
1.2.3.4 not listed in dnsbl.sorbs.net
   Chain test:OTHERNAME.FOR.ISP.MX =? othername.for.isp.mx
   host othername.for.isp.mx (checking ip) = 1.2.3.4
   1.2.3.4 is an MX for isp.mx
   1.2.3.4 is mx
   OTHERNAME.FOR.ISP.MX and othername.for.isp.mx have close IP addresses - chain verified

===

SC is happy that OTHERNAME.FOR.ISP.MX is a valid MX for the email and goes
on to blame tiscali.

-- 
Avoid reality at all costs.
$email =~ s/n(.)a(.)n(.)a(.)e(.+)invalid/$1$2$3$4$5au/;
icbm: 33.43.46S 150.59.27E