Spam and Virus defense

  • Now we will use the smtpd_*_restrictions in the main.cf. This are one key element to make your mailserver block spam and other unwanted mails.

blacklisting and greylisting
  • install the postgrey package and add it to smtpd_recipient_restrictions

    • test sending emails using telnet (from your host maschine) or a MUA to your virtual email address

      Tip

      this needs to be done without authentication

    • see how messages get blocked

    • try again in 10 min

    • send an email via your second mail server to an email account on your first system and watch the logs. Your mail server will try again until the mail is send to the intended mail account

    • Use either of postfix restart, postfix flush or postsuper -r QUEUEID to force resending

  • add some blacklists to your smtpd_recipient_restrictions

    • this can't be tested very well expect building your own blacklist server (beyond scope of current exercise)

    • Supply some common blacklist entries and pretend these will work.

Amavis, Clamav and Spamassasin
  • Install amavis, clamav and spamassasin.

  • configure amavis to use virus checking through clamav and spam checking through spamassasin

  • Configure postfix to use amavis. Add amavis to main.cf as content_filter. You also need to edit the master.cf.

  • send an EICAR-TEST-FILE to check that virus checking via amavis and clamav are working correctly.

  • try to send a Spam Test Mail

  • reconfigure the main.cf to use amavis as smtpd_proxy_filter instead of content_filter

    • what is the difference?

SPF (optional)

Where are plenty of Spam prevention techniques like DMARC, DKIM, DANE, Postscreen and other Policy Deamons (e.g. policyd-weight). Good Providers use most of them. We can't test all of them in SDI. They help to detect spam but not scam. So if Spammers use meine-dt-bank.de to obtain your PIN/TAN by a scam this mails could also use SPF or DKIM for there domain. So this techniques won't help there. The user is still responsible to detect such scams.

  • Add a SPF (Sender Policy Framework) Record to match mx and a to your DNS for your fantasy domain

  • test with dig or nslookup for your record

  • its a little bit hard to test this. if you want you could try to configure amavis to test for spf and set it to debug so that in the mail.log you'll see what amavis does

  • then send a mail from a mailadresse from your fantasy domain to an emailadresse on your server. your mailserver must use your own dns