Arborescence

Ceci est une ancienne révision du document !

We currently run a very old qpsmtpd version (0.84 was released in 2010). A lot of improvements are available in newer release. Today, the last version is 0.96.

The goal is to update qpsmtpd to a newer release, then check if new plugins can be enabled to enhance security and spam filtering. All this is tracked on Bug #8861

The first step is to update the core qpsmtpd package to the latest version, adapt the spec file if needed, rebase needed patches.

This is currently being worked on, my latest build is available in fws-testing repo

Some plugins might have been merged in the core qpsmtpd package, and should be removed from qpsmtpd-plugins/smeserver-qpsmtpd in that case

The list of plugins provided by qpsmtpd-plugins is the following:

autowhitelist_relayrcpt
bcc
check_goodrcptto
denysoft_multi_rcpt
exe_filter
handler
per_user_config
whitelist_soft

None of them are provided by qpsmtpd. Two are probably a bit similar (per_user_config vs user_config and whitelist_soft vs dns_whitelist_soft), but as they do not clash, I see no reason to remove them. They are not used in the stock configuration anyway

The list of plugins bundled in smeserver-qpsmtpd is the following:

check_smtp_forward
disclaimer
dkim_sign
logging/logterse
peers
tnef2mime
virus/pattern_filter

None of those plugins are provided by qpsmtpd. But the functionnalities provided by dkim_sign are now merged in the dkim plugin. We can keep the dkim_sign plugin here, so those who have cponfigured it manually won't break their installation on upgrade, but we'll have to adjust the wiki documentation to use the new dkim plugin. See https://wiki.contribs.org/Email#DKIM_Setup

Plugins have been renamed, some might need new/different arguments. We need to adapt each of those in smeserver-qpsmtpd

This is the list of plugins we use, in order

logterse: no change
tls: no change
auth_cvm_unix_local: no change
check_earlytalker: renamed earlytalker
count_unrecognized_commands: no change
bcc: no change
check_relay: renamed relay
check_norelay: merged into the relay plugin
require_resolvable_fromhost: renamed resolvable_fromhost
check_basicheaders: renamed headers
rhsbl: no change
dnsbl: no change
check_badmailfrom: renamed badmailfrom
check_badrcptto_patterns: doesn't exist anymore, merged with badrcptto
check_badrcptto: renamed badrcptto
check_spamhelo: renamed helo
check_smtp_forward: no change
check_goodrcptto: no change
rcpt_ok: no change
pattern_filter: no change
tnef2mime: no change
spamassassin: no change
clamav: no change
qmail-queue: no change

The last step is to see if we can make use of new features/plugins to improve security and spam filtering on SME. Here's a potential list of improvements

Create a random dhparam on each install and use it in the tls plugin
Check if we can make use of the naughty plugin
The headers plugin (replacing check_basicheaders) can check for several missing headers (From,Date,Subject,Message-ID,Received), the default being only From (even Date is not enabled anymore by default as it blocks some legit emails).
The headers plugin now accepts different values for future and past dates (offset after/before which the email is considered invalid and is rejected). The previous only had a single value. This is controlled by the MaximumDateOffset prop (smtpd). We should allow different offsets (1 for future and 5 for past for example)
We might consider changing the clamav plugin (which uses clamdscan) to the clamdscan plugin. This should be a bit more efficient as we don't spawn the clamdscan binary, but directly talk to the clamd daemon
The new bogus_bounces plugin can be enabled
Check what can be done on a default setup with dkim and dmarc plugins
- We could enable dkim verification for inbound emails
- We could generate rsa keys for each domain declared from the server-manager
- Add a helper (or a panel in the server-manager) to get the TXT entry to add in the DNS
- See what we can do with dmarc for inbound
- See what we can do with dmarc for outbound
See if we could combine dspam with spamassassin, and if it can provide better spam detection
Test and see if the karma plugin is efficient
Test and enable the loadcheck plugin
Test and enable the uribl plugin
See how we could use per user settings. This is ambitious, but would allow to have per user bayes database. We could start by only using it for single recipient email. Multi recipients are harder to manage (we need to add a header during the SMTP transaction, the the LDA must detect iof the header is present, and re-submit the email to spamassassin to have it re-scanned with the per user setting)