Changes

* Your .crt file is your public key.

Let's start with the "sending" SMTP server we have on VM2. Run the following, replacing andrewsmith.org with your own domain name:

After you confirm that security exception - send another email to yourself and make sure you receive it. Notice that from the user's point of view nothing is different. But if you were an evildoer trying to steal an identity - the difference is huge. Before it was trivial and now it's computationally prohibitive.

Now we'll ensure our Dovecot connection is secure, and we'll enforce that. With SMTP you need to allow plain text connections because that's the only way to pass email server-to-server. With IMAP there is no server-to-server, only client-to-server. The only reason to have an unencrypted IMAP connection would be if your IMAP server and IMAP client were the same machine (this would be the case with webmail).

But be aware that even though we spent three weeks on it - we've only done the simplest possible setup. In the rest of the section we'll list other commonly-needed services/tools/concepts that we just don't have time for this semester.

Your SMTP servers are open relays. That means if they were accessible on the internet - anyone could use them to send spam. This would very quickly get your server blacklisted and you'd have a very hard time getting yourself off that blacklist.

# Use SASL or some other means of checking that the person trying to use the SMTP server has a valid user on the system. This way only your users will be able to use your server to relay email.

SPF uses DNS to publish a list of server IP addresses that are allowed to send email for your domain. That way a receiving server can check whether the sending server is authorized (message is likely not spam) or not (message is probably spam).

SPF is a pretty cool system, but it's not perfect. It works very well for single servers but if you send mail for your domain from multiple servers (and perhaps a varying number of them) - you have to put in wildcards which lower the effectiveness of this system.

One popular spam-prevention measure that uses encryption to sign messages originating from your server so that receiving servers can verify that the messages really did come from your server (the keys are published in DNS).

It's a neat idea but the strength of the encryption is pretty pathetic. So it's a good deterrent against mass amounts of spam, but it doesn't really guarantee anything.

An address book has nothing to do with email, even though you might think they are related systems. Typically an address book is a completely separate system - using either a CardDav server (one easy to set up comes with OwnCloud) or an LDAP server. Even tightly integrated services like Microsoft's Active Directory keep the address book separate from the email.

If you think about it - it's not really clear what service should be responsible for sending out vacation messages. Your receiving SMTP server? Do you really want your users to be able to control that? The client? It's probably not running.

It's usually yet another separate service. Even though the settings to enable vacation response will usually be next to your other email settings - they will be controlling a separate system that's hooked into your MTA.

There are countless other features and extensions for email. Not to mention propietary ones like Gmail, Yahoo mail, Office 365, etc. But having mastered the email portion of this course - you will be qualified to evaluate capabilities, design integrated systems, and customise the email service for you organization like no regular email user can even understand.

Students should be prepared with '''all required commands (system information) displayed in a terminal (or multiple terminals) prior to calling the instructor for signoff'''.