Good afternoon. Welcome to session 646, Extending and Securing Mail Services Using Mac OS X. I'm Paul Schreiber, a software engineer on Mac OS X. Today we're going to talk about securing your mail server so your messages can't be read in transit and the content of the messages can't be read. We'll talk about extending the mail server to handle multiple domains and users. We'll show you a neat feature of Tiger's Mail Client, which helps you pre-configure mail accounts for your users. And we're going to explain how the Mac OS X Server GUI makes this all easy to use and uses open source and open standards tools to do so.

So, when it comes to securing the transport of your mail, we'll show you how you can use SSL so the messages can't be read. We're going to show you how to use SMIME to sign and encrypt your messages. We're going to talk about Postfix and Open Directory and how they can be used to handle multiple domains and many users. We'll talk about using ClamAV and SpamAssassin to stop spam and viruses. And again, the Tiger Account Bundles to help save you time, money, support calls, make it easier on your users.

Okay, quick overview of the technologies involved here. Well, when it comes to mail, we provide IMAP and POP services using Cyrus. We provide SMTP services using Postfix. We have HTTPS and SMIME all using OpenSSL. As I said, SpamAV, ClamAV, and SpamAssassin. And we also include SquirrelMail, which is a web-based mail client.

So we'll talk very briefly about internet email. Just want to make sure you want to focus on the last part of this diagram. Often people think of mail as a mailbox and an email address, and that's not always true. It's very much a many-to-many relationship. You're going to have to see, we're going to show you managing multiple domain names.

You're going to have multiple MX records, so you could have multiple mail servers. And you could have many virtual domains. You could have different aliases for your users. And you'll see more about that later on in the talk. Okay. So on to part one, securing the mail transport.

OK. Quick overview of security. Security with regards to the mail server, like anything else, is a tradeoff. There's a certain amount of time and effort and money you're willing to expend to get a certain amount of benefit. And in this case, like in any other, the human factor is always the weakest link.

So no matter what sort of password rules you set up or what grade of encryption you use, people will always write their passwords down or they will share their passwords with other accounts or they'll trade it for a chocolate bar and you have to be aware of this. So there's two aspects to security. First off, there's physical security. So you want to make sure that your server is in a locked room.

You want to make sure it's locked down to the desk. You want to make sure that if you have a G5, you have a padlock on the back. When it comes to electronic security, you want to do things like enable screen saver locking. You want to turn on the open firmware password so people can't bypass it.

You know the boot sequence if they have access to the machine. If you have SSH enabled you can turn off permit root login. And the last two are we're going to concentrate on in this talk, securing the transport and securing the content. So, why do we care about securing our messages in transit?

Well, first off everything is in the clear by default. That means when you talk to the mail server your password can be read, your user name can be read and all of the messages going in and out can be read. Well a few years ago this wasn't as big a concern because you had a bunch of desktops, they're all wired down, you know they sat on your desk, they're on a switch network and it was fine.

But now everyone is using wireless networks and you see Wi-Fi here at WWDC, you can go to your friend's house, you can check your email there, you can go to a coffee shop and there are a lot of opportunities for people to go and recover your password and read your mail and you really don't want that to happen.

So talk about authentication methods. What can you do? Well, at the very basics, the thing you can do is you can put a password on your mail. And you can have a plain text password. But this is not a good solution. It is not adequate. Now having a password will protect your email from being read by, say, your mom, if you use a good password that's not your birthday or your dog's name or something like that.

But what you want to do is you want to encrypt the password. So even if someone is listening in on your network session, they can't go ahead and figure out what it is. So we support several different authentication methods and encryption methods in Mac OS X Server. In this case, we can use MD5, CRAM MD5, to encrypt the password.

And then that, however, is not sufficient because if someone is listening in on your session, even though they can't get your password, they can still listen to or read your email. And you want to make sure they can't do that, either. So we're going to use SSL encryption. And in Tiger server, we make this really easy to do. So what is SSL? Well, this is a cross-platform encryption standard. It'll work on Mac OS X, it'll work on Windows, it'll work on Linux.

This can be used with any mail client. It's an open standard, so it's been implemented by Mac OS X Mail, by Thunderbird, by Eudora, Outlook, Entourage, you name it. This is very hard to break encryption. It's not ROT 13. This is industrial strength. You don't have to worry about people going and cracking it.

