Re: Parsing Received Headers

Bret,

Bret Miller wrote:
>
> Or perhaps I should just open a bug ticket to fix SA's "not understanding"
> problem...
>

(Also posted to CGP mailing list)

If you are receiving false-positives with CGP and the SpamAssassin 3.2.x RDNS_NONE test ...

If SpamAssassin 3.1.x cannot identify RDNS data in a "Received: from" header (due to formatting or omission) it would perform a RDNS lookup itself. That functionality has been removed from SpamAssassin 3.2.x as per:

    http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5054

The author comments: "we can move that lookup out to the eval test that uses it, pretty easily", but the RDNS_NONE test (among others) in 20_dynrdns.cf (among others) continues to just parse the X-Spam-Relays-Untrusted header set in SpamAssassin/Message/Metadata/Received.pm. You can re-enable that feature using the following patch.

Do you need help?
In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related spamassassin.apache.org Links users Request more information about Pantek

80,83d79

<   # TJK Restore SA RDNS Resolution for CGP.
<   $self->{permsgstatus} = $permsgstatus;
<   $self->{is_dns_available} = $self->{permsgstatus}->is_dns_available();
<
1249,1258c1245
<       # TJK Restore SA RDNS Resolution for CGP.
<       if ($self->{is_dns_available}) {
<         $rdns = $self->{permsgstatus}->lookup_ptr($ip);
<         if (! $rdns) {
<           $rdns eq '';
<           $relay->{rdns_not_in_headers} = 1
<         }
<       } else {
<         $relay->{rdns_not_in_headers} = 1;
<       }
---

>       $relay->{rdns_not_in_headers} = 1;

Note that the "verified" flag that CGP sets in the "Received: from" header denotes the status of the HELO command, not the RDNS of the connecting host.

---

Example:

Single sending host with an IP address of 123.456.789.200.

DNS:

name-x.source.com A 123.456.789.100
name-y.source.com A 123.456.789.200
name-z.source.com A 123.456.789.300

Reverse DNS:

123.456.789.100 PTR name-x.source.com
123.456.789.200 PTR name-z.source.com
123.456.789.300 PTR name-z.source.com

telnet cgp.destination.com 25
HELO 123.456.789.100
Received: from [123.456.789.200] (HELO 123.456.789.100) by
cgp.destination.com
# unverified HELO: 123.456.789.100 communicated from 123.456.789.200

telnet cgp.destination.com 25
HELO name-x.source.com
Received: from [123.456.789.200] (HELO nameof-123.456.789.101.com) by
cgp.destination.com
# unverified HELO: name-x.source.com aka 123.456.789.100 communicated from
123.456.789.200

telnet cgp.destination.com 25
HELO name-y.source.com
Received: from name-y.source.com ([123.456.789.200] verified) by
cgp.destination.com
# verified HELO: name-y.source.com aka 123.456.789.200 communicated from
123.456.789.200
# but reverse of 123.456.789.200 is name-z.source.com

--

Tom Kishel
Dark Horse Comics

-- 
View this message in context: 
http://www.nabble.com/Parsing-Received-Headers-tf4361839.html#a12827592
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.