SMTP configuration

Mail Server Configuration
I run my own mail servers, and use the following software:

SMTP incoming: postfix SMTP submission: postfix IMAP: dovecot (version 2) SASL authentication: Dovecot webmail: roundcube anti-spam: Spamassasin anti-virus: clamAV SPF verification: postfix-policyd-spf-python Greylisting: postgrey (currently not in use) Mailing lists: Mailman (currently not in use) Server-based filtering: procmail

Most choices are rather traditional. Postfix is a traditional choice. I heard Exim is slightly easier to configure, but since I'm already familiar with Postfix, that's probably easiest for me. Dovecot is new to me. I previously used Courier, and I'm pleased I made the switch. Note that SMTP submission requires a SASL authentication server, and both Courier and Cyrus provide one. The Dovecot version is much more lightweight (which is good for security), but most online tutorials assume you will use Cyrus. Roundcube is just a fancier-looking alternative to SquirrelMail, which I used in the past.

I've replaces all occurances of macfreek.nl (my actual domain) with example.net, just to avoid spam to my domain.

Port numbers
25  SMTP 143 IMAP 587 submission

465 SMTPS (not used) 993 IMAPS

10023 greylisting 10024 amavis 10025 re-insertiong after amavis

Backscatter Prevention
Just like your mailhost should not be an open relay, it should make sure not to send backscatter, error mails to spoofed sender addresses.

Backscatter occurs when your mail hosts first accepts a message, but later decides to reject it, and replies with an error message to the original sender. Since the original sender is often forged, this means that your mailhost sends mail to someone who didn't actually send the mail. Effectively, this means that your mail server is sending out a specific type of spam, backscatter. Sending backscatter is considered bad, and may cause your mailserver to end up on anti-spam listings because of it.

To prevent backscatter, two important guidelines exist:
 * Let the sender know if the mail is accepted or rejected while the sender is connected. Don't wait with processing.
 * The backup mail server must do the same checks as the primary mail server. Mail from the backup to the primary server should be accepted outright.

Installation of Postfix and Dovecot
aptitude install postfix aptitude install dovecot-imapd

As a first step, set up network specifics in /etc/postfix/main.cf. In my case: myorigin = govert.example.net myhostname = govert.example.net mydestination = govert.example.net, localhost.example.net, localhost relayhost = mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 85.214.18.218/32 [2a01:238:43ed:a300:ea00:54c2:fb7a:7e66]/128 inet_interfaces = all inet_protocols = all smtpd_banner = $myhostname ESMTP $mail_name append_dot_mydomain = no
 * 1) Listen on IPv4 and IPv6
 * 1) Greeting text. Enough for debugging, not enough for potential hackers
 * 1) appending .domain is the MUA's job.

The mynetworks parameters lists the IP address of the host. You may consider also adding the IP address of your backup mail server. In my case, I use  in the smtp restrictions.

Maildirs are used for delivery to local users: home_mailbox = Maildir/ mailbox_size_limit = 0 biff = no
 * 1) Deliver to mail dirs

Email Address
The above settings allows mail delivery to e.g. localuser@govert.example.net. (where localuser is a local accountname, and govert.example.net is the name of the machine). The virtual table translates between full email addresses and usernames. E.g.:

In /etc/postfix/main.cf: virtual_alias_maps = hash:/etc/postfix/virtual alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases
 * 1) virtual aliases: mail forwarding for multiple domains
 * 2) virtual_alias_domains = $virtual_alias_maps

is used to list the domains that are "virtual", and should be looked up with. You can specify a file and list each domain on a line. The default however is the same as. This means that the /etc/postfix/virtual file both contain the domains, as well as the email addresses. Since /etc/postfix/virtual is a hash, you need add a lookup value for each domain. This values is ignored and can be anything. In my case I use the word " ".

/etc/postfix/virtual: example.net                   VIRTUALDOMAIN webmaster@example.net         freek freek@example.net             caroline freekandcaroline@example.net  freek,caroline

It is important to also contain this exact list at your backup mail server. Do not simply add your mail domains to the  parameter in Postfix. That would allow backscatter, since the backup server would accept all mail, but when it is forwarded to the primary server it could get rejected. After rejection, Postfix replies with an error message to the (most likely forged) sender address.