However, just because you've turned on SSL, that doesn't mean you're done. You have the same gotchas you have with any encryption system. People can still use a weak password that someone can guess. The message could be read in transit after it reaches your mail server and goes out on the internet to its destination.

Of course, it can also be read on disk on your server or someone else's server. And lastly, if you're using self-signed SSL certificates, you need to be very aware of the possibility of a man in the middle attack, where someone impersonates your server and relays all the traffic back and forth.

So, in terms of SSL certificates. Well, SSL is Public Key Infrastructure Encryption Technology. That means your mail client has to trust the certificate. So how does it do that? Well, Mac OS X, like every other operating system that supports SSL, includes a collection of certificates, root certificates, that it knows about.

So you could go and you could buy a certificate that's been signed by one of these known authorities like Equifax or VeriSign or Thought or GoDaddy. And you can spend anywhere from $30 to $1800 and this would last you a year. Now if I said, "Okay, go home and do that." Now, anyone here would have reservations with their boss saying, "Hmm, I don't know if I want to spend that kind of money."

Okay, I see. Good. Now, the good news is you don't have to do that. It's really easy in Tiger Server to create your own self-signed certificate. Now, this will cost you nothing. It will require a little bit of work on the client side, and we're going to show you how to do that later in our demo, so users won't have to approve the certificate every time.

Now, there's another strategy that's available for people in large organizations that have many servers. Instead of creating your own certificate, you can become your own certificate authority and have the mail client machine recognize that authority, and that way you can sign as many certificates as you want, and they only have to add that one root certificate to their collection, to their keychain. So, now we're going to show you our first demo. Andrew's going to come up, explain how to use Mac OS X Server to create an SSL certificate, and then the client and how to use it. Thank you, Paul.

My name is Andrew Moon, and over the next 10 minutes, I'm going to be presenting a couple of demonstrations on how to enhance the security of your mail service using self-signed SSL certificates. It's going to be two parts. First, we're going to cover the server-side configuration, and then we'll get to the client side. TigerServer has an enhanced Server Admin application that lets you create and manage self-signed SSL certificates. Let's take a look at that now. Let's bring up Server Admin.

And here in the Computers and Services pane, we're going to select the server we want to manage. In this case, it's demo646.local. Then we come over here to the Settings button and the Certificates tab. Now you see that there's this default certificate here that comes out of the box.

We could use this with a little bit of editing, but for the purposes of this demonstration, let's create a brand new one. So click on the Plus. Now the common name is gonna be the most important field, and you want that to be the fully qualified host name by which your mail server is known and accessed. So in this case it's gonna be demo646.local. And I'll just briefly fill in these other fields.

And this has a default expiration period of one year. We'll leave the private key size at 1024 bits. And we're gonna leave the private key passphrase blank so that the SSL certificate can continue to be used by the mail server even across unattended reboot situations. So I filled out this form. Let's click Save. And if we go back to the list, there's the self-signed certificate that we just created. Now let's tell the mail servers how to make use of that. So let's come over here to the mail service of our server. Click on the Settings button.

Over here to the Advanced tab and the Security sub-tab. Now there are two sections here. The first part is authentication for the various mail protocols. Now login, plain, and clear are all unencrypted authentication methods. So let's make sure those are unchecked. Kerberos is typically more appropriate for larger environments with many systems, so for this single system demo, let's choose CRAM MD5 for both SMTP and IMAP, and APOP for POP.

Next, let's come down here to the SSL section, where we can control the SSL configuration for SMTP as well as IMAP and POP. So this first pull-down lets us choose whether to disable, use, or require SSL. So for SMTP, let's choose Use. So that means if both parties, if both the server and the client support SSL, that SSL will actually be used.

Now the reason we're doing Use and not Require here is that most mail servers on the Internet are not actually configured to send mail to other mail servers using SSL. So we're going to probably have to back off from SSL for that. However, you may have, say, traveling users who are out on the road on other ISPs who want to relay mail through your organization's mail servers. And for that, we can use SSL so that they can use authenticated SMTP over SSL to your mail server. So we'll select Use.

Then this second pull-down lets us choose the certificate we want to use with the mail service. Because we just created that certificate for demo646.local, it's available here on this pull-down list. So let's go ahead and pick that. Now for IMAP and POP, let's go ahead and choose Require. Most or all of the major mail clients available today can connect to IMAP and POP servers via SSL. So that should be a good choice.

