Using Maia Mailguard in CMS This documentation is intended to illustrate the basic common use case for Maia Mailguard in the CMS userbase.  It is 

not intended to cover all exhaustive uses of the system.  If you have questions regarding the spam scoring system, the 

defaults, or the implications of the scanning service on mail forwarding, please address your questions to the CMS help 

queue at help@cms.caltech.edu. 

This documentation assumes you are using the Firefox web browser.  If you are using Safari, Internet Explorer, or Opera, 

you will need to know how to import digital certificates into your application. If you have already imported the CMS CA 

certificate into your web browser (instructions are available here: http://sysadminhelp.cs.caltech.edu/faq/#index12h2), 

you can skip head to Step Three: User Settings, below. 

Step One: Importing the Certificate 

You can import the CA certificate for the CMS cluster by opening Firefox and entering the URL: 

http://pki.cms.caltech.edu/ejbca/retrieve/ca_certs.jsp 

Click on the “Download to Firefox” link under CA: CMS‐CA.  This will import our digital signing authority, which you can 

use to trust any CMS‐signed certificate. 

If you are using Maia Mailguard from a computer with limited access, you can also import the certificate manually. 

First, open a web browser and go to the URL https://maia.cms.caltech.edu 

You will see a warning dialogue in Firefox.  Click on “I Understand the Risks” to expand the options, then click on the 

“Add Exception” button. 

 

This will open the “Add Security Exception” dialogue box.  Click on “Confirm Security Exception” to continue. 

 

Step Two: User Login 

You will see the following login dialogue on the Maia Mailguard website: 

 

Type in your full CMS email address not just your username (i.e., psc@cms.caltech.edu) in the “E‐mail Address:” box and 

your CMS user password in the “Password” box and hit the “Login” button. 

You will now see the “Maia Mailguard Welcome Screen”: 

 

The labels under the menu bar above are not present (although you can see them if you mouse‐over the icons), they are 

included here for easy reference. 

   

Step Three: User Settings 

To change your default user settings, click on the gear icon on the menu bar (handily labeled above as “User Settings”).  

This will take you to the following screen: 

 

Here you can see  the default settings  for  the Maia  interface.   This  is also  the screen where you add additional email 

addresses to your Maia queue.  If you have an ACM, CDS, or CS email address, these addresses must be linked to your 

CMS queue.   To do  this, you  input your  full alternate email address  in  the “Email address:” box, and your CMS user 

password in the “Password:” box… for example: 

 

You will  then  see  the main  settings  screen with  your  additional  email  address  displayed,  and  an  acknowledgement 

message that the additional email address has been linked to your account: 

 

Your CMS address should always be listed as the Primary Address, as this is the endpoint destination for your email.  If 

you  possess  mail  addresses  in  more  than  one  additional  domain  (for  example,  user@cs.caltech.edu  and 

anothername@acm.caltech.edu) in addition to your CMS account, you should repeat the above steps to link all of your 

email addresses together to your main account. 

Step Four: User Preferences 

At this point, the system  is now configured to scan your mail, and you have opted‐in to the scanning service.   You can 

accept the system defaults, or you can adjust your user preferences.  To change/view your user preferences, click on the 

email address listed as your Primary Address: 

 

And you will see the following screen: 

 

As you can see  from  the above, by default all messages are scanned  for spam, viruses, bad headers, and attachment 

types.   Those messages will then be  labeled (if they fail one or more of the tests) and delivered to your mailbox.   One 

major change from the Barracuda: by default, the system does not quarantine messages. 

Question: Why isn’t the quarantine enabled by default?  That seems to be really useful! 

Answer: Since CMS allows people to retain their email addresses after they depart the cluster, the default for 

mail handling needs to be “label and deliver”, since many users of CS/CMS/ACM/CDS email no  longer have an 

active account on the cluster, and will never check their quarantine queue and thus not realize that mail is not 

being delivered. 

Question: What happens if I select “Disabled” on the filtering options? 

Answer:    You  selectively  opt‐out  of  that  portion  of  the  scanning  service.    In  the  case  of  virus‐infected 

attachments, you are now very possibly going to shoot yourself in the foot, as you are depending entirely upon 

your client‐side virus scanner to protect you.  Do this at your own risk  

Depending  upon  the  sensitivity  of  your  email  and  the  quantity  of  spam  you  receive,  you may wish  to  enable  the 

quarantine  (we  generally  recommend  enabling  quarantine  of messages  for  active  users,  rather  than  discarding  or 

delivering those messages).  This will effectively halt mail delivery of all messages that fail one of the tests and hold the 

mail  in place  in the quarantine until your quarantine  is filled (at which point, Maia will begin discarding the messages 

beginning with the oldest first to make room for new messages in the quarantine) or you manually clear your quarantine 

via the web interface.   

If  you  find  you  are  getting  too many  legitimate messages  labeled  as  “spam”  (or,  too many  spam messages  passed 

through the system as legitimate), you can adjust your “Consider mail ‘Spam’ when score is >=” setting.   

Generally,  you  are  going  to want  the  same  user  preferences  for  all  of  your  email  addresses,  so  you would  use  the 

“Update ALL Addresses’ Settings” button  to commit your changes.    If  this  is not  the case, you can update only  these 

settings, and set the user preferences for your other account by repeating the above process for your additional email 

address(es). 

Step Five: Using the Cache 

Returning to the Home screen, we can examine the different Queues by looking at the shortcut box on the main page: 

 

Here you can see that we have 19 messages in the “ham” (non‐spam) cache.  You can examine the cache by clicking on 

the hyperlink to display the contents of the cache: 

 

Here you can mark unrecognized spam as “Spam” (thus training the filter to better recognize spam in the future), mark it 

as  “Non‐spam”  (confirming  the  status as  legitimate email), or  “Delete”  (which  removes  the message  from  the  cache 

without adding it to either Bayesian database). 

Rescuing legitimate email from the “spam” cache is essentially the same process. 

Question: What happens if I never train the filter or check my cache? 

Answer: The mail system will continue to use the default rules for checking for spam.  Generally, this will work 

fairly well.   However, the more you train the system, the more  likely  it  is that you will cut down on both false 

positives (legitimate email marked as “spam”) and false negatives (spam messages that pass all the other tests).  

The prevention of spam  is an arms  race between  the spammers and  legitimate email system operators;  from 

time to time the advantage swings toward the spammers and from time to time the advantage swings towards 

the legitimate users of email. 

Step Six: The White/Black List 

It may be the case that certain addresses are of greater import than others.  For example, you may wish to always get 

email  from  a  grants manager,  or  a  collaborator.    Similarly,  it may  happen  that  you  receive  abusive  email  from  a 

particular source and wish to quarantine all incoming mail from that source.  You can enable this functionality through 

the use of the White/Black List.  To get there, click on the White/Black list icon on the Home screen, which will take you 

to a page with the following dialogue box: 

 

Adding  an  email  address  to  the white/black  list  is  fairly  straightforward.   Note:  this  is  not  a  simple  Boolean  status.  

Adding an email address to the whitelist creates a custom rule that decreases the spam score from any message labeled 

as coming from that address by a very large amount; adding an email address to the blacklist likewise creates a custom 

rule that  increases the spam score  from any message  labeled as coming  from that address.    It  is still possible to have 

emails on the white/black  list wind up  in your respective caches (virus  infected email, for example, will wind up  in the 

virus queue regardless of the white/black list).