Aliases finally contains the relation between username and delivery names. It is usually used to reroute mail for "root" to another user account. E.g. /etc/aliases: abuse:         postmaster spam:          postmaster nobody:        root security:      root postmaster:    root hostmaster:    root root:          freek

There is one other very useful use for /etc/aliases. On my backup server, it contains a line to forward mail to my primary server. That is the only difference between my primary and backup mail server. Everything else is exactly the same!

abuse:         postmaster spam:          postmaster nobody:        root security:      root postmaster:    root hostmaster:    root root:          freek freek:         freek@primarymx.example.net

If all works well, remember to set the MX records in DNS. By the time you set this up, I recommend you configure it for a domain which normally does not receive email. You will see the spam trickling in, and have some time to make sure your configuration holds (and is able to block the spam). If all works well, you can migrate your main domains.

I use a small SMTP test script to test my configuration.

Temporary mail addresses
I'm using temporary mail address for situations where I don't want to leave my regular mail address somewhere. In my case, I simply add a year, month or even day after my regular mail name. E.g.

username201109@macfreek.nl

where  is my primary account name, and   is the date. A cron job runs daily to add these mail addresses in.

A daily cron jobs runs the script tempmailalias.php to add the temporary mail addresses to the  file.

TLS Encryption and SASL Authentication
Encryption is used for mail submission, IMAP, and webmail. I use a single certificate for this server, which is signed by CAcert. I consider CAcert slightly more trustworthy than creating my own CA, despite that the CAcert root certificate is not yet included in most browsers. For more security, consider adding a pointer to your certificate in DNS using DANE.

Beside encrypting these connections, the client must authenticate these connections, thus provide username and password. The SASL implementation of Dovecot is used for authentication, not the (more often used) Cyrus software.

In /etc/postfix/main.cf: smtpd_tls_cert_file=/etc/ssl/govert.example.net.crt smtpd_tls_key_file=/etc/ssl/private/govert.key smtp_tls_security_level=may smtpd_sasl_security_options = noanonymous, noplaintext smtpd_sasl_tls_security_options = noanonymous smtpd_tls_auth_only = yes smtpd_sasl_local_domain = $myhostname broken_sasl_auth_clients = no
 * 1) TLS parameters
 * 1) Allow TLS between servers
 * 1) Plain text only over TLS connections
 * 1) only offer authentication over TLS sessions
 * 1) If your potential clients use Outlook Express or other older clients
 * 2) this needs to be set to yes

The above applies to the (default) communication between SMTP servers. The configuration of the smtpd server running on the submission port overrides this by requiring both TLS encryption and SASL authentication. In /etc/postfix/master.cf</tt>: submission inet n      -       -       -       -       smtpd -o smtpd_tls_security_level=encrypt -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_helo_restrictions=permit_mynetworks,reject_invalid_helo_hostname,permit -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING

As you see, I've also been more liberal in the smtpd_helo_restrictions. Those for my main server also include reject_non_fqdn_recipient, but this is too strict, in particular for IPv6 clients, which quite often do not have a fully qualified domain name.

Custom Passwords
Dovecot SASL (authentication) is used for both mail submission and IMAP.

In /etc/postfix/main.cf</tt>: smtpd_sasl_type = dovecot smtpd_sasl_path = private/auth smtpd_sasl_auth_enable = yes
 * 1) SASL authentication
 * 2) Note: see also the submission parameters in master.cf
 * 3) Use Dovecot SASL at Unix socket /var/spool/postfix/private/auth

Since Dovecot is used for IMAP, it is also used for webmail. By default Dovecot uses the regular UNIX password. This means that it uses the same password for webmail as I use for SSH connections, and all account that have a password (even if the shell is set to ) can log in. I dislike this idea, and prefer a seperate password database.

In, disable system authentication and enable password file: !include auth-passwdfile.conf.ext
 * 1) !include auth-system.conf.ext

Manually create a password file. The format of the password file is equal to. The home directory and user and group ID are used when delivering email.

