MailHosting

From HerzbubeWiki
Jump to navigation Jump to search

This page contains information about how I organize and configure my mail hosting. The current web hosting provider is mailbox.org. Things hosted on their servers are:

  • Mailboxes for all household members
  • Shared household calendar
  • Shared household addressbook

Also see the wiki page DnsHosting.


Basic account organization

Team

  • An initial mailbox.org account is created.
  • The initial mailbox.org account can create further team accounts that are linked together within a team/group.
  • Team accounts are regular mailbox.org accounts which have their own price plan.
  • The initial mailbox.org account ("creator account") which creates the team accounts can decide that the costs of the team accounts will be billed to the creator account.
  • The initial mailbox.org account is the administrator of the team. This can be changed.


Custom domains

  • Each team account (both the initial mailbox.org and the team accounts added later on) can define 0-n aliases for a custom domain. One of the aliases can be the catch-all.
  • For a custom domain the following 4 aliasses (which don't contribute to the price plan limit) must be defined: postmaster@, abuse@, hostmaster@ und webmaster@.


Team accounts

Create a team account

  • Login to the admin account.
  • Navigate to Settings > mailbox.org > Team Mail Account > Gemeinsame Abrechnung > Jetzt aktivieren.
  • Also see this Knowledge Base article.


View team members / change admin

To view the members of the team, and also to select a different account to become the administrator of the team:

  • Login to any of the accounts that are part of the team.
  • Navigate to Settings > mailbox.org > Vertrag und Tarif.
  • Scroll down to the bottom of the page.
  • Only the current administrator has the option to select a different team account to become the new administrator.


Custom domain

Summary

Fully integrating a custom domain into mailbox.org consists of the following steps:

  • Receiving mail. These steps are all explained in detail in this Knowledge Base article.
    • Add a DNS TXT record that allows to define aliases for the domain on mailbox.org.
    • Define the aliases.
    • Change the DNS MX records for the custom domain so that they point to the mailbox.org servers.
  • Sending mail
    • Configure DNS to ensure messages are accepted by others.
    • Enable mailbox.org to send mails for the domain.
  • Refine DNS records for other purposes:
    • Optimizing spam reputation
    • Automating client configuration


Add DNS TXT record

In order to know how the TXT record looks like, you need to obtain the details from mailbox.org. This is how it works:

  • Login to one of the accounts that wants to receive email for the domain.
  • Navigate to Settings > mailbox.org > E-Mail Aliasse
  • In the section related to custom domains, enter one of the addresses that you want to receive email for. For instance info@grunzwanzling.ch.
  • In the background a check is now made whether a DNS TXT record already exists. Because the record does not exist yet, an error message is displayed, with the instructions to create the DNS TXT record and what data to add to it.
  • Two kinds of DNS TXT record can be set up: One of them allows all of the team members to define aliases for the custom domain, the other allows only the current team account to define aliases (the current team account "owns" the domain, so to speak).
  • Choose the desired variant. In my case I always choose the variant that allows all team (= household) members to define aliases.


Define the aliases

Once the DNS TXT record has been set up, the aliases can be defined.

  • Login to one of the accounts that wants to receive email for the domain.
  • Navigate to Settings > mailbox.org > E-Mail Aliasse
  • In the section related to custom domains, enter all of the addresses that you want to receive email for.
  • Note: At the top the information is now displayed how the DNS MX records need to be set up to actually receive email for the domain. Do not do this before you have set up all the aliases for which you want to receive messages.
  • To define a catch-all alias, use the format "@<domain-name>". For instance, "@grunzwanzling.ch". For details see the Knowledge Base article.


Change DNS MX records

Once all aliases have been defined, the DNS MX records can be changed as follows: 

<domain-name>.  IN MX 10 mxext1.mailbox.org.
<domain-name>.  IN MX 10 mxext2.mailbox.org.
<domain-name>.  IN MX 20 mxext3.mailbox.org.


Configure DNS to ensure messages are accepted by others

Although mailbox.org now sends messages for the domain, receiving mail servers will probably reject those messages, resulting in bounces such as the following:

Your email has been blocked because the sender is unauthenticated. 550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM.

The steps in this section show how to set up DNS records for SPF, DKIM and DMARC. They are all explained in detail this KB article. Setting up these DNS records for a domain will make the domain reputable and ensure it will not be added to any blacklists.


SPF

The SPF (Sender Policy Framework) standard says that a DNS record is used to specify which server is authorized to send messages on behalf of the domain.

To support SPF:

  • Add a DNS TXT record
  • Name = @
    • My DNS provider (CloudFlare) automatically translates @ into the domain name.
  • Content = v=spf1 include:mailbox.org -all
    • The mailbox.org KB article uses ~all, which expresses that a receiving mail server should not reject an incoming message if it is not sent by one of the mailbox.org servers, but should instead "apply further tests to determine whether the message is spam". Since I know 100% that I want to send messages only via mailbox.org, I changed this to -all, which allows a receiving mail server to outright reject messages that are not sent via mailbox.org.
    • Historical note: While I still had a dedicated server with a static IP address, I had set this up with content v=spf1 ip4:82.195.228.21 -all


DKIM

The DKIM (DomainKey Identified Mail) standard says that a sending mail server (mailbox.org in this case) signs outgoing messages. DNS records specify the information that receiving mail servers can use to verify the signature, thus proving that the message has not been tampered with. Apparently there are various ways how to supply DKIM information via DNS, but mailbox.org recommends to define 4 CNAME records: 

Name                 Target
---------------------------------------------------
MBO0001._domainkey   MBO0001._domainkey.mailbox.org
MBO0002._domainkey   MBO0002._domainkey.mailbox.org
MBO0003._domainkey   MBO0003._domainkey.mailbox.org
MBO0004._domainkey   MBO0004._domainkey.mailbox.org


DMARC

DMARC (Domain-based Message Authentication, Reporting and Conformance) extends SPF and DKIM in that it allows to specify how a receiving mail server should check the domain used in the "From:" message header address. This check is called "alignment check".

  • SPF: Check that the domain used in the "From:" message header address is the same as the domain used in the SMTP "MAIL FROM" address.
  • DKIM: Check that the domain used in the "From:" message header address is the same as the one used in the DKIM signature.
  • For both checks DMARC allows to specify whether the check should be "strict" or "relaxed". The strict check requires that the domains be exactly the same, the relaxed check allows that the "From:" message header address may contain a subdomain. The default for both checks is to be relaxed.

The entire DMARC check consists of the "alignment check" plus the regular SPF and DKIM checks. DMARC allows to specify a policy what the receiving mail server should do if the DMARC check fails, as well as options how failures should be reported.

To support DMARC:

  • Add a DNS TXT record
  • Name = _dmarc.@
    • My DNS provider (CloudFlare) automatically translates @ into the domain name.
  • Content = v=DMARC1;p=reject;rua=mailto:postmaster@<domain-name>
    • The parameter p=<value> defines the policy mentioned above, i.e. what a receiving mail server should do with messages that fail the DMARC check. Value none says they should accept the message and deliver it to the recipient, value quarantine says they should accept the message and treat it as "suspicious" (may result in delivering the message to the recipient's spam folder), and value reject says they should reject the message.
    • The email address noted in the "rua" parameter (which must belong to the domain for which the DNS TXT record is created) will periodically receive so-called "aggregate reports" about "DMARC activities" from organizations that run receiving mail servers. So far I have no experience how often these report messages are received, who will send them, and whether they are useful.
    • Another parameter "ruf" can be set to receive so-called "forensic reports", which seem to be very technical reports. Apparently it is not legal to set this parameter if you are living, or run your business, in Germany, which is why mailbox.org does not recommend settings this parameter. The "ruf" parameter is set exactly the same way as the "rua" parameter: ruf=mailto:postmaster@<domain-name>.


Enable mailbox.org to send mails for the domain

The following steps are explained in this KB article.

  • Login to one of the accounts that wants to send email for the domain.
  • Navigate to Settings > mailbox.org > Alternative Absender
  • Enter the sender address and press button "Aktivierungslink zusenden" ("send activation link")
  • You should now receive a message from mailbox.org that contains an activation link.
    • Since you have already set the DNS MX records to point to mailbox.org (see previous section), the message with the activation link will land in your mailbox.org inbox.
  • Click the activation link. This proves to mailbox.org that you are in control of the domain, and of the mailbox that receives messages for this sender address.
  • Refresh the mailbox.org settings page from which you sent the activation link. The sender address will now be listed. It will now also be available when you send a message from the mailbox.org web UI.
  • Of course, in mail clients other than the mailbox.org web UI you have to configure the sender address separately. However, mailbox.org will now happily accept messages from other mail clients that use this sender address.
  • Important: Send one test message from the mailbox.org web UI. Only when you do this will the mailbox.org servers start to perform DKIM signing.


Important notes that are not documented anywhere but which I found out by trial & error:

  • In theory it is not necessary to go through the above steps - mailbox.org allows sending mails for the domain from a client that is not the web UI even without activating any sender address. There is one problem, though: The mailbox.org servers will not perform DKIM signing. In my tests with GMail, this resulted in the messages being classified as spam by GMail - interesting enough this happened even though there was a DMARC record that specified the "reject" policy.
  • Once you have clicked the activation link and the sender address is visible in the team account's settings on mailbox.org, it is still necessary to send at least one message via the mailbox.org web UI to make the mailbox.org server perform DKIM signing. It must be the mailbox.org web UI that does the sending, sending via an external mail client does not start DKIM signing.
  • Once DKIM signing starts working for the first sender address, it will continue to work for any sender address, even sender addresses configured in external mail clients and for which no activation was done via mailbox.org web UI.


Automate client configuration

Some email clients try to simplify the process of configuring a new mail account by defining a "protocol" where the mail provider shall store information about IMAP/POP3/SMTP server configurations, and how the email client is supposed to find this information. The details are explained in this KB article. The KB article lists two different protocols.

mailbox.org supports these protocols already. Because household members will use an @mailbox.org address/user name to authenticate, nothing needs to be done for our custom domains.


Migration

Summary

The mailbox.org Knowledge Base lists 3 ways how to migrate data from another mail provider:

  • Use the Audriga migration service. KB article, Audriga handbook.
  • Embed an external IMAP account into the mailbox.org web UI, then use the mailbox.org web UI to manually move or copy messages from the external account to the mailbox.org account. KB article.
  • Add the mailbox.org IMAP account to an email client which already has the external IMAP account configured, then use the email client UI to manually move or copy messages from the external account to the mailbox.org account. KB article.


Calendar and addressbook data

  • Can be exported to .ics and .vcf files, then be imported.


Embedding an external IMAP account into mailbox.org web UI

Note: I attempted to migrate my data with this approach first, and since I was successful I didn't look at the others anymore.

  • Login to the account that you want to configure
  • Go the mail app, then on the left-hand side at the bottom click "E-Mail-Konto hinzufügen"
  • At first you can only supply very simple information: Email address and password. This kind of authentication will fail, after that you can then configure the full set of IMAP and SMTP credentials.
  • Setting up the account takes a long time, in my case the process even stopped after a while and I had to start it again. But eventually the account should be added and you will be able to access its contents.
  • Once you can access the external account you can start migrating the data by selecting a folder and from the context menu choosing "Ordner verschieben" (move folder).
  • Alternatively you can select a folder and on the right hand side, where the messages are listed, select "Alle Nachrichten verschieben" (move all messages) from the "Alle" menu.


Calendar data

Data export

  • The assumption is that the existing addresses are available via CalDAV, and that the CalDAV account is integrated in Apple's Calendar app.
  • Open the Calendar app.
  • Select the calendar in the list on the left-hand side.
  • Select File > Export > Export ...
  • Store the data in in an .ics file.
  • Repeat for all calendars.


Data import

  • Login to the administrator account of the team.
  • Navigate to the Calendar app.
  • Create a new calendar - in case the import fails somehow, the new calendar can be easily deleted and a new attempt can be made.
  • Select the new calendar, in the hamburger menu select "Import".
  • Select the .ics file to upload from your local machine.
  • Click "Import".


Addressbook data

Data export

  • The assumption is that the existing addresses are available via CardDAV, and that the CardDAV account is integrated in Apple's Contacts app.
  • Open the Contacts app.
  • Select the address book in the list on the left-hand side.
  • Select File > Export > Export vCard ...
  • Store the data in in a .vcf file.


Test data import

  • Login to the administrator account of the team.
  • Navigate to the Address Book app.
  • Create a new temporary address book - just in case the import fails somehow, the temporary address book can be easily deleted and a new attempt can be made.
  • Select the temporary address book, in the hamburger menu select "Import".
  • Choose the "vCard" format.
  • Select the .vcf file to upload from your local machine.
  • Click "Import".


Final data import

  • Once you are satisfied that the data import works as expected, delete the temporary address book.
  • Repeat the import into the existing default address book, labeled "Kontakte".
  • The reason why the "Kontakte" address book must hold the addresses is that when addresses are exposed via CardDAV to macOS and iOS, new addresses will only be added to the default address book.


Household configuration

Mail

Each household member has its own mailbox.org account. All of them are linked together as team accounts.

  • Patrick (administrator)
  • Francesca (team account)


Here is the list of alias mappings:

Domain Address Destination Mailbox Remarks
herzbube.ch catch-all Patrick
 moser-naef.ch patrick, catch-all Patrick
francesca, fm, francesca.moser, hochzeit, salsa, bettybossi, ebay, carol Francesca
grunzwanzling.ch catch-all Patrick
francescamoser.ch catch-all Francesca


Spam

Training:

  • If a spam mail is received despite all the spam protection measures that are in place, it can be moved to the Spam folder to train the spam filter (I assume SpamAssassin) so that hopefully next time a similar message will be recognized and blocked immediately.
  • If a message is moved to the Spam folder by accident, it can be moved from there to the Inbox to "unlearn" it.


Spam protection:

  • KB article 1, KB article 2
  • I leave the default settings as they are:
    • Greylisting = Enabled
    • SMTP plausibility check = Enabled
    • RBL check = Enabled
    • Block executable attachments = Enabled
    • Sensitivity when checking content for spam = Normal. Note: This is actually SpamAssassin.
    • What to do with messages classified as spam = Reject
  • There's only one setting that can be turned up for an even stricter protection: The sensitivity when checking content for spam can be increased.
  • For the moment I leave things as they are.


Shared calendar

Exposing an address book via CalDAV:

  • Server address = https://dav.mailbox.org:443
  • Credentials = mailbox.org account credentials
  • All calendars of the account are exposed, i.e. both personal/private calendars, and shared calendars that the account was invited to, are exposed.


Shared address book

Exposing an address book via CardDAV:

  • Server address = https://dav.mailbox.org:443
  • Credentials = mailbox.org account credentials
  • All address books of the account are exposed, i.e. both personal/private address books, and shared address books that the account was invited to, are exposed.


iOS / macOS notes:

  • On macOS, the Contacts app only shows a unified view of all address books.
  • On iOS, the Contacts app shows the individual address books, but the user can also select a unified view of all address books.
  • When the user adds a new contact, that contact is always added server-side to the default address book "Kontakte".
    • On macOS where the user is not aware of any address books, this happens naturally.
    • On iOS, if the user has selected a particular address book that is not the "Kontakte" address book, then adds a new contact, the contact is first shown under the expected address book, but then disappears and reappears under "Kontakte".
  • When the user edits or deletes an existing contact, the correct contact in the correct address book is edited/deleted.


Conclusions:

  • Because of the iOS / macOS restriction that new contacts are always added to the "Kontakte" address book, it is best that all addresses are maintained in that address book.
  • Furthermore, all devices must be configured to use the same mailbox.org account. If the personal account of a household member were used, new contacts would go to different "Kontakte" address books.
  • In case household members want to use the mailbox.org web UI, the "Kontakte" address book can be made a shared address book.


Sharing an address book is described in this KB article. Quick details:

  • Select the address book, in the hamburger menu select "Freigeben / Berechtigungen".
  • Add the mailbox.org addresses of the other team accounts that the address book should be shared with.
  • For each team account select the permissions they should have. In my case I choose "Autor", i.e. read / write / delete permissions.


Things that I found are not supported by the mailbox.org web UI:

  • Phone numbers of type "other". In the .vcf file these appear with "TEL;type=OTHER". The web UI does not show these phone numbers, but the iOS / macOS Contacts app shows them.


Backup

Details of the backup services performed by mailbox.org are explained in this KB article.

Email

  • mailbox.org performs automated daily backups of the entire user mailbox. Backups of the last 7 days are available.
  • It appears the backup data is not accessible for download, or at least I have not found a way to do so.
  • A backup can be restored by navigating to Settings > E-Mail-Backup. It's possible to restore only the inbox, or the entire mailbox. The data will be restored into a new folder, i.e. existing data is not touched. Because of this the account needs sufficient reserve disk space to accomodate the restored data.

Calendar and address books

  • Officially mailbox.org does not perform backups of calendar and address book data. It is unclear whether they perform such backups in the background on the system level, but at least they do not expose any backup data as they do for emails.
  • The KB article linked to at the start of this section recommends doing backups by exporting the calendar or address book as .ics / .vcf data files. This is a manual action.


Things to investigate


Requirements

These are the requirements that a mail hosting provider must fulfill:

  • Basic services
    • Must provide an independent mailbox for each household member.
    • Must provide a calendar that can be shared (read/write) among all household members.
    • Must provide an address book that can be shared (read/write) among all household members.
  • Service independence
    • Must allow mail hosting independently of DNS hosting, i.e. I want to do my own DNS hosting somewhere else.
  • Service access
    • Must provide access to the mailbox via IMAP.
    • Bonus points for access via webmail.
    • Must provide access to the shared calendar via CalDAV.
    • Must provide access to the shared address book via CardDAV.
    • IMAP, CalDAV and CardDAV traffic must be encrypted (SSL/TSL).
  • Domains
    • Must allow sending and receiving mails for custom domains.
    • Must support 4 custom domains.
    • Must support at least one of the domains being shared among household members, i.e. certain domain addresses go to one mailbox while other domain addresses go to another mailbox.
    • Must support wildcard (aka "catch-all") handling, i.e. one mailbox can be configured to receive messages for all domain addresses that are not explicitly mapped to a specific mailbox.
  • Certificates
    • In case the service provider requires any kind of custom domain specific certificates, the service provider must take care of providing such certificates in an automated fashion (generation, renewal).
  • Disk space
    • Must provide 10 GB disk space per mailbox.
    • Bonus points for more disk space.
    • At the time of migration to mailbox.org: 445 MB for mailbox 1, 782 MB for mailbox 2.
  • Must provide high protection from spam. The baseline is the following, any of these measures not provided is "bad karma".
    • Greylisting.
    • SMTP plausibility check.
    • RBL check.
    • Spam filtering (e.g. SpamAssassin).
    • If not already the default, the option to turn on rejection of messages that fail any of the checks.
    • Ability to train/untrain the spam filter.
  • Email
    • Must provide unlimited number of folders.
    • Must provide at least 20 aliases per mailbox.
    • Bonus points for providing the ability to define rules where incoming messages are placed depending on user-definable criteria.
    • Bonus points for providing the ability to define custom spam filter rules.
  • Calendar
    • Must provide unlimited number of calendar entries.
    • Must provide an option to export calendar data in .ics format.
  • Address book
    • Must provide unlimited number of address book entries.
    • Must provide an option to export address book data in .vcf format.
  • Backup
    • Must provide a data backup service.
  • Other services
    • Must provide the possibility to migrate (import) mail, calendar and address book data.
Retrieved from "https://wiki.herzbube.ch/index.php?title=MailHosting&oldid=7114"