bypass content-filter for email sent from localhost

Hi list,

I've googled it but am confused by the various responses.  What I'd
like seems to be pretty simple - to configure content-filter to be
bypassed if the message originates from localhost.

If anyone has a simple way to achieve this I'd appreciate the advice.

Cheers
Marc

Outbound RBL

We run a small cluster of postfix servers that are dedicated outbound
relayhosts for our customers.  Beyond the outbound postfix cluster we have
another cluster of mail filtering appliances that have served their purpose
very well, but we are starting to get more compromised account due to
phishing attempts and some of the spam is getting through the outbound
filters due to the volume of new spam messages.  

I am looking for advice on how to limit our exposure to malicious senders
that have access to a users credentials.  One method we have zero
experience in is using RBLs, which I am hoping to learn more about.

Re: Outbound RBL

On 1/31/2012 8:03 PM, list <at> airstreamcomm.net wrote:
> We run a small cluster of postfix servers that are dedicated outbound
> relayhosts for our customers.  Beyond the outbound postfix cluster we have
> another cluster of mail filtering appliances that have served their purpose
> very well, but we are starting to get more compromised account due to
> phishing attempts and some of the spam is getting through the outbound
> filters due to the volume of new spam messages.  
> 
> I am looking for advice on how to limit our exposure to malicious senders
> that have access to a users credentials.  One method we have zero
> experience in is using RBLs, which I am hoping to learn more about.
> 

Most people address this with sender rate limits using a policy
service such as policyd or postfwd, possibly combined with outbound
virus/spam scanning.
http://www.postfix.org/addon.html#policy

Once the rate limit (or outbound virus/spam limit) is tripped, the
account is flagged for an admin to check further, and maybe
temporarily disabled depending on site policy.

I'm not quite sure how an RBL would be useful here.

  -- Noel Jones

Re: Outbound RBL

On Tue, 31 Jan 2012 20:18:14 -0600, Noel Jones <njones <at> megan.vbhcs.org>
wrote:
> On 1/31/2012 8:03 PM, list <at> airstreamcomm.net wrote:
>> We run a small cluster of postfix servers that are dedicated outbound
>> relayhosts for our customers.  Beyond the outbound postfix cluster we
>> have
>> another cluster of mail filtering appliances that have served their
>> purpose
>> very well, but we are starting to get more compromised account due to
>> phishing attempts and some of the spam is getting through the outbound
>> filters due to the volume of new spam messages.  
>> 
>> I am looking for advice on how to limit our exposure to malicious
senders
>> that have access to a users credentials.  One method we have zero
>> experience in is using RBLs, which I am hoping to learn more about.
>> 
> 
> Most people address this with sender rate limits using a policy
> service such as policyd or postfwd, possibly combined with outbound
> virus/spam scanning.
> http://www.postfix.org/addon.html#policy
> 
> Once the rate limit (or outbound virus/spam limit) is tripped, the
> account is flagged for an admin to check further, and maybe
> temporarily disabled depending on site policy.
> 
> I'm not quite sure how an RBL would be useful here.
> 
> 

Re: Outbound RBL

On 1/31/2012 8:30 PM, list <at> airstreamcomm.net wrote:
> On Tue, 31 Jan 2012 20:18:14 -0600, Noel Jones <njones <at> megan.vbhcs.org>
> wrote:
>> On 1/31/2012 8:03 PM, list <at> airstreamcomm.net wrote:
>>> We run a small cluster of postfix servers that are dedicated outbound
>>> relayhosts for our customers.  Beyond the outbound postfix cluster we
>>> have
>>> another cluster of mail filtering appliances that have served their
>>> purpose
>>> very well, but we are starting to get more compromised account due to
>>> phishing attempts and some of the spam is getting through the outbound
>>> filters due to the volume of new spam messages.  
>>>
>>> I am looking for advice on how to limit our exposure to malicious
> senders
>>> that have access to a users credentials.  One method we have zero
>>> experience in is using RBLs, which I am hoping to learn more about.
>>>
>>
>> Most people address this with sender rate limits using a policy
>> service such as policyd or postfwd, possibly combined with outbound
>> virus/spam scanning.
>> http://www.postfix.org/addon.html#policy
>>
>> Once the rate limit (or outbound virus/spam limit) is tripped, the
>> account is flagged for an admin to check further, and maybe
>> temporarily disabled depending on site policy.
>>
>> I'm not quite sure how an RBL would be useful here.
>>

