https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6501
Andrew W <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrew.lis...@silverstream. | |net.nz --- Comment #2 from Andrew W <[email protected]> 2010-10-19 20:41:07 UTC --- (In reply to comment #1) > (In reply to comment #0) > > Currently, if a webmail user sends a message through a host running > > SpamAssassin, the RCVD_IN_PBL rule is triggered, upping the spam score. > > This sounds like you are scanning outbound mail -- or inbound mail from your > own users, to your users, which equals outbound for the sender. Yes, as extra insurance to ensure I do not want to fall foul of my upstream vendor's spam policy. The path is: client via the public internet uses HTTPS connection to Zimbra webmail on my network; Zimbra then queues it up and delivers it to my qmail host with spamassassin; qmail host scans then continues delivery via my ISP. > SA does *not* do deep-header parsing for DNS BLs that are not meant for this. > That includes PBL, which is only checked against the untrusted / external > handing-over IP address. > Your sample indicates the message indeed has been sent from a dial-up IP > directly to your network. A webmail user, logged in from home on the PBL'd address, sends a message. The webmail host is on my network, as is this mailserver, both on the same private subnet. It has not passed through any dial-up users via SMTP. > The common cure for this is to use authentication. It's webmail, therefore authenticated? SMTP is not authenticated between the webmail host and the qmail host it is via a trusted connection over my private subnet. > Note, that in your case, while having the X-Originating-IP header, there is no > Received header even claiming the message was submitted via HTTP. But ESMTP > (not authenticated). That's Zimbra queueing to itself before sending. > I believe this to be a trusted / internal networks configuration issue, or > missing authentication. Not a bug. I have a non-spamassassin-scanned copy of the original e-mail saved as a file for the purpose of running spamassassin -t against it. It behaves as above. If I make a copy of that file, and remove only the X-Originating-IP header, then the PBL rule doesn't get applied. I even get "ALL_TRUSTED" instead. So the problem goes away if the X-Originating-IP header goes away, which is what led me to believe this is a bug. Should that happen if it were a authentication issue? -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
