Re: X-Originating-IP fires too much
On 2021-12-01 at 07:01:40 UTC-0500 (Wed, 1 Dec 2021 13:01:40 +0100) Matus UHLAR - fantomas is rumored to have said: > On 01.12.21 11:25, Matus UHLAR - fantomas wrote: >> hoping that adding sending IP Address to X-Originating-IP: header will help >> me fight against spam posted via webmail it seems I caused more problems >> than it was supposed to solve. >> >> mail sent from external IP 192.0.2.1 via webmail on 192.168.0.10, then pushed >> to SMTP server 192.168.0.10 (authenticated). > > this line is configured in (debian system): > > /etc/roundcube/plugins/additional_message_headers/config.inc.php > > $config['additional_message_headers']['X-Originating-IP'] = '[' . > $_SERVER['REMOTE_ADDR'] .']'; > > I see that adding mailserver local IP (192.168.0.10) to msa_networks will > hide the remote IP if the local IP is trusted/internal. That's why the *_networks config parameters exist: so that it is possible for SA to figure out which which recorded transit hop to both trust as accurately recorded and to interpret as a transfer from a potentially hostile sender. Is there some reason you would not want 192.168.0.10 in msa_networks? -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: X-Originating-IP fires too much
On Wed, Dec 01, 2021 at 01:52:16PM +0100, Matus UHLAR - fantomas wrote: > > > > > results > > > - ALL_TRUSTED doesn't fire because 192.0.2.1 in X-Originating-IP > > > > > > - HELO_NO_DOMAIN fires > > > - RDNS_NONE fires > > > - both because X-Originating-IP contains no helo/DNS data. > > > > > > any idea what could I do here, besides disabling X-Originating-IP > > > generation? One workaround might be to use "clear_originating_ip_headers" and then re-add all other headers except that one with "originating_ip_headers", eg.: clear_originating_ip_headers originating_ip_headers X-Yahoo-Post-IP X-Apparently-From originating_ip_headers X-SenderIP X-AOL-IP originating_ip_headers X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp This is not perfect beceuase it would ignore X-Originating-IP from everyone. Another perhaps cleaner solution is if your roundcube box is trusted not to send spam, to bypass spamassassin completely for outgoing mails from there. Or simply make a negative score meta rule for all mails identifying themselves as coming from your roundube (originating IP, X-mailer, SPF/DKIM passed etc.) that will undo the spam score it gets from other rules. -- Opinions above are GNU-copylefted.
Re: Managing long welcome_senders list
Shameless plug: https://mailfud.org/postpals/ On Fri, Dec 03, 2021 at 12:55:59PM +, Martin Gregorie wrote: > For Dominic Raferd: > > Another approach also works for me: if you can automatically capture the > addresses you've sent mail to, these addresses make a perfect, self- > maintaining whitelist. > > If you're running Postfix then you can use its automatic BCC option to > feed a copy of all mail, including outbound messages, whatever process > you use to build a list of your mail recipients. Other MTAs probably > have a similar ability, but I don't use them, so can't comment further. > > A database makes a convenient place to keep the your correspondent list > because discarding duplicate addresses then becomes a built-in facility > and writing an SA plugin plus associated rule to interrogate the list > and add negative points to the message is simple. > > My correspondent list is part of my mail archive, which is held as a > PostgreSQL database. The associated functions I use to maintain and > interrogate the correspondent list are: > > a) a BCC directive added to the Postfix configuration or the equivalent >if you use a different MTA > b) a Java application run each night to load the previous day's mail, >both received and sent, into the database > c) an SQL view that selects any message(s) in the archive that were sent >to the address being checked > d) a Perl plugin to execute the view using the message's sender as its >search key and return TRUE if any messages were selected > e) an SA rule to trigger the Perl plugin and add a negative score >if the Perl plugin returns TRUE > > You'd need code to implement all five functions, but if you store your > correspondent address list as a sorted text file, then all the code > would be much simplified: > > - 'b' could be a Perl or awk script run as an additional 'logwatch' > report that scans the previous day's part of the mail log, adds any > new addresses to the sorted list > > - 'c' and 'd' could be combined as a single Perl plugin. > > Martin >
Re: Managing long welcome_senders list
For Dominic Raferd: Another approach also works for me: if you can automatically capture the addresses you've sent mail to, these addresses make a perfect, self- maintaining whitelist. If you're running Postfix then you can use its automatic BCC option to feed a copy of all mail, including outbound messages, whatever process you use to build a list of your mail recipients. Other MTAs probably have a similar ability, but I don't use them, so can't comment further. A database makes a convenient place to keep the your correspondent list because discarding duplicate addresses then becomes a built-in facility and writing an SA plugin plus associated rule to interrogate the list and add negative points to the message is simple. My correspondent list is part of my mail archive, which is held as a PostgreSQL database. The associated functions I use to maintain and interrogate the correspondent list are: a) a BCC directive added to the Postfix configuration or the equivalent if you use a different MTA b) a Java application run each night to load the previous day's mail, both received and sent, into the database c) an SQL view that selects any message(s) in the archive that were sent to the address being checked d) a Perl plugin to execute the view using the message's sender as its search key and return TRUE if any messages were selected e) an SA rule to trigger the Perl plugin and add a negative score if the Perl plugin returns TRUE You'd need code to implement all five functions, but if you store your correspondent address list as a sorted text file, then all the code would be much simplified: - 'b' could be a Perl or awk script run as an additional 'logwatch' report that scans the previous day's part of the mail log, adds any new addresses to the sorted list - 'c' and 'd' could be combined as a single Perl plugin. Martin
Re: Managing long welcome_senders list
On 02/12/2021 16:26, Martin Gregorie wrote: On Thu, 2021-12-02 at 13:42 +, Dominic Raferd wrote: I have a score-reducing algorithm for SA based on known 'good' senders. From a simple one-address-per-line file (which can easily be manually or automatically edited) is built a local_welcoming.cf file which is used by SA - with lines like this: score LOCAL_WELCOMING_4 -4 header LOCAL_WELCOMING_4 From =~ /(\@myfriend\.com|jennifer_smith\@btinternet\.com|\ fred321@gmail\.com)>?\s*$/i I ran into this problem quite some time ago and wrote 'portmanteau'... Thanks to all for the suggestions and comments. I am looking into enlist_addrlist and portmanteau.