Then let's choose the same certificate here. And we're done, so we can click Save. And that should be it for the server side. So let's now move on to client side configuration. And how to connect via SSL to a server that has a self-signed SSL certificate. So let me fast user switch over to a user I've already created for this purpose.

And let's bring up the mail application. So this is the first time we're bringing up the mail application for this user. So it's gonna present me with the new account setup assistant. So let's just go through that. Click Continue. Let's go ahead and create an IMAP account. The incoming mail server is going to be our server, and we're going to provide our credentials to authenticate with.

Uh-oh, we got an error message here. So what's going on is that we decided to use a self-signed SSL certificate. Now, Paul mentioned a few caveats with that choice, and this is actually one of them. So the mail application is not trusting our server by default, and that's why it's throwing up this error message. So since we know what's actually going on here, let's click Continue for now, and we're going to address this issue in just a few moments.

Let's tell this account configuration to use SSL. Now the authentication method, you'll recall that we chose CRAM MD5 for IMAP and SMTP, and here that corresponds to the MD5 challenge response choice. Choose that and click Continue. Now let's fill out the outgoing mail server. Also use authentication. We don't have a problem here since it doesn't have to connect via SSL to SMTP. Now we're done with that.

I'm actually aware of some of what's new in the mail application, so we'll skip that. Let's go ahead and check our mail. And we get another error dialog that gets thrown up. So let me point you to the most important part of this message is right here. The root certificate for this server could not be verified. And that's again because we chose to use a self-signed SSL certificate.

Now this would be a real problem if we continue to get this message every time we wanna connect to our server and check mail. So we need to figure out some way to tell the OS or tell the mail application to trust this server. The way we do that is we're gonna is we can click on the show certificate button.

Let's check on the details to make sure that this is the server we want to connect to. And just briefly here, one thing we can check is the common name. It's matching the server that we want to connect to, demo646.local. We're going to take this certificate and we're going to drag it over to desktop.

Once on the desktop, we can double-click on it, and that will bring up the Keychain application, which hopefully asks us if we want to add it to our Keychain. We do, however, we want to add it to a special system-level Keychain, and that happens to be called X.509 Anchors. And it's available on this pull-down list, so let's go ahead and select that. And then let's click OK. Now because that's a special system-level keychain, we need to authenticate with our administrator privileges. Let's go ahead and do that. And the certificate gets added.

And then let's click OK. Now because that's a special system-level keychain, we need to authenticate with our administrator privileges. Let's go ahead and do that. And the certificate gets added. And there it is. So there's the certificate we just imported. Let's go ahead and put away that Keychain Access application now that we're done with it. Let's continue onward.

And now, if I restart mail, That error dialogue should not come up anymore, so let's go ahead and check our mail again. And we don't actually have additional new mail, so we're connecting to our server, and you'll notice that the error dialogue has not come up. And so that's all we have to do. That's client-side configuration, and now the server certificate is saved. And I'm going to turn this back over to Paul.

Thank you very much Andrew. Slides please. Okay, so to review what did we have to do to enable SSL? On the server side we did two things. First of all, we created an SSL certificate and second of all, we enabled it for the SMTP and IMAP services. On the client side we did two things. We configured the mail application to use SSL and then we added the certificate to keychain access in the X.509 anchors keychain.

Now, this is all new on Tiger Server. If you're still using Mac OS X Panther, you need to go to Terminal and enter a bunch of commands to create the certificate. There's a document describing how to do this on the developer.apple.com website, the URL of which you can see right here. It's called Creatinging Secure Transactions on Mac OS X Server Using SSL. Okay, now we're on to the second part of our talk, Securing Message Content.

Sometimes SSL is not enough. You may have messages which are very confidential and you want to make sure that not only can they not be read in transit, but you want to make sure they can't be read on the disk. Perhaps you don't trust the system administrator in this case or all the system administrators in between you and your recipient. This is perhaps other people have physical access to your machine and you want to make sure that they can't read the message.

So, we're going to... There are many different ways you can encrypt messages. You can use something like PGP or OpenPGP or GPG. We're going to talk about using SMIME because this is built into Mac OS X. SMIME will let you do two things. First of all, it will let you sign messages. And second of all, it will let you encrypt the messages.