The resulting  file looks like: freek:{SHA256-CRYPT}$5$JNFyrTLn5NJsZDQ1$BtkFsgpzi2AphAESzsbduyeGvCIbtkSCGVZ.Kki2oa9:1000:1000::/home/freek caroline:{SHA256-CRYPT}$5$rncnsvNdquzxpvFJ$Tx2qLlzkaI10dq52oQN5NgmAfNr.DrKOnAmi0u.Zrn0:1001:1001::/home/caroline

To create a password, run:.

Sender Verification (SPF)
Sender Policy Framework (SPF) is a technique that verifies if the client (IP address) is allowed to send email for the domain it says as a sender. Since nearly all spam contains a forged sender address, the idea is that this would limit the amount of spam. In addition, SPF may also check the HELO record, and see if the given hostname matches the IP address (I personally rather see a reverse DNS check there, but this is fine too.)

SPF has one problem: it does not support simple forwarding of email. Imagine host A sends an email originating from user-a@example.com to user-b@example.net at host B, who forwards it to user-c@example.org at host C. If host B forwards the email as-is to host C, the MAIL FROM remains user-a@example.com. However, host B is not allowed to send email for example.com, which leads to a SPF rejection. My solution is to exempt all hosts that may forward traffic from the SPF check.

In main.cf: smtpd_recipient_restrictions = reject_unauth_pipelining, reject_non_fqdn_recipient, reject_unknown_recipient_domain, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_sender_access hash:/etc/postfix/sender_access, check_client_access hash:/etc/postfix/client_access, check_policy_service unix:private/policy-spf, permit

In master.cf: policy-spf unix  -       n       n       -       -       spawn user=nobody argv=/usr/bin/policyd-spf

contains IP addresses of all hosts that may forward mail, along with an "ACCEPT" rule. This means that for these hosts, the SPF checks are not applied.

192.0.2.66                            OK 192.0.2.67                             OK 2001:db8:767:fd::41                    OK 2001:db8:767:fd::42                    OK forwarder.example.com                  OK

Since my own domains publish a SPF header, the SPF check will filter spam that is supposedly send from some other user in my domain.

SPF checks the  address as used in the initial SMTP exchange (this is the same as the   in the mail header), not the   or   header.


 * TODO: add milter to filter the From: header as well.

Spoofed Sender in Own Domains
SPF is a good way to block spoofed senders. A small disadvantage is that it requires some DNS lookups. Since a large part of the spam is spoofing mails from my domain (e.g. some admin@example.net sending mail to user1@example.net telling the storage limit is reached). I can already block that since there is no account called admin.

smtpd_recipient_restrictions = reject_unauth_pipelining, reject_non_fqdn_recipient, reject_unknown_recipient_domain, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_sender_access hash:/etc/postfix/sender_access, check_client_access hash:/etc/postfix/client_access, check_policy_service unix:private/policy-spf, permit

Before running the SPF policy check, Postfix already checks the sender list. The file  contains:

user1@example.net             DUNNO user2@example.net             DUNNO root@example.net              DUNNO example.net                   REJECT

Meaning that mail with these senders may be valid, and continue the validity checks, but mails from any other sender in my domain (example.net) is rejected.

Client IP Blacklists (RBL)
A Real-time Blackhole List (RBL) or a DNS-based Blackhole List (DNSBL) is a list containing IP addresses of known spammers. Such a list is published in the DNS system. There are a few hundred public blacklists, although about 30 or so are considered reliable. Most blacklists only contain IPv4 addresses, although a handful also contain IPv6 addresses.

The idea is that a mail server checks for each incoming mail if (the IP address of) the sender is listed as a known spammer in one of the blacklist, and if so, rejects the incoming email. A problem with blacklists is the number of false positives (the rejection of legitimate mail as spam). Some blacklists block all IP addresses of home ADSL users. While these IP addresses indeed have a higher chance of containing botnet (hacked) hosts, they may also contain some legitimate mailers. Some blacklists mark over 1% of all legitimate email as spam. That means that if you use them, 1% of your genuine mail will never arrive. On the other hand, there are also blacklists which block about 75% of the spam, with less than 0.01% false positives.

