{"id":486,"date":"2017-01-22T03:42:33","date_gmt":"2017-01-22T02:42:33","guid":{"rendered":"https:\/\/blog.unetresgrossebite.com\/?p=486"},"modified":"2017-01-22T06:44:42","modified_gmt":"2017-01-22T05:44:42","slug":"bluemind-migration","status":"publish","type":"post","link":"https:\/\/blog.unetresgrossebite.com\/?p=486","title":{"rendered":"BlueMind Best Practices"},"content":{"rendered":"

Following up on a previous post introducing BlueMind<\/a>, today we’ll focus on good practices (OpenDKIM, SPF, DMARC, ADSP, Spamassassin, firewalling) setting up their last available release (3.5.2) – and mail servers in general – while migrating my former setup (3.14).<\/p>\n

A first requirement to ease up creating mailboxes, and manipulating passwords during the migration process, would be for your user accounts and mailing lists to be imported from some LDAP backend.
\nAssuming you do have a LDAP server, then you will need to create some service account in there,\u00a0so BlueMind can bind. That account should have read access to your userPassword<\/em>, pwdAccountLockedTime<\/em>, entryUUID<\/em>, entryDN<\/em>, createTimestamp<\/em>, modifyTimestamp<\/em> and shadowLastChange<\/em>\u00a0attributes (assuming these do exist on your schema).
\nIf you also want to configure distribution lists from LDAP groups, then you may want to load the dyngroup<\/em> schema.<\/p>\n

Another key to migrating your mail server would be to duplicate messages from one backend to another. Granted that your mailboxes already exist on both side, that some IMAP service is running on both sides, and that you can temporarily force your users password: then a tool you should consider is ImapSync<\/a>. ImapSync can run for days, duplicate billions of mails, in thousands of folders, … Its simplicity is its strength.
\nIdeally, we would setup our new mail server without moving our MXs yet. The first ImapSync run could take days to complete. From there, next runs would only duplicate new messages and should go way faster: you may consider re-routing new messages to your new servers, continuing to run ImapSync until your former server stops receiving messages.<\/p>\n

To give you an idea, my current setup involves less than 20 users, a little under 1.500.000 messages in about 400 folders, using around\u00a030G of disk space. The initial ImapSync job ran for about 48 hours, the 3 next passes ran for less than one hour each.
\nA few years back, I did something similar involving a lot more mailboxes: in such cases, having some frontal postfix, routing messages to either one of your former and newer backend\u00a0depending on the mailbox you’re reaching could be a big help in progressively migrating users from one to the other.<\/p>\n

 <\/p>\n

Now let’s dive into BlueMind configuration. We won’t cover the setup tasks as you’ll find these in BlueMind documentation<\/a>.<\/p>\n

Assuming you managed to\u00a0install BlueMind, and that your users base is stored in some LDAP, make sure to install BlueMind LDAP import plugin:<\/p>\n

apt-get install\u00a0bm-plugin-admin-console-ldap-import bm-plugin-core-ldap-import<\/p><\/blockquote>\n

Note that if you were used to previous BlueMind releases, you will now need to grant each user with their accesses to your BlueMind services, including the webmail. By default, a newly created user account may only access its settings.
\nThe management\u00a0console\u00a0would allow you to grant such permissions, there’s a lot of new stuff in this new release: multiple calendars per user, external calendars support, large files handling detached from webmail, …<\/p>\n

 <\/p>\n

The first\u00a0thing we will configure is some firewall.
\nNote that Blue-Mind recommend to setup their service behind some kind of router, avoid exposing your instance directly to the Internet. Which is a good practice hosting pretty much everything anyway. Even though, you may want to setup some firewall.
\nNote that having your firewall up and running may lead to BlueMind installation script failing to complete: make sure to keep it down until you’re done with BlueMind installer.<\/p>\n

On\u00a0Debian, you may find the Firehol<\/a> package to provide with an easy-to-configure firewall.
\nThe service you would need to open for public access being smtp (TCP:25), http (TCP:80), imap (TCP:143), https (TCP:443), smtps (TCP:465), submission (TCP:587)\u00a0and\u00a0imaps (TCP:993).
\nAssuming firehol, your configuration would look like this:<\/p>\n

mgt_ips=”1.2.3.4\/32 2.3.4.5\/32″
\ninterface eth0 WAN
\n    protection strong
\n    server smtp accept
\n    server http accept
\n    server imap accept
\n    server https accept
\n    server smtps accept
\n    server submission accept
\n    server imaps accept
\n    server custom openssh “tcp\/1234” default accept src “$mgt_ips”
\n    server custom munin “tcp\/4949” default accept src “$mgt_ips”
\n    server custom nrpe “tcp\/5666” default accept src “$mgt_ips”
\n    client all accept<\/p><\/blockquote>\n

You may then restart your firewall. To be safe, you could restart BlueMind as well.<\/p>\n

Optionally, you may want to use something like Fail2ban<\/a>, also available on Debian.\u00a0You may not be able to track all abusive accesses, although you could lock out SMTP authentication brute-forces at the very least, which is still relevant.<\/p>\n

Note that BlueMind also provides with a plugin you could install from the packages cache extracted during BlueMind installation:<\/p>\n

apt-get install bm-plugin-core-password-bruteforce<\/p><\/blockquote>\n

 <\/p>\n

The second\u00a0thing we would do is to install some valid certificate. \u00a0These days, services like LetsEncrypt<\/a> would issue free x509 certificates.
\nStill assuming Debian, a LetsEncrypt client is available in jessie-backports: certbot. This client would either need access to some directory served by your webserver, or would need to bind on your TCP port 443, so that LetsEncrypt may validate the common name you are requesting actually routes back to the server issuing this request. In the later case, we would do something like this:<\/p>\n

# certbot certonly –standalone –text –email me@example.com –agree-tos –domain mail.example.com –renew-by-default<\/p><\/blockquote>\n

Having figured out how you’ll generate your certificate, we will now want to configure BlueMind services loading it in place of the self-signed one generated during installation:<\/p>\n

# cp -p \/etc\/ssl\/certs\/bm_cert.pem \/root\/bm_cert.pem.orig
\n# cat\u00a0\/etc\/letsencrypt\/live\/$CN\/privkey.pem \/etc\/letsencrypt\/live\/$CN\/fullchain.pem >\/etc\/ssl\/certs\/bm_cert.pem<\/p><\/blockquote>\n

Additionally, you will want to edit postfix configuration using LetsEncrypt certificate chain. In \/etc\/postfix\/main.cf<\/em>, look for\u00a0smtpd_tls_CAfile<\/em> and set it to \/etc\/letsencrypt\/live\/$CN\/chain.pem<\/em>.<\/p>\n

You may now reload or restart postfix (smtps) and bm-nginx (both https & imaps).<\/p>\n

Note that LetsEncrypt certificates are valid for 3 months. You’ll probably want to install some cron job renewing your certificate, updating\u00a0\/etc\/ssl\/certs\/bm_cert.pem<\/em> then reloading postfix and bm-nginx.<\/p>\n

 <\/p>\n

The next thing we would configure is OpenDKIM signing our outbound messages and validating signatures\u00a0of inbound messages.
\nDebian has some opendkim<\/em> package embedding everything you’ll need on a mail relay. Generating keys, you will also need to install opendkim-tools<\/em>.<\/p>\n

Create some directory layout and your keys:<\/p>\n

# cd \/etc
\n# mkdir dkim.d
\n# cd dkim.d
\n# mkdir keys keys\/example1.com keys\/example2.com keys\/exampleN.com
\n# for d in example1 example2 exampleN; do \\
\n    ( cd keys\/$d.com;\u00a0opendkim-genkey -r -d $d.com ); done
\n# chmod 0640 *\/default.private
\n# chown root:opendkim *\/default.private<\/p><\/blockquote>\n

In each of \/etc\/dkim.d\/keys<\/em> subdir, you will find a default.txt<\/em> file that contains the DNS record you should add to the corresponding zone. Its content would look like the following:<\/p>\n

default._domainkey IN TXT “v=DKIM1; k=rsa; p=PUBLICKEYDATA”<\/p><\/blockquote>\n

You should have these DNS records ready prior to having\u00a0configured Postfix signing your messages.
\nHaving generated our keys, we still need to configure OpenDKIM signing messages. On Debian, the main configuration is \/etc\/opendkim.conf<\/em>, and should contain something like this:<\/p>\n

Syslog yes
\nUMask 002
\nOversignHeaders From
\nKeyTable \/etc\/dkim.d\/KeyTable
\nSigningTable \/etc\/dkim.d\/SigningTable
\nExternalIgnoreList \/etc\/dkim.d\/TrustedHosts
\nInternalHosts \/etc\/dkim.d\/TrustedHosts<\/p><\/blockquote>\n

You would need to create the 3 files we’re referring to in there, the first one being \/etc\/dkim.d\/KeyTable<\/em>:<\/p>\n

default._domainkey.example1.com\u00a0example1.com:default:\/etc\/dkim.d\/keys\/example1.com\/default.private
\ndefault._domainkey.example2.com\u00a0example2.com:default:\/etc\/dkim.d\/keys\/example2.com\/default.private
\ndefault._domainkey.exampleN.com\u00a0exampleN.com:default:\/etc\/dkim.d\/keys\/exampleN.com\/default.private<\/p><\/blockquote>\n

The second one is \/etc\/dkim.d\/SigningTable<\/em> and would contain something like this:<\/p>\n

example1.com\u00a0default._domainkey.example1.com
\nexample2.com\u00a0default._domainkey.example2.com
\nexampleN.com\u00a0default._domainkey.exampleN.com<\/p><\/blockquote>\n

And the last one, \/etc\/dkim.d\/TrustedHosts<\/em> would contain a list of the subnets we should sign messages for, such as<\/p>\n

1.2.3.4\/32
\n2.3.4.5\/32
\n127.0.0.1
\nlocalhost<\/p><\/blockquote>\n

Now, let’s ensure OpenDKIM would start on boot, editing\u00a0\/etc\/default\/opendkim<\/em>\u00a0with following:<\/p>\n

DAEMON_OPTS=
\nSOCKET=”inet:12345@localhost”<\/p><\/blockquote>\n

Having started OpenDKIM and made sure the service is properly listening on TCP:12345, you may now configure Postfix relaying its messages to OpenDKIM. Edit your \/etc\/postfix\/main.cf<\/em> adding the following:<\/p>\n

milter_default_action = accept
\nsmtpd_milters = inet:localhost:12345
\nnon_smtpd_milters = inet:localhost:12345<\/p><\/blockquote>\n

Restart Postfix, make sure mail delivery works. Assuming you can already send outbound messages, make sure\u00a0your DKIM signature appears to be valid for other mail providers (an obvious one being gmail).<\/p>\n

 <\/p>\n

Next, we’ll configure SPF validation of inbound messages.
\nOn Debian, you would need to install\u00a0postfix-policyd-spf-perl.<\/em><\/p>\n

Let’s edit \/etc\/postfix\/master.cf<\/em>, adding a service validating inbound messages matches sender’s domain SPF policy:<\/p>\n

spfcheck unix – n n – 0 spawn
\n    user=policyd-spf argv=\/usr\/sbin\/postfix-policyd-spf-perl<\/p><\/blockquote>\n

Next, edit \/etc\/postfix\/main.cf<\/em>, look for smtpd_recipient_restrictions<\/em>. The last directive should be a reject_unauth_destination<\/em>, and should precede the policy check we want to add:<\/p>\n

smtpd_recipient_restrictions=permit_sasl_authenticated,
\n    permit_mynetworks,reject_unauth_destination,
\n    check_policy_service unix:private\/policyd-spf<\/p><\/blockquote>\n

Restart Postfix, make sure you can still properly receive messages. Checked messages should now include some Received-SPF<\/em> header.<\/p>\n

 <\/p>\n

Finally, we’ll configure SPAM checks and Spamassassin<\/a> database training.
\nOn Debian, you’ll need to install spamassassin<\/em>.<\/p>\n

Let’s edit \/etc\/spamassassin\/local.cf<\/em> defining a couple trusted IPs, and configuring Spamassassin to rewrite the subject for messages detected as SPAM:<\/p>\n

rewrite_header Subject [ SPAM _SCORE_ ]
\ntrusted_networks\u00a01.2.3.4\/32 2.3.4.5\/32
\nscore ALL_TRUSTED -5
\nrequired_score 2.0
\nuse_bayes 1
\nbayes_auto_learn 1
\nbayes_path \/root\/.spamassassin\/bayes
\nbayes_ignore_header X-Spam-Status
\nbayes_ignore_header X-Spam-Flag
\nifplugin Mail::SpamAssassin::Plugin::Shortcircuit
\nshortcircuit ALL_TRUSTED on
\nshortcircuit BAYES_99 spam
\nshortcircuit BAYES_00 ham
\nendif<\/p><\/blockquote>\n

Configure Spamassassin service defaults in \/etc\/default\/spamassassin<\/em>:<\/p>\n

CRON=1
\nENABLED=1
\nNICE=”–nicelevel 15″
\nOPTIONS=”–create-prefs –max-children 5 -H \/var\/log\/spamassassin -s \/var\/log\/spamassassin\/spamd.log”
\nPIDFILE=\/var\/run\/spamd.pid<\/p><\/blockquote>\n

Make sure \/root\/.spamassassin<\/em> and \/var\/log\/spamassassin<\/em> both exist.<\/p>\n

Now let’s configure Spamassassin to lear from BlueMind SPAM folders content, create or edit\u00a0\/etc\/spamassassin\/sa-learn-cyrus.con<\/em>f with the following content:<\/p>\n

[global]
\ntmp_dir = \/tmp
\nlock_file = \/var\/lock\/sa-learn-cyrus.lock
\nverbose = 1
\nsimulate = no
\nlog_with_tag = yes<\/p>\n

[mailbox]
\ninclude_list = ”
\ninclude_regexp = ‘.*’
\nexclude_list = ”
\nexclude_regexp = ”
\nspam_folder = ‘Junk’
\nham_folder = ‘Inbox’
\nremove_spam = yes
\nremove_ham = no<\/p>\n

[sa]
\ndebug = no
\nsite_config_path = \/etc\/spamassassin
\nlearn_cmd = \/usr\/bin\/sa-learn
\nbayes_storage = berkely
\nprefs_file = \/etc\/spamassassin\/local.cf
\nfix_db_permissions = yes
\nuser = mail
\ngroup = mail
\nsync_once = yes
\nvirtual_config_dir = ”<\/p>\n

[imap]
\nbase_dir = \/var\/spool\/cyrus\/example_com\/domain\/e\/example.com\/
\ninitial_letter = yes
\ndomains = ”
\nunixhierarchysep = no
\npurge_cmd = \/usr\/lib\/cyrus\/bin\/ipurge
\nuser = cyrus<\/p><\/blockquote>\n

Look out for sa-learn-cyrus script<\/a>. Note that Debian provides with a package with that name, that would pull cyrus as a dependency – which is definitely something you want on a BlueMind server.
\nRun this script to train Spamassassin from the messages in your Inboxes and Junk folders. Eventually, you could want to install some cron job.<\/p>\n

Start or restart Spamassassin service. Now, let’s configure Postfix piping its messages to Spamassassin. Edit \/etc\/postfix\/master.cf<\/em>, add the following service:<\/p>\n

spamassassin unix – n n – – pipe
\n    user=debian-spamd argv=\/usr\/bin\/spamc -f -e
\n    \/usr\/sbin\/sendmail -oi -f ${sender} ${recipient}<\/p><\/blockquote>\n

Still in \/etc\/postfix\/master.cf, locate the smtp service, and add a content_filter<\/em> option pointing to our spamassassin service:<\/p>\n

smtp \u00a0 \u00a0 \u00a0inet \u00a0n \u00a0 \u00a0 \u00a0 – \u00a0 \u00a0 \u00a0 n \u00a0 \u00a0 \u00a0 – \u00a0 \u00a0 \u00a0 – \u00a0 \u00a0 \u00a0 smtpd
\n    -o content_filter=spamassassin<\/p><\/blockquote>\n

Restart Postfix. Sending or receiving messages, you should read about spamd in \/var\/log\/mail.log<\/em>. Moreover, a\u00a0X-Spam-Checker-Version<\/em> header should show in your messages.<\/p>\n

 <\/p>\n

Prior to migrating your messages, make sure to mount \/var\/spool\/cyrus<\/em> on a separate device, and \/var\/backups\/bluemind<\/em> on some NFS share, LUN device, sshfs, …. something remote, ideally.
\nYour \/tmp<\/em> may be mounted from tmpfs<\/em>, and could use the nosuid<\/em> and nodev<\/em> options – although you can not set noexec<\/em>.<\/p>\n

Assuming you have some monitoring system running: make sure to keep an eye on mail queues, smtp service availability or disk space among others, …<\/p>\n

 <\/p>\n

Being done migrating your setup, the last touch would be to set proper SPF, ADSP and DMARC policies (DNS records).<\/p>\n

Your SPF record defines which IPs may issue mail on behalf of your domain. Usually, you just want to allow your MXs (mx<\/em>). Maybe you’ll want to trust some additional record, … And deny everyone else (-all<\/em>). Final record could look like this:<\/p>\n

@ IN TXT “v=spf1 mx a:non-mx-sender.example.com -all”<\/p><\/blockquote>\n

Having defined your SPF policy, and assuming you properly configured DKIM signing, while corresponding\u00a0public key is published in your DNS, then you may consider defining some DMARC policy as well.<\/p>\n

@ IN TXT v=DMARC1; p=quarantine; pct=100; rua=mailto:postmaster@example.com<\/p><\/blockquote>\n

And ADSP:<\/p>\n

_adsp._domainkey IN TXT “dkim=all;”<\/p><\/blockquote>\n

… and that’s pretty much it. The rest’s up to you, and would probably be doable from BlueMind administration console.<\/p>\n","protected":false},"excerpt":{"rendered":"

Following up on a previous post introducing BlueMind, today we’ll focus on good practices (OpenDKIM, SPF, DMARC, ADSP, Spamassassin, firewalling) setting up their last available release (3.5.2) – and mail servers in general – while migrating my former setup (3.14). A first requirement to ease up creating mailboxes, and manipulating passwords during the migration process, […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[8,10,2],"tags":[],"_links":{"self":[{"href":"https:\/\/blog.unetresgrossebite.com\/index.php?rest_route=\/wp\/v2\/posts\/486"}],"collection":[{"href":"https:\/\/blog.unetresgrossebite.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.unetresgrossebite.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.unetresgrossebite.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.unetresgrossebite.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=486"}],"version-history":[{"count":21,"href":"https:\/\/blog.unetresgrossebite.com\/index.php?rest_route=\/wp\/v2\/posts\/486\/revisions"}],"predecessor-version":[{"id":507,"href":"https:\/\/blog.unetresgrossebite.com\/index.php?rest_route=\/wp\/v2\/posts\/486\/revisions\/507"}],"wp:attachment":[{"href":"https:\/\/blog.unetresgrossebite.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=486"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.unetresgrossebite.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=486"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.unetresgrossebite.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=486"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}