So, let's go back to our diagram about authentication methods. As we started out with just using a plain text password. And as we said before, this is not an adequate method for protecting your data. Then, we moved on to encrypting the password. And this will help keep out, say, you know, your nosy neighbors who happen to be sharing your network. If we go and we use SSL to encrypt the entire session, this will keep out some script kiddies who are breaking into the network. And if we use S-MIME, this will protect the message content from industrial spies or foreign governments.

So, what are the benefits of using SMOT? Well, you can ensure, when you sign a message, you can ensure that the message, once it's received, has not been modified in transit. Second of all, you have to be aware that this doesn't make a claim about the human or the computer that sent the message, so you can't guarantee that the message is from who it says it's from.

When it comes to encryption, it prevents the messages from being read in transit and on disk. So let's take a look at how you go ahead and use S-MOD. Well, Mac OS X Mail supports this right out of the box. And like in the case of SSL, you need to get certificates.

Now, you can sign messages right away, and you can encrypt messages. In order to do that, you need to have the other person's public key. This is also PKI. So, how do you get someone else's public key? Well, there's two ways you can do it. First of all, you can receive a signed message from them. If you receive a signed message, that will include enough information for mail to reply and encrypt the message.

The other method is to retrieve this information from a server. Many directory services servers, such as LDAP, provide an option to store all of the public keys from people in your organization on them. And that way, you can look it up there and not need to receive a message from someone before you send them one.

So, how do we get an S/MIME certificate? Well, in this case, we can go to a third-party vendor. We can go to VeriSign and we can pay them $20. But the good news is, you can get a free certificate from THOT, and that will automatically be recognized as valid.

Now, THOT's S/MIME certificates use something called their Web of Trust. And when you get a certificate initially, it says "THOT free mail member" instead of your real name. In order for your name to appear on the certificate, you have to find people who are considered notaries by THOT to assert that you are who you say you are. And once you find enough of those, your certificate will bear your name.

Alternatively, if you're a large organization, you can consider becoming your own certificate authority for SMIME. And that way you can validate everyone's certificates in your organization. Now when you start using SMIME, you're going to see a bunch of files around. There are two different file types you need to worry about. The first type of file is a P7 file. That contains the certificate itself.

When you use Safari to download a certificate from Thought, you will see a .exe file. This is actually a P7 file. So if you're going to pass this around, you're going to need to rename it before you do so. In order to use Safari to obtain a certificate from Thought, you need to make sure you're using Mac OS 10.3.4 or better.

If you use a Mozilla-based browser, such as Firefox, Now there's a caveat. You have to be careful when you're managing these certificates. Because certificates expire, at the end of the year, you'll see in your keychain red Xs saying the certificate has expired. Don't delete those, because if you do, you won't be able to read encrypted messages that person has sent you with that certificate.

The second thing you have to be aware of is if you are deleting your own old certificates, don't delete just the certificate and leave the key around. Because mail, when it sends a message out, will include all of your keys, and when the other person replies, they could choose the key to which you no longer have the corresponding certificate. That means you won't be able to read the encrypted message they send you.

So, what does it look like in the mail client when you do this? Well, you can sign a message and in the bottom right-hand portion of the header you check a checkmark and it looks like this. If you want to encrypt a message, there's a padlock. Same place right beside the checkmark. And when you check the padlock, it becomes locked. If you choose to both sign and encrypt a message, you'll check both the checkmark and the padlock and they will both be enabled.

What happens when you receive a signed or encrypted message? Well, when you receive a signed message at the bottom of the header, the checkmark will appear and the word "signed" will appear. If you receive an encrypted message, in this case you'll see a lock icon and the word "encrypted". And lastly, if you receive a message that's both signed and encrypted, you'll see the lock icon and the checkmark. So this is what happens when things go right. Well, what happens when things go wrong?

Well, if mail receives an SMI message that's been signed and it can't verify the message signature, it will warn you about that, putting a big yellow bar above the message. So what can cause this? Well, two things. First off, the message content could be modified by someone who is purposely--some adversary who's trying to modify the content of the message, you know, to fool you, you know, if you get a message from your boss or something. And the other thing is if you resend a message with your signature, you will see that as well. And in that case, don't worry, you can safely ignore the message. And what about encrypted messages?