Factors to consider when choosing a blacklist are: is blacklist done automatically, with how many probes? Is de-listing done automatically, after what time? I strongly discoureage the use of any blacklist that has manual operations for either listing or de-listing. Spammers changes sending host multiple times a day. If the blacklist has some manual operations, it is bound to be outdated. Don't get me started on blacklists that only de-list for money, such as SORBS. What criteria are used for listing? For example, Spamhaus has a list of IP addresses of spammers (the SBL), a list of domain names used by spammers (the DBL), a list of IP addresses of home users (who should use an external mail server according to the ISP's policy) (the PBL), and a list of IP addresses of hijacked PCs (the XBL). Does the blacklist contain single IP addresses or a range of IP addresses? For example, UCE Protect has three levels: level 1 lists individual IP addresses; level 2 lists blocks of IP addresses, and level 3 lists all IP addresses of an ISP.

I strongly recommend to compare the different blacklists before choosing one:
 * Blacklist Comparison of the Last Week at uceprotect.net, which lists the quality of some blacklists. Perhaps a bit biased towards their own blacklist.
 * Blacklists Compared each week at SDSC (San Diego Supercomputing Center), which only lists the size of each blacklist, but not the quality (in terms of positives, negatives, false positives and false negatives)
 * Comparison of DNS blacklists at Wikipedia, listing some background information and (de)listing policies. Not suitable for a comparison of quality, only to compare types.

Furthermore, I strongly recommend to test some well known IP addresses against all blacklists. I was unpleasantly surprised to find a few false positives, mostly due to blocking of large (/16) IP ranges. Nothing serious (for me), but enough the question the validity of some blacklists:
 * Multi-RBL Checking Tool
 * MultiRBL Lookup
 * RBL Query Tool

My selection is (based on size and quality):
 * 1) cbl.abuseat.org or zen.spamhaus.org (zen.spamhaus.org includes cbl.abuseat.org)
 * 2) dnsbl-1.uceprotect.net
 * 3) dnsbl.sorbs.net
 * 4) dnsbl-2.uceprotect.net
 * 5) dnsbl-3.uceprotect.net
 * 6) bl.mailspike.net
 * 7) bl.spamcop.net
 * 8) dnsbl.njabl.org
 * 9) bogons.cymru.com

I would recommend not to use ix.dnsbl.manitu.net, l2.apews.org, or list.quorum.to. These listings have too many false positives, even though l2.apews.org can be credited for catching a lot of spam.

My first approach was to select the top blacklists and use that to reject spam right away:

smtpd_recipient_restrictions = reject_unauth_pipelining, reject_non_fqdn_recipient, reject_unknown_recipient_domain, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_rbl_client cbl.abuseat.org, warn_if_reject reject_rbl_client dnsbl-1.uceprotect.net, permit

The  rule checks the following RBL rule, but allows the mail. This allows you to add a RBL and check its effectiveness.

This sections only dealt with blocking clients based on their IP address. There are also blacklists listing client hostnames, blacklists listing domains of the sender, and blacklists listing URIs found in the content of the message. Blacklists listing the sender domain are generally ineffective (since virtually all spam has a forged sender address). Blacklists listing URIs are effective and applied using spamassassin, as described below.

Greylisting
Greylisting (graylisting for American readers) is the process of reducing spam by forcing clients to resend messages after a few minutes. The first time a client connects, the message is rejected with a temporary error. Since the error is temporary, a genuine client will try again later, and the message is accepted the second time. Most spam software is less patient, and never tries the second time.

I use the postgrey software to greylist. By default, greylists runs at a daemon that listens on port 10023.

To subject all mail to greylisting, add the following line to : smtpd_recipient_restrictions = reject_unauth_pipelining, reject_non_fqdn_recipient, reject_unknown_recipient_domain, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_policy_service inet:127.0.0.1:10023, permit

As an alternative, you can greylist based on different criteria. To do so, add an action called "greylist":

smtpd_restriction_classes = greylist greylist = check_policy_service inet:127.0.0.1:10023

You can now use this action in other rules. For example, if you like to greylist all email coming from Hotmail and Gmail, add the following to :

gmail.com    greylist hotmail.com  greylist

