User Tools

Site Tools


Sidebar

No ai soldati italiani all'estero

Indice

Eventi

Energia

Rigacci.Org usa energia elettrica da fonti rinnovabili, grazie al gruppo di acquisto Merci Dolci.

Merci Dolci - Energia Rinnovabile

Software libero!

Petizione contro i brevetti software

Faunalia: Soluzioni GIS professionali

Debian

www.gnu.org www.kernel.org

doc:appunti:linux:sa:postfix_spamassassin_clamav_dovecot

Postfix, SpamAssassin, ClamAV and Dovecot

Tested on Debian 9 Stretch.

Postfix on Port 587/TCP (submission)

Uncomment in /etc/postfix/master.cf:

submission inet n       -       y       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=may
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_reject_unlisted_recipient=no
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject

The option smtpd_reject_unlisted_recipient=no causes Postfix to accept non-existant local recipients, thus generating an error message just after queuing it. The default (to be enforced for non-authenticated clients) is to reject non-existant local recipient just after RCPT TO command.

Address Rewrite, Alias, etc.

Addresses without a domain name (both recipient and sender), will be qualified with the value of myorigin configuration, which defaults to the content of /etc/mailname in Debian.

If you need to rewrite the sender of some mails (e.g. locally generated system messages generated by root), you can use the sender_canonical_maps option of Postfix and provide a file like this:

root    user@some_domain.org

Mail for unqualified local users can be diverted to a specific local user by the /etc/aliases file. E.g. many system users do not have an $HOME/Maildir/, so they cannot receive locally generated mail. You can redirect all the messages to a single user with something like (remember to run newaliases after changing the file):

postmaster:     root
www-data:       root
root:           niccolo

Dovecot Authentication

We want a single authentication mechanism for SMTP, POP3 and IMAP, and we want to let the user to authenticate using the Unix username or the full email address and the password. Dovecot authentication is suitable for the task; the default Debian configuration provides authentication against the system usernames via the PAM module. The configuration file is /etc/dovecot/conf.d/auth-system.conf.ext.

To let authentication using the email address, we provide a passwd-like file /etc/dovecot/userdb, we will leave gecos, shell and extra_fields blank. See PasswdFile wiki page for details:

user:password:uid:gid:(gecos):home:(shell):extra_fields

This file will be used for authentication against the password (i.e. as a Password Database), and it will be used for user's data lookup, like the home directory (i.e. as an User Database). So we need to configure two sections in /etc/dovecot/conf.d/auth-passwdfile.conf.ext

passdb {
  driver = passwd-file
  args = scheme=CRYPT /etc/dovecot/userdb
}

userdb {
  driver = passwd-file
  args = /etc/dovecot/userdb
}

The scheme=CRYPT means that libc's crypt() is used for password encryption, so the same password stored in /etc/shadow can be used.

To activate both system PAM and passwd-like authentication, we set into /etc/dovecot/conf.d/10-auth.conf (needed systemctl reload dovecot.service after the change):

!include auth-system.conf.ext
!include auth-passwdfile.conf.ext

Now we can test both authentication and user's lookup using the doveadm tool:

doveadm auth test username@domain.org
Password: 
passdb: username@domain.org auth succeeded
doveadm user username@domain.org
field   value
uid     1000
gid     1000
home    /home/username
mail    maildir:~/Maildir

The file /etc/dovecot/userdb should be built e.g. by a cron-job, joining Postfix virtual_alias_maps and /etc/shadow passwords. It is re-read at each lookup. We need also to protect it:

chmod 0640 /etc/dovecot/userdb
chown root:dovecot /etc/dovecot/userdb

If you need to generate the hash for a password, you can use the following command line:

openssl passwd -1

Postfix SASL over Dovecot Auth

See Postfix And Dovecot SASL.

First of all we need to activate the socket used by Posfix for authentication. In /etc/dovecot/conf.d/10-master.conf ensure that into the service auth section there is:

service auth {
  ...
  # Postfix smtp-auth
  unix_listener /var/spool/postfix/private/auth {
    mode = 0660
    user = postfix
    group = postfix
  }
  ...
}

To be compatible with more clients, enable both PLAIN and LOGIN methods. In /etc/dovecot/conf.d/10-auth.conf:

auth_mechanisms = plain login