What happens when an error occurs? Well, in this case, you won't be able to see the message at all and you'll see a similar looking error with a lock saying "unable to decrypt message". This could happen because the message was modified in transit or it could happen because you don't have the right certificate and key pair, you need the other person's public key.

Now, we're on to the third section of our talk. This is about managing multiple domains. If you're an ISP or you handle multiple domains for your company, what do you do with that? Well, there are four cases we're going to cover. First off, you have the easy case where you have one domain.

Second case is where you have multiple domains with one namespace, and we call this virtual domains. The third case is virtual hosting, where you have a bunch of domains and a bunch of different namespaces. This is very common if you're an internet provider or you have a shared co-located server. And lastly, we'll cover some advanced virtual hosting techniques.

So, when you're using Mac OS X Server, there are two ways to configure virtual hosting and virtual domains. First off, you can use the Mac OS X GUI using Server Admin and Workgroup Manager, and this will store the information in Open Directory. The second method is using the Postfix configuration file that you see in Etsy Postfix.

Let's take a look at what happens when you have one domain. Well, in this case you don't have to do anything special. You create a bunch of user accounts, you set up the host or use that domain, and each user account will correspond to the left-hand side of an email address.

Now, what about virtual domains? Well, in this case you have a shared namespace. This is very useful if your company has multiple names, if you've registered variations on the name, you have a misspelling you've registered, and you want those all to receive email. What you can do is you create a virtual domain in Mac OS X Server. This acts like an alias. And so we have, in our example, we have a company, Banana Software, and they've registered bananasoftware.ca and banana-inc.ca, and in both cases, they receive mail.

Okay, so this time we're going to do the Mac OS X configuration of the virtual hosting slide that Paul showed us. So let's work through that slide and configure what he showed us as possible. Let's go ahead and actually do that. So let's bring up the server admin application.

And the way we're going to do that is we're going to do part of the administration with server admin to tell it about the virtual hosts, and then we're going to bring up workgroup manager to alter user records. So first server admin, mail service, settings, advanced tab, and this time we want the hosting sub-tab. We're going to check the box to enable virtual hosting, which will then allow us to add our virtual hosts. The first one is Bananasoftware.ca. And the second one is going to be Starfruit.ca. Let's go ahead and save that.

That's all we need to do with Server Admin. Now let's bring up the Workgroup Manager. So we saw that we had two people, Joe and Joe Bob, and they both want Joe at their domain names. So the way we do that is we look at their user records and we're going to add the email address we want to control into the short names field.

So we're going to come to this short name field, and we're going to go underneath the last entry that is already there. We're going to double click on it, and that allows us to edit this field. So we're going to add [email protected]. We'll go ahead and save that user record. and Joe Bob also wanted Joe, but he wanted that at [email protected].

and Andrew So now we've actually gone through and that's all it takes to actually configure the scenario presented in virtual hosting in Paul's slide. So now we have email sent to [email protected] going to this person Joe and we have the email address [email protected] mail to that email address going to Joe Bob and that's all we have to do to do virtual hosting. Now I'm going to turn it back over to Paul.

Thank you very much, Andrew. So to summarize, what do we have to do to set up virtual hosting on Mac OS X? First off, we use a Work Group Manager. The short name field contains the email address for the other domain we want to use. And the advantage of using the Open Directory method is that it keeps all of the configuration information in one place.

However, there's some things that you can't do with Open Directory. And we're going to talk about a few advanced virtual hosting techniques that are possible with PostFix. So the first technique is having one email address go to multiple people. This is very useful if you have a generic email address like contact, feedback, or info at your domain name. As you can see in the slide, we have this email address going to three of our users.

The second technique you can do is create a catch-all email address. This means that any email address that's not explicitly specified in your domain will go to this user's mailbox. And lastly, we can provide an email address that exists without a user account. So in this case, we can forward [email protected] to her mac.com account.

There are two types of virtual domains that you need to be aware of. Now the first case is this old sendmail style. If you were using Mac OS X Server Jaguar that had sendmail, 10.3 and later have Postfix. Postfix, however, has a sendmail compatibility mode. If you use the default configuration, you don't need to worry about this. However, if you're creating this from scratch or by hand, you need to pay attention.

