Users primarily interacted with the master machine via their online control panel, but it was also possible to use email to apply updates.
To allow updates to be applied by email we defined several MX records pointing soley at the master machine - and then had some additional qpsmtpd plugins which would allow administrative emails to be recognised and processed.
Table E-1. Email Interface to the controller.
| Email Address | Intended Purpose |
|---|---|
user.org@spam.m-s.com | The given message would be trained as SPAM for the domain - by updating the spambayes database.. Remember that the site controls are all per-domain, so there is a single spam/ham dataset for each domain not each localpart. |
user.org@notspam.m-s.com | The given message would be trained as non-SPAM for the domain. |
user.org@whitelist.m-s.com | Messages would be Bcc'd here, and the original recipient would be added to the whitelist for the appropriate domain. |
user.org@control.m-s.com | Many settings for a domain, such as the list of user-accounts, could be manipulated by email - providing the message had a valid GPG-signature. |
For example to automatically whitelist an email address outgoing messages could be BCC'd to a specific address:
Example E-1. Auto whitelisting.
To: recipient@example.org From: sender@user.org Bcc: user.org@whitelist.m-s.com Subject: Hello, baby! This message is for you ..
Any recipients of the email (i.e. addresses listed in the To: or Cc: fields) would be added to the whilelist for the appropriate domain.
Because these addresses were only useful upon the master machine the plugins were not loaded and used upon the satellite MX machines.