[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 08:50:51
+0000 said:

> On 30 Mar 2005 You have no need to know entered spamcop.help and left
> news:pan.2005.03.30.22.25.33.270552 at fl.net.invalid: 
> 
>> If the MX is the first receiver it gets marked as the spam source
>> rather than the original source. (Before someone asks, the ISP has two
>> names and all MXs for one are MXs for the other. I have munged one as
>> ISP.MX and the other as isp-other-name.mx)
>> 
> 
> Your first mistake is thinking that MX has anything to do with outgoing 
> mail.

At no point did I say the MX was sending mail. It *is* correctly relaying.

The spammer connected to one of the ISP's MXs. The name the MX put in the
received line is a valid name for the box.

If you do the forward lookup on that name you get the same IP as one of
the MXs.

If you then reverse lookup that address you get the name in the received
line. This is not a name that appears in an MX record. (If there were PTR
records for each A record this would not happen.)

If this MX is the first receiver SC discards it as fake and wants to
report it.

If this MX is *not* the first receiver SC accepts it as valid after
comparing its address with those of the MXs and finding it matches.

> The sending server needs to send out the actual hostname, it can't use a
> name who's PTR resolves to a different hostname. If it does, Spamcop has
> to try to make a bunch of guesses to see if any match turns up. I have
> an ISP that uses 2 or 3 alternating relays and Spamcop has never got it
> wrong.
> In your first example, why doesn't isp-other-name.mx match 4dmail.co.uk?

Because isp-other-name.mx is one of the MXs for the other name by which
my ISP is known. I said that in one of the comments you snipped.
4dmail.co.uk was the source of that mail.

> 
> Even the spammers are figuring this out.

I've gone through the SC mailhost process and got all the combinations
of MXs for both ISP names listed, so we'll see whether that solves it
completely.

-- 
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