Re: Trying to find out cause of blacklisting

Mike Easter wrote:

> mean that the parser made a mistake and named an IP such as the server
> as a source when it should have named something else -- altho' the
> parser is designed to name a user IP behind the server and not the
> server, so if the parser is 'unfamiliar' with the server and if the
> server's Received tracelines are non-compliant, then the parser can
> 'trip' and break the chain back to the user IP prematurely.

Speaking of tripping and naming a server when there's a user IP behind
it....

I found a set of headers^1 which involve a Received traceline by your
server which looks very noncompliant to me, and which would get your
server named instead of the user which relayed thru' it.

<partial headers>

Received: from ns1.pil.net (ns1.pil.net [208.8.16.10])
        by iq12.iqnection.com (Postfix) with SMTP id B55BA7E24
        for <[email protected]>;
        Tue, 20 Apr 2004 15:48:25 -0400 (EDT)
Received: (qmail 16043 invoked from network); 20 Apr 2004 19:51:01 -0000
Received: from unknown (HELO ambler) (151.197.26.29)
        by 0 with SMTP; 20 Apr 2004 19:51:01 -0000

Those headers show your server relaying for ambler 151.197.26.29  rDNS
pool-151-197-26-29.phil.east.verizon.net  because I believe ambler to be
amblertheater.org which you provide the MX for, so I'm betting that you
also provide the output for the amblertheater.

That bottom line is noncompliant.  SC would call the server 208.8.16.10
the source instead of the relay because the 'by' field of the bottom
line is deficient as '0' instead of the domainname of the relay.

If your server is still configured that way, I would fix it.


^1
http://mail-archives.apache.org/mod_mbox/spamassassin-users/200404.mbox/%[email protected]%3E

or http://snipurl.com/qdf0


-- 
Mike Easter
kibitzer, not SC admin