Disable Spam Checks on Outbound Email

[John Hinton]

Patrick! This is most excellent. I think it finally sinks into my too 
often times thick skull.

On 5/22/2012 1:09 AM, Patrick Ben Koetter wrote:
> John,
>
> * John Hinton<webmaster at ew3d.com>:
>> Seems I'm finding all sorts of answers to this Googling it, so
>> figured I'd ask here. My systems are virtual hosting environments.
>> Many times one of our users will land on a 'dirty' IP address where
>> someone sent spam a day or two before and so they are suddenly on a
>> blacklist or few.
>>
>> I am running CentOS, Postfix, Dovecot and Amavisd-new. I have a
>> typical Postfix virtual file and virtual.db. These list email
>> address and user... typical. So, I'm wondering if I simply direct
> Any message to a virtual.db recipient address is inbound, but it doesn't tell
> you about the sender, which is what you want in order to disable spam scanning
> (and for other reasons such as DKIM signing).
>
>> @bypass_spam_checks_maps to that file or maybe there is some other
>> wildcard for any authed smtp user so I stop the filtering on
>> outbound? Or is there any other good (aka simple) method for this?
> There is no wildcard.
>
>> Some were even opening additional ports which seems a long way
>> around to the solution.
> If you are using SMTP to send messages to amavis, then you have two ways to
> let amavis know a sender is local (and amavis should not scan for them):
OK, this was my duh moment. So Amavis has no way to know where the email 
originated, it only knows 'an email' has been sent to it from Postfix 
and goes to work on that.
>
> 1. static IP
> Add the senders client IP to @mynetworks or even better add it to a section in
> @client_ipaddr_policy and assign that section to a policy_bank. Then set a
> policy in that policy_bank that stops spam scanning:
>
> $policy_bank{'CUSTOMERS'} = {
>      originating =>  1,
>      bypass_spam_checks_maps   =>  [1], # No SPAM checks
>      bypass_banned_checks_maps =>  [1], # No Banned Files checks
>      final_virus_destiny =>  D_REJECT,
>      final_bad_header_destiny =>  D_PASS,
>      banned_filename_maps =>  ['MYNETS-DEFAULT'],
>      warnbadhsender =>  1,
> };
>
I would doubt that even 10% of our users have a static IP address (and 
those don't have this problem to start with as we don't host spammers). 
Add to that the mobile world and IP addresses are all over the place. 
So, I could only grab dynamically from maillogs IP addresses from 
successful auth logins to create a map of those IP addresses in use at 
that moment. It seems to me this is not a good solution for a number of 
reasons, as long as IP addresses are dynamic, which again, is the entire 
problem, dirty networks. Lets not build a tower so we can put a light on 
top of it so a plane won't hit it.
> 2. dynamic IP
> Sorting senders with dynamic IP out is a little more work. There's no way to
> tell they are local by their IP. So you need to let them send over a dedicated
> port in order to identify them.
>
> Let users with dynamic IP send over port 587 (submission) in Postfix. Send
> their messages to a differerent port in amavis. Assign that port to a
> policy_bank. Disable spam checking.
>
> Here's an example we use on some servers:
>
> # master.cf
> submission inet n       -       n       -       32       smtpd
>      -o smtpd_proxy_filter=[127.0.0.1]:10026
>      -o anvil_rate_time_unit=30s
>      -o smtpd_client_connection_count_limit=16
>      -o smtpd_delay_reject=yes
>      -o smtpd_sasl_auth_enable=yes
>      -o smtpd_recipient_restrictions=$submission_recipient_restrictions
>      -o smtpd_tls_security_level=may
>      -o milter_macro_daemon_name=ORIGINATING
>      -o smtpd_banner=$smtpd_submission_banner
>
>
> # amavisd.conf
> # Open a port
> $inet_socket_port = [9998,10024,10026];
> # Assin the port to a policy
> $interface_policy{'10026'} = 'CUSTOMERS';
> # use the policy from my example above.
And so this explains the need for the additional port. A method for 
Postfix to tell Amavis something different about the email it is 
receiving, such as the case of a local user. For my situation, the 
cleanest method of the two.

And again, thank you for this email. It is well laid out and explains 
the situation clearly. My Googling took me all over the place with 
confusing answers, some of which I'm not sure would work or well, 
sometimes searches just don't clear up anything.
>
> HTH
Yes, the fog has lifted! ;)
>
> p at rick
>
>


-- 
John Hinton
877-777-1407 ext 502
http://www.ew3d.com
Comprehensive Online Solutions