Re: Outbound RBL

On Tue, Jan 31, 2012 at 08:54:33PM -0600, Noel Jones wrote:
> On 1/31/2012 8:30 PM, list <at> airstreamcomm.net wrote:
> > What we were thinking was using RBLs to dynamically block known 
> > malicious IPs before allowing SMTP Auth to occur, hopefully 
> > seeing a decrease in spam.  Not sure if this would have 
> > unintended consequences, which is why I am consulting the list.
> 
> That would probably cause a huge number of false positives; a
> support desk nightmare.
> 
> Many "consumer" IPs are listed on the popular RBLs.  As a
> consequence, legit users may be unable to send mail because their
> dynamic IP was used by a spambot at some point in the past.
> 
> I don't know of any RBLs that would be useful on incoming
> authenticated mail.

Even a locally-maintained private DNSBL is the wrong approach. When
spam is detected from an authenticated account, revoke the
credentials. You have no other good choice. Even after the user's
system is purged of the ratware, you cannot be sure that these 
credentials were not forwarded to the botnet's control node[s].

Detection of a spamming account is done as Noel suggested, through 
rate limiting (and possibly behavioral monitoring) policy daemons. 
Content filtering of user-submitted mail is also important. Most 
malware will spew mail containing positive URIBL/SURBL hits. 
SpamAssassin can do this (I recommend using SA from amavisd-new.)

> You can test this yourself by inserting "warn_if_reject 

spy problem

Re: spy problem

Re: Outbound RBL

On Tue, Jan 31, 2012 at 09:44:22PM -0600, /dev/rob0 wrote:
> On Tue, Jan 31, 2012 at 08:54:33PM -0600, Noel Jones wrote:
> > On 1/31/2012 8:30 PM, list <at> airstreamcomm.net wrote:
> > > What we were thinking was using RBLs to dynamically block known 
> > > malicious IPs before allowing SMTP Auth to occur, hopefully 
> > > seeing a decrease in spam.  Not sure if this would have 
> > > unintended consequences, which is why I am consulting the list.
> > 
> > That would probably cause a huge number of false positives; a
> > support desk nightmare.
> > 
> > Many "consumer" IPs are listed on the popular RBLs.  As a
> > consequence, legit users may be unable to send mail because their
> > dynamic IP was used by a spambot at some point in the past.
> > 
> > I don't know of any RBLs that would be useful on incoming
> > authenticated mail.
> 
> Even a locally-maintained private DNSBL is the wrong approach. When
> spam is detected from an authenticated account, revoke the
> credentials. You have no other good choice. Even after the user's
> system is purged of the ratware, you cannot be sure that these 
> credentials were not forwarded to the botnet's control node[s].

Yes, however in our practice, there is good reasons to "block" the IP too
(if it's not our IP, then of course we have the chance to solve the
situation better with contacting the current user of the IP - anyway,
"not our IP pool" is quite a good sign that smtp username/passwd is
used illegally from there; for sure not always, but there is a good chance
for that):

* it's fairly common that the IP tries to abuse another smtp user of ours
  then in the future
* it helps decrease the load of the submit server: even if revoke user's
  crendentials, it has the cost (which is maybe more than using a locally
  stored mail submission IP blacklist like stuff) that user must be
  checked, etc. The "evil" IP still tries to send mail for hours (or even
  days - in our practice again) even after revokation of user's
  credentials, which can consume resources of the submit server.
  [that was the reason I thought about using postscreen for mail submission
  but only for BL features and using a "local" BL, so postfix smtpd
  processes, smtp auth stuffs etc are not under load because of these
  abusers/spammers]

We usually revoke submit user's credentials (of course), we inform the user
about the problem, and we block (with a locally stored list) of the IP which
abused the mail account, _if_ the IP does not seems to be part of our IP
pool, and either not the IP of "neighbour ISPs" in our country (which is
quite common that users use different local ISPs using the same ISP's mail
submission service though) and also seems to be a dynamic IP pool somewhere
or no PTR record, etc etc.

For sure, it's quite a "manual" work, and not always done just in extreme
cases when the IP does "really evil things".

