SMTP configuration

From Exterior Memory
Jump to: navigation, search

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 (my actual domain) with, 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/ In my case:

myorigin =
myhostname =
mydestination =,, localhost
relayhost = 
mynetworks = [::ffff:]/104 [::1]/128 [2a01:238:43ed:a300:ea00:54c2:fb7a:7e66]/128
inet_interfaces = all
# Listen on IPv4 and IPv6
inet_protocols = all

# Greeting text. Enough for debugging, not enough for potential hackers
smtpd_banner = $myhostname ESMTP $mail_name

# appending .domain is the MUA's job.
append_dot_mydomain = no

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 check_client_access in the smtp restrictions.

Maildirs are used for delivery to local users:

# Deliver to mail dirs
home_mailbox = Maildir/
mailbox_size_limit = 0
biff = no

Email Address

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

In /etc/postfix/

# virtual aliases: mail forwarding for multiple domains
#virtual_alias_domains = $virtual_alias_maps
virtual_alias_maps = hash:/etc/postfix/virtual
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases

virtual_alias_domains is used to list the domains that are "virtual", and should be looked up with virtual_alias_maps. You can specify a file and list each domain on a line. The default however is the same as virtual_alias_maps. 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 "VIRTUALDOMAIN".

/etc/postfix/virtual:                    VIRTUALDOMAIN          freek              caroline   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 relay_domains 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

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.

where username is my primary account name, and 201109 is the date. A cron job runs daily to add these mail addresses in /etc/postfix/virtual.

A daily cron jobs runs the script tempmailalias.php to add the temporary mail addresses to the /etc/postfix/virtual 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/

# TLS parameters

# Allow TLS between servers
# Plain text only over TLS connections
smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_tls_security_options = noanonymous
# only offer authentication over TLS sessions
smtpd_tls_auth_only = yes
smtpd_sasl_local_domain = $myhostname
# If your potential clients use Outlook Express or other older clients
# this needs to be set to yes
broken_sasl_auth_clients = no

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/

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/

# SASL authentication
# Note: see also the submission parameters in
# Use Dovecot SASL at Unix socket /var/spool/postfix/private/auth
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes

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 /bin/false) can log in. I dislike this idea, and prefer a seperate password database.

In /etc/dovecot/conf.d/10-auth.conf, disable system authentication and enable password file:

#!include auth-system.conf.ext
!include auth-passwdfile.conf.ext

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

The resulting /etc/dovecot/users file looks like:


To create a password, run: doveadm pw -s SHA256-CRYPT.

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 to at host B, who forwards it to at host C. If host B forwards the email as-is to host C, the MAIL FROM remains However, host B is not allowed to send email for, which leads to a SPF rejection. My solution is to exempt all hosts that may forward traffic from the SPF check.


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


policy-spf  unix  -       n       n       -       -       spawn
     user=nobody argv=/usr/bin/policyd-spf

client_access 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.                             OK                             OK
2001:db8:767:fd::41                    OK
2001:db8:767:fd::42                    OK                  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 MAIL FROM address as used in the initial SMTP exchange (this is the same as the Return-Path: in the mail header), not the From: or Sender: 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 sending mail to 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,
    check_sender_access hash:/etc/postfix/sender_access,
    check_client_access hash:/etc/postfix/client_access,
    check_policy_service unix:private/policy-spf,

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