Greylisting for Suspect clients
My ideal configuration would be as follow: - Check 2 or 3 larger DNS blacklists. - If it is positive match, greylist. If not, allow the mail right away. - Add a header with the result of the blacklisting (so spamassassin can add some points, without doing the lookup again, if it comes  through the greylist the second time)

Use gross, http://code.google.com/p/gross/source/browse/trunk/README

Advise:

Check the existing policy services at http://www.postfix.org/addon.html#policy

My first thought would be to use postfwd to check the RBLs, and if there's a match call the simple but reliable greylist.pl included with postfix. There are undoubtedly other ways to do this; maybe one of the existing tools does this all by itself.

Don't bother adding RBL result headers for SpamAssassin; the previous results will be cached in your DNS and won't add any significant latency.

Rate Limiting
delay_warning_time = 2h bounce_queue_lifetime = 1d maximal_queue_lifetime = 2d
 * 1) Uncomment the next line to generate "delayed mail" warnings
 * 1) Queue undeliverable mail for only a short while. I rather fail quickly than to send a mail
 * 2) when it's overdue.

minimal_backoff_time = 125s maximal_backoff_time = 700s
 * 1) Deliver to remote mail servers
 * 2) Retry faster to deal with greylisting

smtpd_error_sleep_time = 2s anvil_rate_time_unit = 60s smtpd_client_connection_rate_limit = 30 smtpd_client_connection_count_limit = 15
 * 1) Rate limit botnets

Server-based Mailbox Filters
TODO : procmail

Antivirus and Antispam
aptitude install amavisd-new spamassassin aptitude install clamav clamav-daemon

In main.cf:

content_filter = smtp-amavis:127.0.0.1:10024
 * 1) Use amavis for virus and spam filtering

(TODO: the above lists port 10024, below lists a Unix socket. It seem that the unix socket is unused, and the following inet port is used) /etc/amavis/conf.d/20-debian_defaults:$inet_socket_port = 10024;  # default listening socket

In master.cf: smtp-amavis unix - -   -   -   10  smtp -o smtp_data_done_timeout=1200 -o smtp_send_xforward_command=yes -o disable_dns_lookups=yes 127.0.0.1:10025 inet n -   -   -   -  smtpd -o content_filter= -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks -o local_recipient_maps= -o relay_recipient_maps= -o smtpd_restriction_classes= -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o mynetworks_style=host -o strict_rfc821_envelopes=yes -o disable_dns_lookups=yes -o smtpd_authorized_xforward_hosts=127.0.0.0/8
 * 1) Reinsertion from Amavis to Postfix

SpamAssassin rules
Postfix solutions: use header_check, milter, or proxy filter
 * Client IP blacklisted (Add some points, even if it came through the greylist)
 * Is the MAIL FROM the same as the From: ?
 * Is the From: valid? (do a lookup with postmap -q "value" /etc/postfix/sender_access)
 * Lookup all URIs in a URI DNSBL (e.g. SURBL, URIBL or ivmURI)
 * Bayes filtering

Check effectiveness of SpamAssassin (separate wiki article?)

Spam Training
Folder with sa-learn ispamthereforiam mailing address

Webmail
aptitude install roundcube

Debug postfix
You can turn on postfix debug mode. Note that debug mode produces large amounts of logging, and can be hard to decipher since the important stuff (which is usually present in regular logs) often gets overlooked in the flood. http://www.postfix.org/DEBUG_README.html#trace_mail

warn_if_reject in: smtpd_recipient_restrictions = reject_unauth_pipelining, reject_non_fqdn_recipient, reject_unknown_recipient_domain, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, warn_if_reject check_sender_access hash:/etc/postfix/sender_access, warn_if_reject check_policy_service unix:private/policy-spf,


 * 1) debug_peer_list = 0.0.0.0/0

Appendix: Postfix Configuration File
incoming mail: mx2.example.net outgoing mail: govert.example.net webmail: webmail.example.net / webmail.koalas.nl imap: govert.example.net