Once reloaded the dovecot.service, you should see the /var/spool/postfix/private/auth socket, with the requested owner and permission.

For the Postfix part, you must declare in /etc/postfix/main.cf:

# Uses Dovecot Auth socket.
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth

After reloading the postfix.service, it should repsond to the EHLO command with:

telnet localhost 25
220 smtp.domain.org ESMTP Postfix (Debian/GNU)
EHLO test
...
250-STARTTLS
250-AUTH PLAIN LOGIN
...

WARNING: The AUTH capability is not announced over an unencrypted connection, if it is enabled only over TLS connections; see the smtpd_tls_auth_only Postfix option. Modern Postfix installations does not offer AUTH over smtp (port 25/tcp), but only over submission (port 587/tcp). Check if the option smtpd_sasl_auth_enable=yes is declared into main.cf or into the submission section of master.cf.

Dovecot IMAP and POP3

Install the Debian packages:

  • dovecot-imapd
  • dovecot-pop3d

Once installed, the basic services IMAP2 on port TCP/143 and POP3 on port TCP/110 are already working, eventually with the Dovecot Authentication on userdb as seen above.

Enable SSL, imaps and pop3s

See SSL Dovecot Configuration.

We need to enable SSL certificates for encryption, and enable IMAPS on port TCP/993 and POP3S on port TCP/995. We will use the same Let's Encrypt certificates obtained for the web server. So we set into /etc/dovecot/conf.d/10-ssl.conf:

ssl = yes
ssl_cert = </etc/letsencrypt/live/smtp.domain.org/fullchain.pem
ssl_key = </etc/letsencrypt/live/smtp.domain.org/privkey.pem

Dovecot will read the SSL files with root privileges, so no particular settings should be required.

Once restarted the dovecot.service, we will find the services listening on the well known ports, and we can check the SSL certificates.

SpamAssassin Filter

Install the Debian packages spamassassin and spamc. Configure the SpamAssassin filter in /etc/spamassassin/local.cf, we customized a couple of settings:

rewrite_header Subject *****SPAM*****
report_safe 0

We can test the spam daemon using the spamc client:

cat message.txt | spamc

The result should show the added headers X-Spam-Status, etc.

To enable the cron job to automatically update spamassassin's rules on a nightly basis, edit /etc/default/spamassassin and set:

CRON=1

To force a manual update you can run /etc/cron.daily/spamassassin, downloaded rules will be stored into /var/lib/spamassassin/3.004001/. If something goes wrong (e.g. rules with errors), the spamd daemon may stop to work, in this case you should remove the above directory and just run with default, not updated rules.

Sanitizer/ClamAV Filter

For virus scanning of email attachments we use the ClamAV antivirus software. We install the daemon, the client and the database periodic update utility:

  • clamav-daemon
  • clamdscan
  • clamav-freshclam

Periodic download (update) of viruses database is performed by the clamav-freshclam.service, you can check the /var/log/clamav/freshclam.log.

Beside the plain scan utility, we want a mail filter, which will scan every attachment, removing the infected ones. The sanitizer program will do that.

All the logic will be included into the /etc/sanitizer.cfg configuration file. A Dovecot Sieve filter will do the rest. Testing the Sanitizer/ClamAV filter is quite easy:

cat message.txt | /usr/bin/sanitizer /etc/sanitizer.cfg

Beware that the clamd daemon runs per default with the clamav user, if you want regular users to scan their files (e.g. their mail attachments) you have to use the --fdpass argument when invoking the clamdscan client, otherwise you will get the error message:

eicar-antivirus.com: lstat() failed: Permission denied. ERROR

The --fdpass option works only if clamdscan connects to clamd via the Unix socket.

Dovecot Local Delivery Agent

We apreciate local delivery agents which permits per-user filtering (enable/disable spam or virus filtering on a per-user basis). In the past we used procmail and maildrop, but dovecot-lda was our choiche because it provides all the following features:

  • Maildir support
  • Voluntary quota
  • Per-user filtering (spam, virus, …)
  • Sieve filtering (forward, vacation)

The executable /usr/lib/dovecot/dovecot-lda is provided by the package dovecot-core.

To use the $HOME/.Maildir/ as final recipient (instead of the /var/mail/ Unix mailbox) we have to configure /etc/dovecot/conf.d/10-mail.conf:

mail_location = maildir:~/Maildir

WARNING! It seems that $HOME/Maildir/ will be created if it does not exist, but subfolders will be not! To be safe: make all the required directories and subdirectories with maildirmake.dovecot, before enabling a new mailbox, eventually with system Sieve filters, etc.

To let Postfix use this delivery agent, we have to change /etc/postfix/main.cf:

mailbox_command = /usr/lib/dovecot/dovecot-lda -f "$SENDER" -a "$RECIPIENT"

Sieve filtering

Sieve is a programming language that can be used for email filtering, filters are usually stored into the mail server as user's files, the dovecot-lda searches that files into the user's $HOME. In that scenario it can act as the procmail or maildrop delivery agents (which uses respectively the .procmailrc and .mailfiter configuration files).

We will use Sieve for:

  • Filtering messages with Sanitizer/ClamAV.
  • Filtering messages with SpamAssassin.
  • Saving SPAM into the Spam folder (or removing it).
  • Creating Vacation auto-responder.

Enable Sieve Filtering in Dovecot LDA

To enable Sieve filtering in Dovecot local delivery agent we have to edit /etc/dovecot/conf.d/15-lda.conf:

protocol lda {
  mail_plugins = $mail_plugins sieve
}

Enable sieve_extprograms plugin

By default a Sieve filter cannot execute an external program or filter, we have to enable the sieve_extprograms plugin, which is however installed by the dovecot-sieve Debian package.

To enable the plugin, just edit /etc/dovecot/conf.d/90-sieve.conf and set into the existing plugin section:

plugin {
  ...
  sieve_extensions = +vnd.dovecot.filter
  ...
  sieve_plugins = sieve_extprograms
  ...
}

and configure the plugin itself, editing the /etc/dovecot/conf.d/90-sieve-extprograms.conf file at the plugin section:

plugin {
  ...
  sieve_filter_socket_dir = sieve-filter
  ...
  sieve_filter_bin_dir = /usr/local/lib/dovecot/sieve-filter
  ...
}

NOTICE: we enabled only the filter capability of the sieve_extprograms plugin, there are also the pipe and execute capabilities.

The actual filters are scripts saved into /usr/local/lib/dovecot/sieve-filter/ directory. We make just two examples: one using Sanitizer/ClamAV and one using SpamAssassin (named clamav-filter.sh and spamc-filter.sh respectively):

/bin/sh
/usr/bin/sanitizer /etc/sanitizer.cfg
#!/bin/sh
/usr/bin/spamc

How to Test an User's Sieve Filter File

The dovecot-lde searches the user's active filter into $HOME/.dovecot.sieve (configured in /etc/dovecot/conf.d/90-sieve.conf). We can write a simple filter file:

require ["fileinto"];
if header :contains "subject" ["order", "buy"] {
    fileinto "Commercial";
}

When a message is received and handled by the dovecot-lda, it can leave some useful log in /var/log/mail.log:

Jan 19 09:51:58 dovecot: lda(username): sieve: Execution of script /home/username/.dovecot.sieve
    failed, but implicit keep was successful (user logfile /home/username/.dovecot.sieve.log may
    reveal additional details)

As reported in log, an error message is recorded into users' $HOME/.dovecot.sieve.log. In our case the subfolder named Commercial was missing, we have to create it using maildirmake.dovecot ~/Maildir/.Commercial (notice the leading dot in subfolder name, which does not appear in Sieve filter statements).

A more complete Sieve filter example is the following. Each message is filtered for viruses and spam, then the messages marked as spam are saved into a specific folder:

require ["fileinto", "vnd.dovecot.filter"];

# Filter with /usr/local/lib/dovecot/sieve-filter/spamc-filter.sh.
filter "spamc-filter.sh";

# Filter with /usr/local/lib/dovecot/sieve-filter/clamav-filter.sh.
filter "clamav-filter.sh";

if header :contains "X-Spam-Flag" "YES" {
    fileinto "Spam";
}

Every Sieve script will be compiled by Dovecot at the first execution; you will find a file .svbin for each .sieve file. Beware that global Sieve files are usually stored in non-user-writable directories, to the sysadmin must compile them with sievec.

Multiple Sieve Scripts