Meaning that mail with these senders may be valid, and continue the validity checks, but mails from any other sender in my domain ( 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, 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:

My selection is (based on size and quality):

  1. or ( includes

I would recommend not to use,, or These listings have too many false positives, even though 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,
    warn_if_reject reject_rbl_client,

The warn_if_reject 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 (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:

smtpd_recipient_restrictions = reject_unauth_pipelining, reject_non_fqdn_recipient,
    reject_unknown_recipient_domain, permit_mynetworks, permit_sasl_authenticated,
    check_policy_service inet:,

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:

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 /etc/postfix/sender_access:     greylist   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,


Check the existing policy services at

My first thought would be to use postfwd to check the RBLs, and if there's a match call the simple but reliable 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

  1. Uncomment the next line to generate "delayed mail" warnings

delay_warning_time = 2h

  1. Queue undeliverable mail for only a short while. I rather fail quickly than to send a mail
  2. when it's overdue.

bounce_queue_lifetime = 1d maximal_queue_lifetime = 2d

  1. Deliver to remote mail servers
  2. Retry faster to deal with greylisting

minimal_backoff_time = 125s maximal_backoff_time = 700s

  1. Rate limit botnets

smtpd_error_sleep_time = 2s anvil_rate_time_unit = 60s smtpd_client_connection_rate_limit = 30 smtpd_client_connection_count_limit = 15

Server-based Mailbox Filters

TODO : procmail

Antivirus and Antispam

aptitude install amavisd-new spamassassin aptitude install clamav clamav-daemon


# Use amavis for virus and spam filtering
content_filter = smtp-amavis:
(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


smtp-amavis unix -  -   -   -   10  smtp
    -o smtp_data_done_timeout=1200
    -o smtp_send_xforward_command=yes
    -o disable_dns_lookups=yes
# Reinsertion from Amavis to Postfix 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=

SpamAssassin rules

  • 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)
 Postfix solutions: use header_check, milter, or proxy filter
  • 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


aptitude install roundcube


Debugging Postfix

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.

warn_if_reject in: smtpd_recipient_restrictions = reject_unauth_pipelining, reject_non_fqdn_recipient,

   reject_unknown_recipient_domain, permit_mynetworks, permit_sasl_authenticated, 
   warn_if_reject check_sender_access hash:/etc/postfix/sender_access, 
   warn_if_reject check_policy_service unix:private/policy-spf,
#debug_peer_list =

Appendix: Postfix Configuration File

incoming mail: outgoing mail: webmail: / imap:

  1. Requirements for the connecting server
  2. Resource intensive RBL check is performed later in the process.

smtpd_client_restrictions = permit_inet_interfaces, permit_mynetworks, permit_sasl_authenticated, permit

  1. require proper helo or ehlo at connections

smtpd_helo_required = yes

  1. Requirements for the HELO statement

smtpd_helo_restrictions = permit_mynetworks, warn_if_reject reject_non_fqdn_hostname, reject_invalid_helo_hostname, permit

  1. Requirements for the sender address

smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_sender, reject_unknown_sender_domain, permit

  1. We do not block SPF records here, because
  2. Requirement for the recipient address

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, warn_if_reject reject_rbl_client, permit

  1. Requirements for the message body

smtpd_data_restrictions = reject_unauth_pipelining, permit

  1. Requirements for the end of data command
  2. smtpd_end_of_data_restrictions =
  3. Don't allow ETRN

smtpd_etrn_restrictions = warn_if_reject reject

  1. evaluate restrictions during RCPT TO (this delay waste spammer's time)

smtpd_delay_reject = yes disable_vrfy_command = yes

content_filter = smtp-amavis:


  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@.

  1. hostmaster?
  2. postmaster?


TODO: ponder on SPF problem. If I mail to, and it is forwarded to, 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> ---> check_sender_access in smtpd_sender_restrictions

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

FROM: --> OK if received from trusted network --> REJECT otherwise

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

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

FROM: --> always reject


  • OK OK


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)


  • Get CAcert including, 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 to govert
  • Accept mail for user freek
  • Configure user interface for roundcube
  • Configure webmail caroline
  • Route mail for all domains to govert, except for (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)

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

Spam Protection

This article is unfinished.

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

Uit > > 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 > > > 2 Links. Laat alle links in bulkmail verwijzen naar uw eigen verzenddomein en maak gebruik van redirects. Bijvoorbeeld, als u mailt van ‘’, dan verwijzen alle links naar ‘’. > Goed advies. Eindelijk eens verstandig gebruik maken van de hiërarchie die DNS biedt! In essentie: hou op met stomme domeinnamen verzinnen zoals bijvoorbeeld - 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 in de tekst ziet, wil dat niet zeggen dat je ook daarnaartoe gaat als je op die link klikt. > > Voorbeeld: als je in je muis boven de link getoond als " ..." laat zweven, verschijnt een popupje met daarin "". Beide zijn onzin. Als je erop klikt ga je naar, 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 (bron, waarvoor dank aan Ivanhoe: > > Nieuwsbrieven van Praxis zult u altijd via het e-mailadres of 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".