You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by Stephan Menzel <sm...@gmx-gmbh.de> on 2006/03/28 17:08:59 UTC

Re: Trusted or internal networks not recognized

Am Dienstag, 28. März 2006 16:40 schrieb Bowie Bailey:
> > [32116] dbg: received-header: relay 10.1.76.29 trusted? no internal?
> > no
>
> Ok.  Show us the entire debug section where it parses the headers.
> Keep in mind that the interpretation of each header is influenced by
> the headers that precede it.  Once SA finds one untrusted relay,
> everything else is untrusted by definition.

Of course. That's why I mostly took emails for the test that only contain 
internal or trusted hops. This way I wanted to make sure not to be caught by 
this effect. However, I also places debug out into this section where this is 
checked. You see the message "Untrusted relay found"

Here is where I put this:

/usr/lib/perl5/vendor_perl/5.8.8/Mail/SpamAssassin/Message/Metadata/Received.pm:124

    # trusted_networks matches?
  $DB::single=2;

    if ($in_trusted && $did_user_specify_trust && !$relay->{auth} && !
$trusted->contains_ip ($relay->{ip}))
    {
      dbg("moep: untrusted relay found $relay->{ip}");
      $in_trusted = 0;          # we're in deep water now
    }

    # internal_networks matches?
    if ($did_user_specify_internal) {
      if (!$relay->{auth} && !$internal->contains_ip ($relay->{ip})) {
        dbg("moep: user did specify internal but $relay->{ip} is not in it");
        $in_internal = 0;
      }
    } else {
      # if the user didn't specify it, assume we immediately transition
      # to the external network (the internet) once we leave this host.
      dbg("moep: user did not specify internal");
      $in_internal = 0;
    }

[6250] dbg: plugin: Mail::SpamAssassin::Plugin::ReplaceTags=HASH(0x8bbd81c) 
implements 'finish_parsing_end'
[6250] dbg: replacetags: replacing tags
[6250] dbg: replacetags: done replacing tags
[6250] dbg: config: score set 0 chosen.
[6250] dbg: dns: dns_available set to no in config file, skipping test
[6250] dbg: moep: use trusted for internal
[6250] dbg: received-header: parsed as [ ip=10.1.76.29 rdns= 
helo=mp029.v300.gmx.net by=ih001.v300.gmx.net ident= envfrom= intl=0 id= 
auth= ]
[6250] dbg: moep: untrusted relay found 10.1.76.29
[6250] dbg: moep: user did specify internal but 10.1.76.29 is not in it
[6250] dbg: received-header: relay 10.1.76.29 trusted? no internal? no
[6250] dbg: received-header: parsed as [ ip=212.227.35.113 rdns= helo= 
by=www1.gmx.net ident= envfrom= intl=0 id= auth= ]
[6250] dbg: received-header: relay 212.227.35.113 trusted? no internal? no
[6250] dbg: metadata: X-Spam-Relays-Trusted:
[6250] dbg: metadata: X-Spam-Relays-Untrusted: [ ip=10.1.76.29 rdns= 
helo=mp029.v300.gmx.net by=ih001.v300.gmx.net ident= envfrom= intl=0 id= 
auth= ] [ ip=212.227.35.113 rdns= helo= by=www1.gmx.net ident= envfrom= 
intl=0 id= auth= ]
[6250] dbg: message: ---- MIME PARSER START ----
[6250] dbg: message: main message type: text/plain
[6250] dbg: message: parsing normal part
[6250] dbg: message: added part, type: text/plain
[6250] dbg: message: ---- MIME PARSER END ----
[6250] dbg: message: decoding other encoding type (8bit), ignoring
[6250] dbg: rules: local tests only, ignoring RBL eval


Yow the way I see it, contains_ip() doesn't work.
I postet some debugging results on dev@spamassassin.apache.org

Here's what I thought yesterday:

Mail::SpamAssassin::NetSet::contains_ip(/usr/lib/perl5/vendor_perl/5.8.8/Mail/SpamAssassin/NetSet.pm:146)

sub contains_ip {
  my ($self, $ip) = @_;

  if (!defined $self->{nets}) { return 0; }
  if ($ip !~ m/^\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}$/) { return 0; }

  $ip = Mail::SpamAssassin::Util::my_inet_aton($ip);
  foreach my $net (@{$self->{nets}}) {
    return !$net->{exclude} if (($ip & $net->{mask}) == $net->{ip})
  }
  0;
}

As far as I can see,  (($ip & $net->{mask}) == $net->{ip}) never gives true, 
even when $ip == $net->{ip}

I debugged through it with many different IPs and subnet settings and it 
didn't give true even once.

I'm about to prepare a workaround and a different implementation for this 
method but I'm no good in perl so it still gives me headaches.

Greetings...

Stephan