there are a number of bugs about RCVD_IN_PBL triggering on Received: or
X-Originating-IP: lines it is not supposed to parse anyway because they do not
originate from the trusted network.

(bug 6403, bug 7132, bug 6501, bug 6334, bug 7101 all look like that)

while the wiki page[1] is quite clear about what the PBL means, it is of no
help to admins who misconfiured their server, and now either try to make the
mail authors use delivery instead of smtp (might work for individuals), to make
the big mail providers indicate authentication (good luck with that) or to get
spamassassin patched to accept "via HTTP" as indicatiing authentication.

if my freshly-built understanding of the applicability of the RCVD_IN_PBL rule
is correct and correctly reflected in the below sniplet, please consider adding
that to [1] to guide admins to the real causes of their high spam scores.

[1] https://wiki.apache.org/spamassassin/Rules/RCVD_IN_PBL


=== Common causes ===

If this rule triggers based on mails received from large mail providers (eg.
United Internet / GMX or Google), chances are that SpamAssassin has a wrong
view of what constitutes the local network. Unless SpamAssassin runs on, for
example, a United Internet server, the `Received:` lines indicating that some
United Internet server has taken up the message from a dynamic IP (no matter
what that line says about authentication credentials) should not be evaluated;
RCVD_IN_PBL is a last_internal rule. (It should trigger, however, if a server
under local administration has accepted the message from a dynamic IP without
indicating that proper authentication has happened).

In such situations, make sure that the TrustPath is configured correctly, and
that SpamAssassin is actually working on the right headers (which can be an
issue with some spamass-milter configurations).