smtpd_client_restrictions = permit_inet_interfaces, permit_mynetworks, permit_sasl_authenticated, permit smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, warn_if_reject reject_non_fqdn_hostname, reject_invalid_helo_hostname, permit smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_sender, reject_unknown_sender_domain, permit smtpd_recipient_restrictions = reject_unauth_pipelining, reject_non_fqdn_recipient, reject_unknown_recipient_domain, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, warn_if_reject check_sender_access hash:/etc/postfix/sender_access, reject_rbl_client relays.ordb.org, warn_if_reject reject_rbl_client sbl.spamhaus.org, permit smtpd_data_restrictions = reject_unauth_pipelining, permit smtpd_etrn_restrictions = warn_if_reject reject smtpd_delay_reject = yes disable_vrfy_command = yes
 * 1) Requirements for the connecting server
 * 2) Resource intensive RBL check is performed later in the process.
 * 1) require proper helo or ehlo at connections
 * 1) Requirements for the HELO statement
 * 1) Requirements for the sender address
 * 1) We do not block SPF records here, because en.wikipedia.org/wiki/Sender_Policy_Framework#FAIL_and_forwarding
 * 2) Requirement for the recipient address
 * 1) Requirements for the message body
 * 1) Requirements for the end of data command
 * 2) smtpd_end_of_data_restrictions =
 * 3) Don't allow ETRN
 * 1) evaluate restrictions during RCPT TO (this delay waste spammer's time)

content_filter = smtp-amavis:127.0.0.1:10024

/etc/postfix/sender_access freek@example.net                  DUNNO security@example.net               DUNNO root@example.net                   DUNNO security@govert.example.net        DUNNO root@govert.example.net            DUNNO security@leopold.example.net       DUNNO root@leopold.example.net           DUNNO security@govert.example.net        DUNNO root@govert.example.net            DUNNO security@kwek.example.net          DUNNO root@kwek.example.net              DUNNO security@wolfje.example.net        DUNNO root@wolfje.example.net            DUNNO security@zilverslang.example.net   DUNNO root@zilverslang.example.net       DUNNO security@hiawatha.example.net      DUNNO root@hiawatha.example.net          DUNNO security@donald.example.net        DUNNO root@donald.example.net            DUNNO example.net                        REJECT caroline@koalas.nl                 DUNNO c.dijkstra@koalas.nl               DUNNO koalas.nl                          REJECT macfreek.com                       REJECT omroephumor.nl                     REJECT apoz.org                           REJECT deliciouspi.com                    REJECT xn--j-pgai6b.eu                    REJECT
 * 1) After changing this file, run
 * 2)  postmap /etc/postfix/sender_access
 * 3) This file contain a list of blocked MAIL FROM addresses, domain, parent domains, or localpart@.
 * 4) Note that this only includes mails that originate outside of my domain.


 * 1) hostmaster?
 * 2) postmaster?

3.0 RCVD_IN_XBL            zen.spamhaus.org 0.9 RCVD_IN_PBL           Spamhaus PBL 2.0 RCVD_IN_BL_SPAMCOP_NET bl.spamcop.net zen.spamhaus.org truncate.gbudb.net sbl-xbl.spamhaus.org dnsbl.njabl.org ix.dnsbl.manitu.net bl.spamcop.net psbl.surriel.com intercept.datapacket.net db.wpbl.info

TODO: ponder on SPF problem. If I mail to f.dijkstra@internl.net, and it is forwarded to freek@example.net, the sending domain is not in SPF. How to distinguish from this use case with the use case of spam with myself as sender.

TODO: Add all hosts which can send unauthenticated mail to myself from myself to the list of trusted networks. (e.g. cron jobs on other virtual machines.) ---> not needed, as I am the destination. See next issue for details

TODO: Block mail FROM myself, TO myself which do not originate from a SASL connection, or contain <root|security>@hostname.example.net ---> check_sender_access in smtpd_sender_restrictions

TODO: Block all non-existing example.net mail address as "FROM". ---> check_sender_access in smtpd_sender_restrictions

FROM: security@wolfje.example.net --> OK if received from trusted network --> REJECT otherwise

FROM: freek@example.net --> OK if send using SASL authenticated connection --> OK if received from trusted network (incl backup MX) --> OK if received from forwarding host (e.g. f.dijkstra@internl.net) and non-local domain in the ORCPT. --> REJECT OTHERWISE