> > You can test this yourself by inserting "warn_if_reject 
> > reject_rbl_client zen.spamhaus.org" just before 
> > permit_sasl_authenticated.  Then watch your logs for 
> > reject_warning: from legit connections.  (this is a
> > logging-only function; the client is not rejected and
> > sees no additional messages.)
> 
> Perhaps a slightly less insane ;) test would be to check 
> xbl.spamhaus.org at that point. But hotels and public hotspots are 
> often listed there. You might catch a few bad users, but you will 
> *not* have reasonable protection for clean users.

Of course I only wrote about a "local RBL" which is maintained by ourselves
for this purpose, not a general-purpose public BL.

Problem with rejecting mail to unknown users

Hi.

I'e got a problem I've been trying to solve for some time now, but I 
can't seem to get it to work. I'm running Postfix on FreeBSD with 
Maildrop delivery, SASL authentification and PostGreSQL backend. However 
I'm sending tons of backscatter because Postfix dosn't reject mail for 
unknown local recipients

I've tried setting local_recipient_maps and 
unknown_local_recipient_reject_code = 550 - Nothing seems to help 
though... Anyone with some pointers as to where I should look for the error?

# postconf -n

alias_maps =
broken_sasl_auth_clients = yes
command_directory = /usr/local/sbin
config_directory = /usr/local/etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10026
daemon_directory = /usr/local/libexec/postfix
data_directory = /var/db/postfix
debug_peer_level = 2
html_directory = /usr/local/share/doc/postfix
in_flow_delay = 0
local_recipient_maps = 
proxy:pgsql:/usr/local/etc/postfix/local_recipient_maps
mail_owner = postfix
mailq_path = /usr/local/bin/mailq
manpage_directory = /usr/local/man
message_size_limit = 41943040
mydestination =
mynetworks = 10.10.10.0/24, 127.0.0.0/8
newaliases_path = /usr/local/bin/newaliases
proxy_interfaces = 194.255.69.21
proxy_read_maps = $local_recipient_maps $mydestination 
$virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps 
$virtual_mailbox_domains $relay_recipient_maps $relay_domains 
$canonical_maps $sender_canonical_maps $recipient_canonical_maps 
$relocated_maps $transport_maps $mynetworks $smtpd_sender_login_maps 
$smtp_sasl_password_maps
queue_directory = /var/spool/postfix
readme_directory = /usr/local/share/doc/postfix
relay_domains = proxy:pgsql:/usr/local/etc/postfix/relaydomainmap
relay_recipient_maps = proxy:pgsql:/usr/local/etc/postfix/relayaliasmap
sample_directory = /usr/local/etc/postfix
sendmail_path = /usr/local/sbin/sendmail
setgid_group = maildrop
smtpd_recipient_restrictions = permit_sasl_authenticated, 
permit_mynetworks, reject_unauth_destination, reject_unlisted_recipient
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_local_domain = pixelpoint.dk
smtpd_sasl_path = smtpd
smtpd_sender_login_maps = proxy:pgsql:/usr/local/etc/postfix/saslmap
smtpd_tls_auth_only = no
smtpd_tls_cert_file = /usr/local/share/courier-imap/imapd.pem
smtpd_tls_key_file = /usr/local/share/courier-imap/imapd.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_use_tls = yes
transport_maps = proxy:pgsql:/usr/local/etc/postfix/mxmap
unknown_local_recipient_reject_code = 550
virtual_alias_maps = proxy:pgsql:/usr/local/etc/postfix/aliasmap
virtual_mailbox_domains = proxy:pgsql:/usr/local/etc/postfix/domainmap
virtual_transport = maildrop

master.cf:
#
# Postfix master process configuration file.  For details on the format
# of the file, see the master(5) manual page (command: "man 5 master").
#
# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================
smtp      inet  n       -       n       -       -       smtpd
   -o content_filter=smtp-amavis:[127.0.0.1]:10024
   -o smtp_send_xforward_command=yes
submission inet n       -       n       -       -       smtpd
#  -o smtpd_enforce_tls=yes
   -o smtpd_etrn_restrictions=reject
   -o smtpd_sasl_auth_enable=yes
   -o smtpd_client_restrictions=permit_sasl_authenticated,reject
   -o content_filter=smtp-amavis:[127.0.0.1]:10026