When you use sendmail style virtual domains, that means everything on the left-hand side of an email address will go to that user account, even if it hasn't been explicitly specified. In this case, we have two customers, Joe and Jane, and Joe has Bananasoftware.ca, and Jane has Guava.ca. However, [email protected] is not a valid email address, and neither is [email protected].

With sendmail style virtual hosting, this email address will continue to receive email and will go into their mail accounts. Any mail sent to this address is likely to be spam, and we don't want that to happen. So if we use post-fixed-style virtual domains, this isn't a problem, because with a post-fixed-style virtual domain, only email addresses that are explicitly specified in the virtual user table will be allowed through.

Let's summarize the virtual hosting features we talked about. Number one, you can have an email address that will go to multiple people. They can be a combination of local users and remote users. You can have an email address that exists without a corresponding user account. You can think of this as an alias or call forwarding for email. You can provide a catch-all email address, which will receive all email not explicitly specified for that domain.

And finally, you can mitigate dictionary attacks by spammers. By using post-fixed-style virtual hosting, only email addresses that are explicitly defined will allow email to go through. Now, Andrew is going to demonstrate how to use the post-fixed configuration file to set up some of the advanced virtual hosting techniques we described.

Thank you, Paul. So for this demo, we're going to go and set up the advanced virtual hosting slide that Paul just described. And the way we're going to do that is we're going to go a little beyond what the Apple Server GUI tools provide and give a little exposure to the underlying text configuration files. So let's put these apps away. So you'll see that the virtual hosting configuration is still there. That's important. And let's bring up the terminal application.

and change directory to the /etc/postfix directory. This is the directory that stores all the postfix configuration files. And let's start by editing the main one called main.cf. I'm going to do that with vim. And I need to do that with rootly privileges, so I'm going to preface this command with the sudo command, as I've done on this command line.

Let's go to the end of the file, and we're going to add a line. It's called Virtual Alias Maps. Now, this is the parameter that tells Postfix where to look for this virtual hosting information. Let's go ahead and set that to Etsy Postfix Virtual. Now the hash just tells Postfix what kind of file or how the storage is laid out in that file. Many of the Postfix configuration files are going to be the hash type.

And for this demo, that's all we need, so let's go ahead and write out that file. Next, let's edit that virtual file. So this file already has a bunch of comments and information there that we can look at. I'm going to jump to the end of the file. And let's go ahead and work through the slide that Paul had.

So we had [email protected] and we wanted that to go to Joe, Joe Bob, and Jane. Next, we had the catch-all email address. So any other email address that's not already specified at Banana Software. Next, we had the catch-all email address. So any other email address that's not already specified at Banana Software.

[email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] Now that Postfix, now that we've told Postfix about this new table, we also need to have Postfix reload its configuration files. And the way we do that is with the Postfix reload command. And we get a message back saying that the Postfix Mail System has been refreshed. So now all of our changes are in effect. And so now we've configured the slide that Paul laid out in the Advanced Virtual Hosting slide. I'll turn it back over to Paul now.

Thank you very much, Andrew. Let's do a quick recap of what we had to do to configure the post-fix configuration file. First off, we have to do all these commands as root. We need to edit the main configuration file and enable the virtual-alias-maps command. Next, we need to edit the virtual file itself and define the email address configuration that we'd like. Once we've updated the map, we run the post-map command to create the hash that post-fix will use. And finally, we reload the post-fix configuration file using the post-fix reload command. Now, there are two things about using post-fix versus open directory.

First of all, the post-fixed configuration files are accessible by standard UNIX tools like VI, Emacs, and grep. And the second advantage to this method is that the post-fixed configuration file is compatible with any other post-fixed configuration file on any other UNIX flavor that you may happen to be running. Finally, let's move on to stopping spam and viruses.

Unwanted email is inundating your server. There are two ways we provide to stop it in Mac OS X's server. First of all, we can help you stop spam. There are many different strategies you can employ to stop spam. You can use real time black hole lists or RBLs. You can use Spam Assassin, which is a server side filtering tool. You could employ a challenge response system, which means that everyone who sends mail to one of your users has to fill out a form to prove they're human. You could use a white listing technique, where you only accept mail from senders that you've previously explicitly validated.

You could also employ client side filtering, like Mac OS X's junk mail filter. We're going to talk about RBLs, and we're going to talk about Spam Assassin. When it comes to viruses and worms, you say, well, Mac users aren't really affected by this stuff. You know, why should we care?

