https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7805

hnsupport <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|NEW                         |RESOLVED

--- Comment #15 from hnsupport <[email protected]> ---
(In reply to hnsupport from comment #14)
> (In reply to RW from comment #12)
> > You appear to have 192.254.118.54 in your trusted_networks, and since you
> > haven't defined internal_networks explicitly, it gets copied from
> > trusted_networks. Presumably you haven't added the private address ranges to
> > trusted_networks which makes 10.30.65.95 look like the last-external IP
> > address.
> > 
> > Others see the spf pass because they don't have 192.254.118.54 in
> > internal_networks, and so, correctly, see that IP address as last-external.
> 
> Interesting: thanks RW, sounds promising!  And like an environmental issue,
> of course...
> 
> I'll re-read the documentation for those directives more carefully, and
> define internal_networks / redefine trusted_networks as appropriate.
> 
> Thanks again.

Just to follow up here: that was exactly the problem.  I've done a RADB lookup
to find all of our subnets, put them in internal_networks for an initial test,
and the proper relay is once again evauluated:

====
Content analysis details:   (8.6 points, 10.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
 0.0 URIBL_BLOCKED          ADMINISTRATOR NOTICE: The query to URIBL was
                            blocked.  See
                           
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
                             for more information.
                            [URIs: zendesk.com]
 3.0 BAYES_50               BODY: Bayes spam probability is 40 to 60%
                            [score: 0.4277]
-0.1 SPF_PASS               SPF: sender matches SPF record
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 0.1 HTML_MESSAGE           BODY: HTML included in message
-0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily
                            valid
 2.0 DKIM_INVALID           DKIM or DK signature exists, but is not valid
 3.7 TXREP                  TXREP: Score normalizing based on sender's
reputation
====

Thanks again, closing this out.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to