Spam fighting

Keeping own mail server can be rather painful because of spam. Very good spam fighting techniques can be found on ACME website.

My setup and techniques are following:

• One trick is undeliverable MX records:

  stargrave.org mail is handled by 10 mailfake0.stargrave.org.
  stargrave.org mail is handled by 40 mailfake2.stargrave.org.
  stargrave.org mail is handled by 30 mail2.stargrave.org.
  stargrave.org mail is handled by 20 mailfake1.stargrave.org.
  

  mailunexistent domains exist, have an address, but no daemon listens on them. Most robots will connect only to the first MX.

• Check for reverse DNS record works very good.
• SPF checking. Most mail servers do not provide SPF information, so SPF fail-rate is very low. However some mails do not passs.
• Postfix configuration options that work relatively good:

  disable_vrfy_command = yes
  strict_rfc821_envelopes = yes
  smtpd_helo_required = yes
  smtpd_recipient_restrictions =
      permit_mynetworks,
      reject_unauth_pipelining,       # Do not allow PIPELINE at all
      reject_non_fqdn_helo_hostname,  # Reject HELO with non FQDN
      reject_invalid_helo_hostname,   # Reject malformed HELO
      reject_unauth_destination,      # Reject unknown destination
      reject_unknown_client_hostname, # check IP->name mapping,
                                      # check name->address mapping,
                                      # check name->address match
      check_policy_service inet:127.0.0.1:10023,   # Greylist
      check_policy_service unix:private/spf-policy # SPF
  smtpd_client_restrictions = sleep 5, reject_unauth_pipelining
  smtpd_delay_reject = no
  
  # Some mail are rejected at all from some domains
  smtpd_sender_restrictions = hash:/usr/local/etc/postfix/access
  

• Greylisting weapon. This works very well, however can highly increase legitimate mail delivery time for the first time.
• I refuse to use any blacklists (RBL, DNSBL), because in that case delivery of email is under control of someone external. I do not trust them. Moreover there is high risk of false positives. I do not like when people use this technology, marketing bullshit, unfair play.
• I used SpamAssassin for a while, but stopped do that. Is requires time to support, to work with. Some email messages are processed fine, but false positives also exist. It gave too low profit at the cost of resources and time needed for its configuration.
• Own manual maildrop rules that places mail directly into /dev/null, or spam folder. I check spam folder once or twice a week and quickly wipe it if visually it have obvious spam. For me it is easier to maintain maildrop configuration from time to time, than work with SpamAssassin again.