Well, first of all, not all of us have the luxury of working in an all Mac environment. All right. These are annoying, they waste bandwidth, and you should really be a good internet citizen and stop them from propagating further. Spammers will often explicitly target the backup MX because they know it's often less protected.

So, what about Real-Time Blackhole Lists? What can they do for you? Well, the upside is by enabling them, there's a dramatic decrease in the amount of spam you receive. It just gets stopped before it's delivered to your users' mailboxes. The downside to this is they're often false positives.

These lists are maintained by third parties over whom you don't have control, and it's often difficult to get on a list if you've been put on one inadvertently. Sometimes there are political arguments over who should be on a list or who shouldn't. With those caveats said, they're still extremely helpful.

The first item you see on the list here is rbls.org. This isn't an RBL itself, but it's actually a real-time check which you can enter an IP address into, and it will tell you how many RBLs are blocking this particular IP address. The rfcignorant.org RBL will block mail from servers who aren't configured properly. This means they aren't accepting mail for postmaster or abuse, or they don't have reverse DNS setup.

Spamhouse.org, ORDB.org, NJABL.org, Spamcop.net, or some other servers you can use. When we get to the end of the slides, you'll see a URL for a site that lists dozens of different blackhole lists, and you can consider using these for your organization depending on which you feel are appropriate.

Now, spam assassin is a server-side filter, and that occurs after you've received the mail. So if it hasn't been blocked by your server using an RBL, spam assassin takes a look at it. And it employs a bunch of different filters. These filters will look at the content of the message.

They'll look at the message headers. They'll decide, does this match my rules? And any time it matches a rule, it's assigned a score. If the score exceeds a certain threshold, that message gets marked as spam. If the message is marked as spam, you can configure what to do with it, whether you want to keep the message, whether you want to delete the message, or bounce the message.

In addition to filtering messages based on their content and the message body, SpamAssassin can use RBLs and assign an additional score if a message is sent from a server that's in an RBL. It can employ Bayesian filtering, which analyzes the message content, similar to the way junk mail filter works.

Well, what about viruses? Well, when it comes to viruses, Tiger includes ClamAV, which is an open-source anti-virus tool. It will scan the email for viruses, and once it's received, once it's found a virus, it has a few options what it can do with it. It can delete the message right away, it can quarantine it so you can check if it really is a virus-infected email, and it can bounce the message. Now, bouncing the message is a really bad idea.

Most of the Windows viruses and worms that are out there will forge both the from, header, and the return address. So if you choose to bounce messages, you'll be sending them back to some innocent third party who will be inundated with bounce messages and wondering why they're getting them. You also have a few notification options where you can notify the user who received the message or you, the system administrator, one of these messages is received. So now Andrew will demonstrate how to configure Mac OS X Server to use SpamAssassin in ClamAV.

Thanks, Paul. So this is the last session of the day and I'm getting a little antsy to get out of here for the weekend, so I think I'm just going to try to race through this demo as fast as I possibly can. So let's bring up Server Admin Application. Let's bring up the Filters tab here. Let's check the box to turn on SpamAssassin. Check the box to turn on ClamAV. Check the box to have my virus database definitions updated. Click Save, and I think I'll hand it over back to Paul.

Wow, Andrew, that was really quick. Is there anything else you can tell us? Well, actually, okay. All right. Good. So let's go back and take a closer look at some of these other options in the GUI. So Paul talked about the threshold that has to be met by SpamAssassin. So this is a control for that.

So least, moderate, and most. So if you leave it on least, even mildly suspicious mail will get marked as junk. And if you have it set on most, it will take many different criteria in order for a message to get marked as junk. Accepted languages. Now SpamAssassin has some facility to try to detect what language a given email message is written in. And so this selection lets you control and choose those languages that you do not want to be considered a potential characteristic of junk mail.

Similarly with Locales, SpamAssassin has some knowledge of what character sets are associated with given country codes. So again, this selector lets you choose those country codes that you do not want to be considered as a potential characteristic of junk mail. Then this is some of that notification option that Paul was mentioning.

Once the message is identified as junk mail, you can choose to bounce, not such a great idea usually, to delete, deliver, or to redirect. Let's leave it undelivered, and you can see that there are some additional options, such as editing the subject line automatically. Keep in mind that SMAM Assassin already adds its own header, so you might want to look at that instead. Or you can choose to encapsulate the mail as an attachment to a given message.

