[Wiltshire] Fed up of deleting zip file junk

[Simon Iremonger (wiltslug)]

On 2016-08-29 17:28, David Fletcher via Wiltshire wrote:
> Getting really hacked off with all of the jerks out there sending out
> spam with presumably windows virus infected zip files attached.
I wouldn't get _personally_ hacked-off...

> Actually, I've not had a legitimate email with a zip file attachment in
> a very long time so I'm thinking of implementing this on my postfix
> Configuration line in main.cf
> Question is, if I also implement a postfix white list, will the white
> list override the reject mechanism to allow delivery of zip or other

Possible, at least its' possible to do virtually anything like that
with postfix multi_instance but depending what you want it can get
'messy'.

I certainly had overrides for check_recipient_access rules at the
least...

What I would say, however, is that this may not be best best approach.



I would say, in the current public-internet-email climate, some
amount of 'being picky about who you talk to' is really *needed*/
*sensible*, the following works well:-

* Reject from servers that can't say HELO properly (or other protocol
    outright violations)
* Reject 'from' addresses that are aren't a full name [somebody at name],
    don't exist in DNS [somebody at invalid.name], or are hosted locally
    but are invalid [wrongname at thefletchers.net].
* Reject from all servers without a forward-confirmed-reverse-DNS
    (unless whitelisted, but I don't seem to need that any more).
    [e.g. gmail does this on ipv6]
* Reject from servers listed in zen.spamhaus.org.
    (seem very reliable, they supply JANET blacklist too...)

* don't talk to same address too many times at once

In addition, (which can be overridden for specific recipient
    email addresses), you can do well to:-
* Apply greylisting
    (unless whitelisted server or whitelisted-recipient-address).
    [this makes the other server retry once at first, before
    then being accepted, though SOME people rather insist on more
    instant-email in all cases and don't like this.]



(This 'pickyness' can be achieved with the following recipe:-

  (a) install "postgrey"

  (b) Change /etc/default/postgrey to have something like:-
POSTGREY_OPTS="--inet=127.0.0.1:10023 --greylist-action=450 --delay=90
--retry-window=16h"

    [this makes postgrey more lenient / faster to accept mail]
    [the '450' action rather than default DEFER_IF_PERMIT is useful,
       stops further querying blacklists usage-limits etc. until
       greylist stage 'passed'.]

  (c) Then, in /etc/postfix/main.cf (this is cut down version):-

=====================================================================
#(smtp connect)
smtpd_client_connection_count_limit = 4
 #maximum 4 connections per IP
smtpd_client_connection_rate_limit = 16
 #maximum 16 connections per IP per minute
smtpd_client_restrictions =
  reject_unknown_reverse_client_hostname
  reject_unknown_client_hostname
  permit
unknown_client_reject_code = 577

#HELO/EHLO
smtpd_helo_required = yes
smtpd_helo_restrictions =
 reject_invalid_helo_hostname
 reject_non_fqdn_helo_hostname
 permit

#MAIL FROM
smtpd_reject_unlisted_sender = yes
smtpd_sender_restrictions =
 reject_non_fqdn_sender
 reject_unknown_sender_domain
 reject_unlisted_sender
 permit

#RCPT TO
smtpd_reject_unlisted_recipient = yes
smtpd_recipient_limit = 100
 #upto 100 Recipients on any email
smtpd_client_message_rate_limit = 50
 #allow upto 50 RCPT_TO per anvil time (1 minute).
smtpd_recipient_restrictions =
 reject_non_fqdn_recipient
 reject_unknown_recipient_domain
 reject_unlisted_recipient
 permit_mynetworks
 reject_unauth_destination
 check_policy_service inet:127.0.0.1:10023
 reject_rbl_client zen.spamhaus.org
 permit

#DATA
smtpd_data_restrictions =
 reject_unauth_pipelining
 permit
=====================================================================

(d) restart postgrey then postfix...


(I have slightly more complicated version with various overrides
  (independent whitelists for each section and a general IP blacklist)
  and remote recipient-address-verification on split-servers etc
  etc...!).

Don't be put off by the amount of 'stuff' above, much of which can
be reduced.  Also, be careful not to conflict with any existing
config directives you already have in config (especially check
what your 'existing' smtpd_recipient_restrictions is).



Even with all the 'pickyness' above (which REALLY works!!!!),
its' possible to 'filter' better by e.g.:-

* Use a milter or smtp-proxy to reject-at-smtp-time or
    filter-out after-acceptance emails that don't pass a
    virus-scanner.
    (For example, sophos-for-linux 'free' works well, clamav can
    work well if enough ram (can be slow/clunky)).

* Use spamassassin scanning and reject very high scores (over 20)
    outright.



[I'm soon going to try out the milter arrangement and tidy-up the
whole setup etc etc....]

> Dave
--Simon