#smtps     inet  n       -       n       -       -       smtpd
#  -o smtpd_tls_wrappermode=yes
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#628      inet  n       -       n       -       -       qmqpd
pickup    fifo  n       -       n       60      1       pickup
cleanup   unix  n       -       n       -       0       cleanup
qmgr      fifo  n       -       n       300     1       qmgr
#qmgr     fifo  n       -       n       300     1       oqmgr
tlsmgr    unix  -       -       n       1000?   1       tlsmgr
rewrite   unix  -       -       n       -       -       trivial-rewrite
bounce    unix  -       -       n       -       0       bounce
defer     unix  -       -       n       -       0       bounce
trace     unix  -       -       n       -       0       bounce
verify    unix  -       -       n       -       1       verify
flush     unix  n       -       n       1000?   0       flush
proxymap  unix  -       -       n       -       -       proxymap
smtp      unix  -       -       n       -       -       smtp
# When relaying mail as backup MX, disable fallback_relay to avoid MX loops
relay     unix  -       -       n       -       -       smtp
         -o fallback_relay=
#       -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
showq     unix  n       -       n       -       -       showq
error     unix  -       -       n       -       -       error
retry     unix  -       -       n       -       -       error
discard   unix  -       -       n       -       -       discard
local     unix  -       n       n       -       -       local
virtual   unix  -       n       n       -       -       virtual
lmtp      unix  -       -       n       -       -       lmtp
anvil     unix  -       -       n       -       1       anvil
scache    unix  -       -       n       -       1       scache
#
# ====================================================================
# Interfaces to non-Postfix software. Be sure to examine the manual
# pages of the non-Postfix software to find out what options it wants.
#
# Many of the following services use the Postfix pipe(8) delivery
# agent.  See the pipe(8) man page for information about ${recipient}
# and other message envelope options.
# ====================================================================
#
# maildrop. See the Postfix MAILDROP_README file for details.
# Also specify in main.cf: maildrop_destination_recipient_limit=1
#
maildrop  unix  -       n       n       -       -       pipe
   flags=DRhu user=courier:courier argv=/usr/local/bin/maildrop -w 90 -d 
${recipient}
#
# ====================================================================
#
# The Cyrus deliver program has changed incompatibly, multiple times.
#
#old-cyrus unix  -       n       n       -       -       pipe
#  flags=R user=cyrus argv=/cyrus/bin/deliver -e -m ${extension} ${user}
#
# ====================================================================
#
# Cyrus 2.1.5 (Amos Gouaux)
# Also specify in main.cf: cyrus_destination_recipient_limit=1
#
#cyrus     unix  -       n       n       -       -       pipe
#  user=cyrus argv=/cyrus/bin/deliver -e -r ${sender} -m ${extension} 
${user}
#
# ====================================================================
#
# See the Postfix UUCP_README file for configuration details.
#
#uucp      unix  -       n       n       -       -       pipe
#  flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail 
($recipient)
#
# ====================================================================
#
# Other external delivery methods.
#
#ifmail    unix  -       n       n       -       -       pipe
#  flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
#
#bsmtp     unix  -       n       n       -       -       pipe
#  flags=Fq. user=bsmtp argv=/usr/local/sbin/bsmtp -f $sender $nexthop 
$recipient
#
#scalemail-backend unix -       n       n       -       2       pipe
#  flags=R user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store
#  ${nexthop} ${user} ${extension}
#
#mailman   unix  -       n       n       -       -       pipe
#  flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py
#  ${nexthop} ${user}

#start virusscan
smtp-amavis unix -      -       n       -       -  smtp
     -o smtp_data_done_timeout=1200
     -o disable_dns_lookups=yes

127.0.0.1:10025 inet n  -       n       -       -  smtpd
     -o content_filter=
     -o local_recipient_maps=
     -o smtpd_helo_restrictions=
     -o smtpd_client_restrictions=
     -o smtpd_sender_restrictions=
     -o smtpd_recipient_restrictions=permit_mynetworks,reject
     -o mynetworks=127.0.0.0/8
#    -o virtual_alias_maps = proxy:pgsql:/usr/local/etc/postfix/aliasmap
#end virusscan
proxywrite unix -       -       n       -       1       proxymap
#smtp      inet  n       -       n       -       1       postscreen
#smtpd     pass  -       -       n       -       -       smtpd
#dnsblog   unix  -       -       n       -       0       dnsblog
#tlsproxy  unix  -       -       n       -       0       tlsproxy

--

-- 
Best regards
Martin Kruse Jensen