Then this is some of that notification option that Paul was mentioning. Once the message is identified as junk mail, you can choose to bounce, not such a great idea usually, to delete, deliver, or to redirect. Let's leave it undelivered, and you can see that there are some additional options, such as editing the subject line automatically.

Keep in mind that SMAM Assassin already adds its own header, so you might want to look at that instead. Or you can choose to encapsulate the mail as an attachment to a given message. And I think that's it for this final demo on Spam Assassin and ClamAV, and I'll turn over the rest of the session to Paul.

Thank you very much, Andrew. So Mac OS X Server really makes it easy to stop spam and virus-infected emails from getting to your mail server. Now onto the last portion of our talk. You've heard there are over 200 new features in Tiger. Well, this is one you probably haven't heard about. It's Mail Account Bundles. What are Mail Account Bundles?

They let you easily extend mail setup assistant for your organization. You can put custom panels in that will reduce the number of steps your users have to go through and the amount of information they have to enter. This makes it really easy for them to configure their account when they don't have to know the server or how to turn on SSL or anything like that. It's going to mean fewer calls for you and your support desk and fewer hassles. They're much less likely to make a mistake.

So what kind of things can you configure with Mail Account Bundles? Well, you can configure the name of the account, the server name, the type of authentication such as Kerberos or MD5. You can choose the domain name for the email address. You can specify if the email address has to match the name of the account. You can choose whether SSL is enabled or required and whether users are allowed to change this.

You can say, Aha, what if you're stuck and you need more information? I'm going to give you a clickable URL which points to a web page on say your company's internet, which will have even more information. And finally, these Mail Account Bundles are also localizable. So if your organization provides mail services to users who speak different languages or are in different countries, you can use one Mail Account Bundle and give it to everyone, and it will provide the information in their language.

So what does this look like? Well, take a look at the screenshot here. In this Mail Account Setup Wizard Assistant, we have Banana Software, our fictional company. And their logo appears here. And in this case, you can see the username has been filled in as Joe, and appbananasoftware.ca has already been specified. That means when the user gets to the next screen, they don't have to fill that information in.

You can also let the email address be unrestricted. So if your organization is large and you have multiple people. You can also let them fill in the email address. And you can also let them fill in the email address. And you can also let them fill in the email address. And you can see here, this field's not editable, which means the users can't accidentally mistype the mail server and start getting wrong password or server not found error messages.

So how do you create one of these? Well, we provide one for .mac. If you take a look in /library/mail/accounttypes, you'll find one. Take that bundle and make a copy. Inside there, you'll find a TIFF file containing the .mac globe logo and a plist called mailaccounts.plist. This is a file you need to edit. It has a bunch of unique IDs for both the sending and receiving accounts. You need to create your own. To do this, use the UUID Gen Command Line tool.

Once you're finished editing the plist, you save it. You can provide a graphic such as your organization's logo. And then to test it, stick it in your library folder. And this can go in /library, tilde/library, or /network/library, whatever you feel is most appropriate. If you want to, you can go ahead and provide an installer for your users that will put this in the right place. If you preconfigure systems for them before you deploy them, go ahead and include this as one of the files.

So, what did we learn today? Well, in summary, we've talked about how you can secure your mail. So you can go home at the end of the session and you can disable plain text passwords on your server. Make sure they can't be read in transit. You can go and you can enable SSL, so your entire session is secure. You can get SMIME and you can start signing and encrypting your mail.

You'll be able to filter your mail. You can use RBLs to block spam before it reaches the server. You can use SpamAssassin to minimize the amount of spam that reaches your users' mailboxes even after it's accepted. You can use ClamAV to stop virus-infected emails from getting to your users. And finally, you can go and deploy a mail account bundle so when your users have to configure their mail client, they have much less work to do.

So if you need any more information, the WWDC website contains documentation, resources, sample code. For those of you watching at home or on the DVD, there are a few other sessions you might find interesting. The Mac OS X Server Overview, Moving to Tiger Server from Windows, Upgrading to Tiger Server, Managing Clients in the Enterprise, and Enterprise Messaging Solutions. Now, we'll turn it over to Jason Anthony Guy who will manage the Q&A.