FROM: caroline@koalas.nl --> OK if send using SASL authenticated connection --> OK if received from trusted network (incl backup MX) --> OK if received from forwarding host (e.g. c.dijkstra@apotheekbreukelen.nl) and non-local domain in the ORCPT. --> REJECT OTHERWISE

FROM: xyz@example.net --> always reject

Thus: freek@example.net     OK caroline@koalas.nl     REJECT
 * @wolfje.example.net  OK
 * @example.net         REJECT

you should monitor your logs on a regular basis to review their effectiveness (hint: install the postfix-pflogsumm package and use the pflogsumm command to analyze your postfix logs)

TODO:
 * Get CAcert including webmail.koalas.nl, for govert and leopold
 * Stop ClamAV notification mail (only use syslog please)
 * Restrict dovecot SASL Auth to only specific accounts
 * Add cron script to update virtual database with temp mail addresses
 * Add spamassassin rules to amavisd
 * Add procmail scripts
 * Add caroline account
 * Route mail for apoz.org to govert
 * Accept mail for user freek
 * Configure user interface for roundcube
 * Configure webmail caroline
 * Route mail for all domains to govert, except for koalas.nl (do forward Caroline's mail to aphrodite)


 * Replicate configuration at leopold
 * Add sync script govert -> leopold for websites (with some check script to preserve user rights?)
 * Add sync script govert -> leopold for email (a script for each user)

strict_rfc821_envelopes = yes swap_bangpath = no recipient_delimiter = +
 * Check these parameters (what do they mean?)



Spam Protection
Hieronder wat knip & plak van goed advies aldaar.

Factsheet Bescherm domeinnamen tegen phishing.pdf (NCSC) Factsheet Goede bulkmail lijkt niet op phishingmail.pdf (NCSC)

Advies van Erik van Straten op https://www.security.nl/posting/449035/NCSC%3A+voorkom+links+naar+externe+domeinen+in+nieuwsbrieven:

Uit https://www.ncsc.nl/actueel/factsheets/factsheet-goede-bulkmail-lijkt-niet-op-phishingmail.html: > > 1. Domein. Gebruik altijd een emailadres van uw eigen domein in de ‘From'-header van het bericht. Zelfs als een externe partij e-mail verzendt kunnen zij een domein van uw organisatie gebruiken. > Exact, phishers kunnen (en doen) dit dus ook! Daarom kun je aan de hand van de ‘From'-header van het bericht een nepbericht niet onderscheiden van een authentiek bericht. Met 1 uitzondering: gebruik, als verzender, naast SPF, ook DKIM en DMARC (geforceerd, niet in optionele of debug modes) - maar die drie protocollen werken alleen indien mailservers van ontvangers correct gevolg geven aan alle bijbehorende instructies. Helaas komt dat nog niet zoveel voor. > > Goed te zien dat NCSC daarover vandaag ook een advies gepubliceerd heeft, zie https://www.ncsc.nl/actueel/factsheets/factsheet-bescherm-domeinnamen-tegen-phishing.html. > > > 2 Links. Laat alle links in bulkmail verwijzen naar uw eigen verzenddomein en maak gebruik van redirects. Bijvoorbeeld, als u mailt van ‘@bulkmail.example.nl’, dan verwijzen alle links naar ‘bulkmail.example.nl’. > Goed advies. Eindelijk eens verstandig gebruik maken van de hiërarchie die DNS biedt! In essentie: hou op met stomme domeinnamen verzinnen zoals bijvoorbeeld praxis-aanbiedingen.nl - iedereen kan zo'n domeinnaam aanvragen. > > Feitelijk zijn de werkelijke links in een e-mail het enige op basis waarvan een ontvanger met zekerheid een echte van een nepmail kan onderscheiden. > > Ik voeg hier graag de volgende adviezen aan toe: > (A) Gebruik https en zorg voor certificaten waarin de gebruiker goed kan zien dat hij een site bezoekt van de bedoelde organisatie. > > (B) Zorg dat alle links in e-mails met https:// beginnen (vertrouw niet op redirects). > > (C) "Verstop" links in de e-mail onder termen als "deze pagina". Vertel aan gebruikers op de anti-phishing pagina (die je natuurlijk publiceert) dat ze altijd met de muis boven een link moeten gaan hangen om te kijken waar de link naartoe gaat, en waar ze dat kunnen zien in de verschillende mail clients. Reden: als je https://bulkmail.example.nl/ in de tekst ziet, wil dat niet zeggen dat je ook daarnaartoe gaat als je op die link klikt. > > Voorbeeld: als je in https://twitter.com/ncsc_nl/status/659315946734141440 je muis boven de link getoond als "ncsc.nl/actueel/factsh ..." laat zweven, verschijnt een popupje met daarin "https://www.ncsc.nl/actueel/factsheets/factsheet-bescherm-domeinnamen-tegen-phishing.html". Beide zijn onzin. Als je erop klikt ga je naar https://t.co/8kLKqkPV3s, en je moet maar afwachten wat daarachter zit. > > Schrijf erbij dat je, in e-mails, nooit en te nimmer van URL-shorteners gebruik zult maken, en waar je dat wel doet (zoals op Twitter). > > > 8 HTML. Zorg dat de e-mail opgemaakt is door middel van correcte en gevalideerde HTML en laad geen externe scipts in. > Vermijd alle externe content, ook plaatjes. Verstandige mensen zetten dat uit (waardoor legitieme e-mails met externe plaatjes er niet uitzien). Reden: spammers weten dat e-mail gericht aan jouw e-mail adres gelezen wordt zodra je een e-mail opent en één of meer plaatjes vanaf een door de spammer/phisher beheerde (of gehackte) server worden opgehaald. > > > 1. Domein. Gebruik altijd een emailadres van uw eigen domein in de ‘From'-header van het bericht. Zelfs als een externe partij e-mail verzendt kunnen zij een domein van uw organisatie gebruiken. > > 4 Spelling en grammatica. Voorkom spel- en grammaticafouten. Deze verlagen de betrouwbaarheid van een e-mail sterk. > > 5 Opmaak. Gebruik een opmaak die overeenkomt met de huisstijl van uw organisatie en voorkom inconsistenties. Phishingmails zijn te herkennen aan stijlinconsistenties en gebreken zoals het ontbreken van een logo. > > 8 HTML. Zorg dat de e-mail opgemaakt is door middel van correcte en gevalideerde HTML en laad geen externe scipts in. > > 9 Reden van ontvangst. Geef duidelijk aan waarom de ontvanger het bericht ontvangt. > > 10 Aanhef. Gebruik de naam van de ontvanger in de aanhef van de e-mail als deze bekend is. Phishingmails beginnen veelal met generieke begroetingen ('Dear customer') of met de gebruikersnaam ('Dear gebruiker123'). > > Vertel NOOIT aan gebruikers dat zij bovenstaande aspecten kunnen gebruiken om legtitieme van nepmails te onderscheiden. Dat is misleiding. > > Voorbeeld, uit https://www.praxis.nl/service/waarschuwing (bron, waarvoor dank aan Ivanhoe: https://www.security.nl/posting/448783/Praxis+phishing): > > Nieuwsbrieven van Praxis zult u altijd via het e-mailadres nieuwsbrief@praxis.nl of email@praxis.cccampaigns.net ontvangen. > Daarmee wek je de suggestie dat mails afkomstig van genoemde adressen gegarandeerd geen phishingmails zijn, en dat is niet waar. Zeker niet omdat genoemde domains welliswaar van SPF gebruik maken, maar daarmee nooit garanderen dat het getoonde afzenderadres authentiek is. > > Correctie 14:42, bovenaan: DMARC lijkt SPF nodig te hebben om het zichtbare From: veld te kunnen valideren (waar SPF alleen slechts het, onzichtbare, envelope-from AKA return-path valideert). Ik moet me nodig verdiepen in DMARC! > Correctie 14:46: in stukje over Twitter stond de schijnbare URL 2x, deze wordt in de tweet juist verkort afgebeeld. > Correctie 15:18: in de 1e correctie bedoelde ik met "header-from" "envelope-from".