Bug 4516 - RCVD_BY_IP, RCVD_IN_BL_SPAMCOP_NET and RCVD_IN_SORBS_WEB are also applied to intermediate relays
Summary: RCVD_BY_IP, RCVD_IN_BL_SPAMCOP_NET and RCVD_IN_SORBS_WEB are also applied to ...
Status: RESOLVED WONTFIX
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Rules (show other bugs)
Version: 3.1.0
Hardware: PC Linux
: P5 normal
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-08-04 09:49 UTC by Luca Barbieri
Modified: 2008-02-28 04:25 UTC (History)
0 users


Attachment Type Modified Status Actions Submitter/CLA Status
Sample message text/plain None Luca Barbieri [NoCLA]
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Luca Barbieri 2005-08-04 09:49:22 UTC 
The RCVD_BY_IP, RCVD_IN_BL_SPAMCOP_NET and RCVD_IN_SORBS_WEB are applied not
only to the last SMTP relay, but also to previous ones listed in Received headers.

If this is intended, I think it is a very bad idea. RCVD_BY_IP will catch mail
programs unable to find an hostname, while RCVD_IN_BL_SPAMCOP_NET and
RCVD_IN_SORBS_WEB will result in hosts listed in that blacklists to have no way
of sending mail out without a positive spam score, regardless of the SMTP
service they use.

Furthermore, other blacklists seem to be only applied to the last relay, so
these two probably should too.
Comment 1 Justin Mason 2005-08-04 10:58:17 UTC 
please attach sample message(s) that exhibits this behaviour using the "Create
New Attachment" link.  I suspect there may be a trust path issue.
Comment 2 Luca Barbieri 2005-08-04 11:06:37 UTC 
Created attachment 3052 [details]
Sample message

This message was sent using Mozilla Thunderbird through the Gmail SMTP SSL
server using my Gmail account to my traditional ISP account at fastwebnet.it.
Comment 3 Justin Mason 2008-02-28 04:25:42 UTC 
RCVD_BY_IP: has been removed

RCVD_IN_BL_SPAMCOP_NET, RCVD_IN_SORBS_WEB: our opinion is that it makes sense
for these rules to fire if any of the untrusted relaying hosts hit these. I'm
afraid that's just part of SA's design...