In the simplest case there is only one Sieve script per each user, which is $HOME/.dovecot.sieve. The user can create several scripts into $HOME/sieve/ directory, and choose which one to activate by making the proper symlink. The managing of these scripts can be done using the Managesieve daemon on the server and a Managesieve client (available e.g. as a Roundcube plugin).

In some cases it is desiderable to have several Sieve scripts and apply them in sequence, beside the one activated by the user and Managesieve. The most flexible way is to use a sieve_before and/or a sieve_after directory.

Scripts sieve_before and sieve_after

In /etc/dovecot/conf.d/90-sieve.conf we can configure some files or directories to contain Sieve scripts (with the proper .sieve extension), to be executed before or after the user's personal script. If the path starts with ~/ it is relative to the user's home directory (scripts are executed in alphabetical order):

plugin {
    ...
    sieve_before = ~/sieve_before.d/
    sieve_before2 = /var/lib/dovecot/sieve.d/
    #sieve_after =
    ...
}

The Include plugin

Another useful mechanism is to provide some system or user Sieve scripts, and let the users to use them via the include directive. The location for user's scripts is $HOME/sieve by default, for global scripts you have to define sieve_global, e.g.:

plugin {
    sieve = file:~/sieve;active=~/.dovecot.sieve
    ...
    sieve_global = /etc/dovecot/sieve
    ...
}

once defined the location, the user can create a Sieve script like this:

require ["include"];
include :personal "my_script";
include :global "spam_tests";

The files (with the .sieve extension) will be searched into the proper directory.

Roundcube with MySQL

If you missed the database configuration during Roundcube installation, you can re-do it with:

dpkg-reconfigure roundcube-core
  • IMAP server: 127.0.0.1
  • Default language: it_IT
  • Reinstall database for roundcube: Yes
  • Connection method for MySQL database of roundcube: Unix socket
  • MySQL database name for roundcube: roundcube
  • MySQL username for roundcube: roundcube@localhost
  • MySQL application password for roundcube: <blank>
  • Name of the database's administrative user: root
  • Web server(s) to configure automatically: apache2

Roundcube with PostgreSQL

  • IMAP server: 127.0.0.1
  • Default language: it_IT
  • Reinstall database for roundcube: Yes
  • Database type to be used by roundcube: pgsql
  • Connection method for PostgreSQL database of roundcube: Unix socket
  • Method for authenticating the PostgreSQL administrator: ident
  • Method for authenticating PostgreSQL user: password
  • PostgreSQL database name for roundcube: roundcube
  • PostgreSQL username for roundcube: roundcube
  • PostgreSQL application password for roundcube: <blank>
  • Name of the database's administrative user: postgres
  • Web server(s) to configure automatically: apache2

Roundcube: Virtual Users, etc.

/etc/roundcube/config.inc.php

// The default locale setting (leave empty for auto-detection)
$config['language'] = 'it_IT';

Whenever an user login into Roundcube, the webmail attempts an IMAP authentication using the same credentials. If it succeeds, it will create a new record into the users table, filling the username field with the used login name. If the IMAP server accepts both the Unix login name and the full email address as login, you can find yourself having two different Roundcube users for the same IMAP mailbox.

In this scenario is preferable to disable in Roundcube the automatic creation of users and enable the use of email from user's identities as login.

// Set to false if only registered users can use this service
$config['auto_create_user'] = false;
// Enables possibility to log in using email address from user identities
$config['user_aliases'] = true;

The only drawback is that you have to populate the users and identities database tables before the user can login into Roundcube:

INSERT INTO users (username, mail_host, language)
    VALUES ('niccolo', '127.0.0.1', 'it_IT');
SELECT user_id FROM users WHERE username = 'niccolo';
INSERT INTO identities (user_id, standard, name, email)
    VALUES (1234, 1, 'Niccolo Rigacci', 'niccolo@domain.org');

ManageSieve Daemon

Install the dovecot-managesieved Debian package, verify that the daemon is responding on port 4190/TCP. The protocol is enabled by the included snippet /usr/share/dovecot/protocols.d/managesieved.protocol.

Test the ManageSieve Daemon

See ManageSieve Troubleshooting. It is possible to test a ManageSieve daemon talking the proper language over an interactive TCP/IP session. The language is specified by RFC5804.

To authenticate ourself to the server, we'll need a base64 encoded string containing \000login\000password:

echo -en "\000niccolo@mail.domain.org\000MySecret" | base64
AG5pY2NvbG9AbWFpbC5kb21haW4ub3JnAE15U2VjcmV0
telnet localhost 4190

In this session we will authenticate, check if there is space to store a script, create a script and activate it:

CAPABILITY
AUTHENTICATE "PLAIN" "AG5pY2NvbG9AbWFpbC5kb21haW4ub3JnAE15U2VjcmV0"

HAVESPACE "myscript" 200
PUTSCRIPT "myscript" {109+}
require ["copy"];
if header :contains "Subject" "newsletter"
{
    redirect :copy "other@domain.org";
}

LISTSCRIPTS
SETACTIVE "myscript"

LOGOUT

To calculate the size of the script (109 bytes in our case), use cr+lf as newline separator.

Connect Roundcube to the ManageSieve Daemon

Install the Debian package roundcube-plugins, which cointains the managesieve plugin. Edit the /etc/roundcube/plugins/managesieve/config.inc.php file, and set:

$config=array();
$config['managesieve_port'] = 4190;
$config['managesieve_host'] = 'localhost';
$config['managesieve_default'] = '/etc/dovecot/sieve/global';

Enable the plugin adding it to the array in /etc/roundcube/config.inc.php:

$config['plugins'] = array(
    'managesieve'
);

After configuring the two files, login into the Roundcube web interface, click on Settings, you should have a new tab labeled Filters on the left (after Preferences, Folders, etc.)

Roundcube, ManageSieve, sieve_extprograms and Include

It seems that Roundcube with ManageSieve plugin, cannot handle scripts which use the sieve_extprograms plugin or the include directive. The filters are not properly shown into the web interface, and they gets corrupted when the plugin edit/rewrite the script.

Vacation with Roundcube and Sieve/ManageSieve

A Vacation (or out-of-office) automatic responder can ben activated using a Sieve filter. The Roundcube webmail has a plugin which enables a web interface to activate and configure the vacation auto-responder. The Roundcube plugin uses the ManageSieve client/server method to create and activate the Sieve script.

To expose the specific vacation web interface, put into /etc/roundcube/plugins/managesieve/config.inc.php:

$config['managesieve_vacation'] = 1;

With this config, pointing the web interface to the Settings page, you should have a new tab labeled Vacation on the left (after the Filters one). The vacation rules can be managed with the generic Filters tab too, so there is the option to show only the Filter tab (value 0), both the Filter and the Vacation tabs (value 1), or only the Vacation tab (value 2).

This is a Sieve file generated by the Roundcube managesieve/vacation plugin:

require ["date","relational","vacation"];
# rule:[Vacation]
if allof (currentdate :zone "+0100" :value "ge" "iso8601" "2018-01-17T17:00:00+01:00", 
          currentdate :zone "+0100" :value "le" "iso8601" "2018-02-08T09:00:00+01:00")
{
    vacation :subject "Out of Office" "I'm on vacation until February 8th. Be patient.";
}

Information about what addresses were already responded and when, are stored into $HOME/.dovecot.lda-dupes.

The managesieve Roundcube plugin is configured by /etc/roundcube/plugins/managesieve/config.inc.php. Many options are explained into the provided /usr/share/roundcube/plugins/managesieve/config.inc.php.dist file.

Vacation and Virtual Domains

You can use the virtual_alias_maps to handle several virtual domains, e.g. you receive mails for @domain1.org, @domain2.org, etc. while myhostname is mail.domain.org.

This is a problem for Dovecot Vacation, because every local delivery is translated from virtual domain to myhostname, as you can see into Postfix logfile:

postfix/local: ... to=<niccolo@mail.domain.org>, orig_to=<niccolo.rigacci@domain1.org>, ...

in that scenario the filter does not send the automatic reply, because it is implicitly delivered:

discarding vacation response for implicitly delivered message; no known (envelope)
recipient address found in message headers (recipient=<niccolo@mail.domain.org>,
and no additional `:addresses' are specified)

The trick is to enumerate the addresses for which the vacation should respond. In the Roundcube Vacation web interface, Advanced settings, you have the My email addresses field, where you have to add your virtual addresses.

Roundcube can fill automatically that field, using the email address found into the Identities settings, just add the following in /etc/roundcube/plugins/managesieve/config.inc.php:

$config['managesieve_vacation_addresses_init'] = true;

Obviously Roundcube is not aware of aliases and/or virtual addresses configured in Postfix, so you have to add them manually, if any.

DAViCal

We used version 1.1.7 from Debian Stretch Backports, which requires libawl-php 0.59-1 from the same backports. For installation instructions, follow /usr/share/doc/davical/README.Debian.

Add the following to /etc/postgresql/9.6/main/pg_hba.conf (then reload the postgresql service):

local   davical   davical_app   trust
local   davical   davical_dba   trust

As the postgres user, run /usr/share/davical/dba/create-database.sh. Take note of the admin generated password.

Customize /etc/apache2/sites-available/davical.conf. E.g. we used the alias /dav/ instead of /davical/, we forced SSL, etc.

Customize /etc/davical/config.php, we changed:

$c->system_name = "CalDAV Server";
$c->admin_email ='postmaster@domain.org';

Enable the site, the required module, and restart Apache:

a2ensite davical
a2enmod rewrite
systemctl restart apache2

Point the browser to https://host.domain.org/dav/setup.php and login as admin with the above generated password.

Securing the PostgreSQL Access

Once installed, we can make a more secure database connection, setting a password. Change the pg_hba.conf file with:

local   davical    davical_app   md5
local   davical    davical_dba   md5

As the postgres user, connect to the database and issue:

ALTER USER davical_app PASSWORD 'PwdSecret';
ALTER USER davical_dba PASSWORD 'PwdSecret';

In /etc/davical/config.php add the password into the connection string:

$c->pg_connect[] = 'dbname=davical port=5432 user=davical_app password=PwdSecret';

Finally protect the configuration file:

chgrp www-data /etc/davical/config.php
chmod 640 /etc/davical/config.php

Apache RewriteRule

The default base URL for DAViCal resources is http://host.domain.org/davical/caldav.php/, but using alias and rewrite rules you can use more pretty (and well-known) URLs.

Beware that RewriteRule directives must be in VirtualHost section of Apache configuration, so it is likely that you have to replicate the examples found in /etc/apache2/sites-available/davical.conf into your /etc/apache2/sites-available/default-ssl.conf or alike.

Here we used a more generic dav alias instead of davical, and activated the suggested well-known URLs:

# Rewrite rules for DAViCal, must be in VirtualHost section.
RewriteEngine On
#LogLevel info rewrite:trace2
RewriteRule ^/\.well-known/(.*)$ /dav/caldav.php/.well-known/$1 [NC,PT]
RewriteRule ^/principals/users/(.*)$ /dav/caldav.php/$1 [NC,PT]
RewriteRule ^/principals/resources/(.*)$ /dav/caldav.php/$1 [NC,PT]
RewriteRule ^/calendars/__uids__/(.*)$ /dav/caldav.php/$1 [NC,PT]
RewriteRule ^/addressbooks/__uids__/(.*)$ /dav/caldav.php/$1 [NC,PT]

Create an User with a Calendar and an Addressbook

To create a new user, login to the web interface as admin, click on User FunctionsCreate Principal. As Princial Type choose Person. For each person created, DAViCal will create also a calendar and an addressbook, with the following URLs:

  • https://host.domain.org/dav/caldav.php/<username>/calendar
  • https://host.domain.org/dav/caldav.php/<username>/addresses

With the proper Rewrite rules (Apache configuration) you can use also well known URLs, like:

  • http://host.domain.org/principals/users/<username>/calendar
  • http://host.domain.org/principals/users/<username>/addresses

It depends upon the client to be able to discover the proper resource (e.g. the addressbook) when given just the user's URL. May be you have to experiment to discover the capabilities of your client.

  • With Thunderbird 52.5 and the CardBook 26.0 extension, we tested with success the URL
    http://host.domain.org/principals/users/<username>/addresses
  • With Thunderbird and the Lightning 52.5.2 calendar extension, we tested with success the URL
    http://host.domain.org/principals/users/<username>/calendar

There is no automatic way to authenticate in DAViCal using the Dovecot Auth: you must create the user into the DAViCal database. If you prefer, you can use the email address as the login name. When creating the Person you are asked for an email address, which should be unique among the persons, otherwise the scheduling my not work.

Into the davical database, you can browse the table collection to see addressbooks and calendars, browse the table addressbook_resource to see the names, etc.

Quota

See Dovecot Quota. Enable overall quota plugin in /etc/dovecot/conf.d/10-mail.conf:

mail_plugins = $mail_plugins quota

Dovecot Quota Backend

Dovecot quota plugin can relay on several backends: dirsize means calculate the actual disk space used every time (very slow!!), maildir means voluntary quota via maildirsize file, etc. We will instead use fs, the quota enforced by the Linux filesystem. In /etc/dovecot/conf.d/90-quota.conf set:

plugin {
  quota = fs:User quota
}

The Dovecot plugin will return mailbox full when user will reach the filesystem quota soft limit. You may want to set the hard limit a bit above the soft one, so that the system can still write mailbox indexes, Spamassassin stats, etc.

Dovecot Quota service for Postfix

We enable a service that will be checked by Postfix when accepting mail via SMTP. Into /etc/dovecot/conf.d/90-quota.conf add the following:

service quota-status {
  executable = quota-status -p postfix
  inet_listener {
    port = 12340
  }
  client_limit = 1
}

In the same configuration file, set also the responses returned by the service. Notice that if you set a grace quota space of 10%, you must set the filesystem soft quota limit 10% smaller than the hard one; or even more, to be safe:

plugin {
  quota_grace = 10%%
  quota_status_success = DUNNO
  quota_status_nouser = DUNNO
  quota_status_overquota = "554 5.2.2 Quota exceeded (mailbox for user is full)"
}

After reloading dovecot.service, you will have a daemon listening on port 12340/TCP. To check if the service is working, you can telnet to the TCP port and paste some strings of text, the relevant lines are recipient and size in bytes (see more on smtpd-policy language in this example):

request=smtpd_access_policy
protocol_state=RCPT
protocol_name=SMTP
sender=foo@bar.tld
recipient=user@domain.org
client_address=1.2.3.4
client_name=another.domain.tld
size=123000

action=554 5.2.2 Quota exceeded (mailbox for user is full)

In Postfix configuration /etc/postfix/main.cf add a restriction on smtpd (the order of restrictions matter):

smtpd_recipient_restrictions =
    ...
    check_policy_service inet:127.0.0.1:12340,
    ...

If you use the same Postfix instance for submission and smtp services, it may will perform an useless call to quota-status for emails to be relayed. The check should return the DUNNO status in case of quota_status_nouser, i.e. proceed with the next restriction rule check.

Quota and dovecot-lda

dovecot-lda, on local deliveries, will chek user quota too. Debian default is to include global mail_plugins, so no need to add quota into /etc/dovecot/conf.d/15-lda.conf:

protocol lda {
  mail_plugins = $mail_plugins
}

So also locally generated mails (i.e. not received via SMTP) will be checked against filesystem quota, and eventually bounced with a MAILER-DAEMON error email message.

Dovecot Quota for IMAP

To enable quota support into the IMAP server, add to /etc/dovecot/conf.d/20-imap.conf:

protocol imap {
  mail_plugins = $mail_plugins imap_quota
}

Verify that QUOTA is displayed among CAPABILITY(ies), using telnet to port 143/TCP:

telnet localhost 143
a1 LOGIN username SuperSecret
a1 OK [CAPABILITY IMAP4rev1 ... QUOTA] Logged in
a2 LOGOUT

Checking SSL Certificates

We should periodically check every SSL-enabled service for the certificate validity. The monitoring-plugins-basic Debian package contains some useful scripts that can be used. Here are an example script:

#!/bin/sh
echo "Checking SSL certificate fot SMTP on port 25/TCP..."
/usr/lib/nagios/plugins/check_smtp -H localhost --port=25 --starttls -D 28
echo
echo "Checking SSL certificate fot POP3D on port 995/TCP..."
/usr/lib/nagios/plugins/check_pop -H localhost --ssl --port=995 -D 28
echo
echo "Checking SSL certificate fot IMAP on port 993/TCP..."
/usr/lib/nagios/plugins/check_imap -H localhost --ssl --port=993 -D 28
doc/appunti/linux/sa/postfix_spamassassin_clamav_dovecot.txt · Last modified: 2019/04/05 10:09 by niccolo