Différences
Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente Prochaine révision Les deux révisions suivantes | ||
smedev:qpsmtpd_096 [15/04/2016 12:23] dani [Adapt smeserver-qpsmtpd] |
smedev:qpsmtpd_096 [17/06/2016 23:06] dani [Update qpsmtpd core package] |
||
---|---|---|---|
Ligne 9: | Ligne 9: | ||
The first step is to update the core qpsmtpd package to the latest version, adapt the spec file if needed, rebase needed patches. | 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 | ||
- | |||
- | * http:// | ||
- | * http:// | ||
===== Check qpsmtpd-plugins and smeserver-qpsmtpd for duplicated plugins ===== | ===== Check qpsmtpd-plugins and smeserver-qpsmtpd for duplicated plugins ===== | ||
Ligne 75: | Ligne 71: | ||
* tnef2mime: no change | * tnef2mime: no change | ||
* spamassassin: | * spamassassin: | ||
- | * clamav: no change | + | * clamav: no change |
* qmail-queue: | * qmail-queue: | ||
+ | |||
===== Improve our config ===== | ===== Improve our config ===== | ||
Ligne 82: | Ligne 79: | ||
* Create a random dhparam on each install and use it in the tls plugin | * 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, | ||
+ | * The headers plugin now accepts different values for future and past dates (offset after/ | ||
+ | * 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, | ||
+ | * 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, | ||
+ | |||
+ | ===== To add in the release notes ===== | ||
+ | |||
+ | * The badrcptto_patterns doesn' | ||
+ | * The karma plugin is now ready to be used | ||
+ | * The helo plugin can now check more than just the helo hostname | ||
+ | * DKIM, SPF and DMARC are used | ||
+ | * The loadcheck plugin can defer inbound emails when your server load is too high | ||
+ | * The uribl plugin is ready to be used | ||
+ | * RBLList, SBLList and the new UBLList must now be comma separated. Previous configuration will be migrated automatically. For RBLList, you can use a semicolon to separate the service address and a reject message. This is useful for lists which doesn' | ||
+ | |||
+ | ===== Documentation ===== | ||
+ | ==== Karma ==== | ||
+ | |||
+ | The karma plugin tracks sender history. For each inbound email, various plugins can raise, or lower the " | ||
+ | |||
+ | * Karma (enabled|disabled): | ||
+ | * KarmaNegative (integer): Default value is 2. It's the delta between good and bad connection to consider the host naughty enough to block it for 1 day. Eg, with a default value of two, a host can be considered naughty if it sent you 8 good emails and 10 bad ones | ||
+ | * KarmaStrikes (integer): Default value is 3. This is the threshold for a single email to be considered good or bad. Eg, with the default value of 3, an email needs at least 3 bad karmas (reaches -3) for the connection to be considered bad. On the other side, 3 good karmas are needed for the connection to be considered good. Between the two, the connection is considered neutral and won't be used in the history count | ||
+ | |||
+ | Example: | ||
+ | <code bash> | ||
+ | db configuration setprop qpsmtpd Karma enabled KarmaNegative 3 | ||
+ | signal-event email-update | ||
+ | </ | ||
+ | |||
+ | ==== URIBL ===== | ||
+ | |||
+ | The URIBL plugin works a bit like RHSBL, except that it checks domain names found in the body of the email. For each URI identified, the corresponding domain name can be submitted to a BL list (through DNS queries). Two settings are available: | ||
+ | |||
+ | * URIBL (enabled|disabled): | ||
+ | * UBLList: (Comma separated list addresses): Default value is **multi.surbl.org: | ||
+ | |||
+ | Example: | ||
+ | <code bash> | ||
+ | db configuration setprop qpsmtpd URIBL enabled UBLList multi.surbl.org, | ||
+ | signal-event email-update | ||
+ | </ | ||
+ | |||
+ | ==== Helo ==== | ||
+ | |||
+ | Previously, the helo plugin was just checking for some known bad helo hostnames used by spammers (aol.com and yahoo.com). Now, it can check much more than that. This plugin is always enabled and has a single setting: | ||
+ | |||
+ | * HeloPolicy: (lenient|rfc|strict). The default value is **rfc**. See https:// | ||
+ | |||
+ | Example: | ||
+ | |||
+ | <code bash> | ||
+ | db configuration setprop qpsmtpd HeloPolicy lenient | ||
+ | signal-event email-update | ||
+ | </ | ||
+ | |||
+ | ==== Inbound DKIM / SPF / DMARC ==== | ||
+ | |||
+ | DMARC is a policy on top of DKIM and SPF. By default, SPF and DKIM are now checked on every inbound emails, but no reject is attempted. The dmarc plugin can decide to reject the email (depending on the sender policy). dkim and spf plugins are always enabled. dmarc has two settings: | ||
+ | |||
+ | * DMARCReject (1|0): Default value is 1. If set to 1, the dmarc plugin can decide to reject an email (if the policy of the sender is to reject on alignment failure). You can disable it by setting this to 0 (or disabled, off, no) | ||
+ | * DMARCReporting (1|0): Default value is 1. If set to 1, enable reporting (which is the **r** in dma**r**c). Reporting is a very important part of the DMARC standard. When enabled, you'll record information about email you receive from domains which have published a DMARC policy in a local SQLite database (/ | ||
+ | * SPFRejectPolicy (0|1|2|3|4): | ||
+ | * 0: do not reject anything | ||
+ | * 1: reject when SPF says fail | ||
+ | * 2: reject when SPF says softfail | ||
+ | * 3: reject when SPF says neutral | ||
+ | * 4: reject when an error occurred (like a syntax error in SPF entry) or if no SPF entry is published | ||
+ | * Inbound DKIM checks are only used by DMARC. No reject solely based on DKIM is supported | ||
+ | |||
+ | Example: | ||
+ | <code bash> | ||
+ | db configuration setprop qpsmtpd DMARCReject 0 SPFRejectPolicy 2 | ||
+ | signal-event email-update | ||
+ | </ | ||
+ | ==== Outbound DKIM signing / SPF / DMARC policy ==== | ||
+ | |||
+ | Everything is now ready for you to sign your outbound emails, and publish your public key, as well as your SPF and DMARC policy. A default DKIM key is created in / | ||
+ | |||
+ | <code bash> | ||
+ | db configuration setprop qpsmtpd DKIMSigning enabled | ||
+ | signal-event email-update | ||
+ | </ | ||
+ | |||
+ | If you want to disable dkim signing for a domain, you can use: | ||
+ | <code bash> | ||
+ | db domains setprop domain.com DKIMSigning disabled | ||
+ | signal-event email-update | ||
+ | </ | ||
+ | |||
+ | The default behavior is to use the same key pair for all your domains. But you can create other key pairs for specific domain if you want. For example, if you want to use a specific key pair for the domain.net domain: | ||
+ | |||
+ | <code bash> | ||
+ | cd / | ||
+ | mkdir domain.net | ||
+ | cd domain.net | ||
+ | echo default > selector | ||
+ | openssl genrsa -out private 2048 | ||
+ | openssl rsa -in private -out public -pubout | ||
+ | chown qpsmtpd: | ||
+ | chmod 400 private | ||
+ | signal-event email-update | ||
+ | </ | ||
+ | |||
+ | Now, the emails using a domain.net sender address will be signed by this new key instead of the default one. | ||
+ | |||
+ | === Publishing your DNS entries === | ||
+ | |||
+ | Signing your outbound emails is just part of the process. You now need to publish some DNS entries so everyone can check if the email they receive matches your policy. This part is not to be done on your SME Server, but on your public DNS provider. A script helps you by creating some sample DNS entries already formatted for a bind-like zone file. To use it: | ||
+ | |||
+ | <code bash> | ||
+ | qpsmtpd-print-dns <domain name> | ||
+ | </ | ||
+ | If omitted, the primary domain name is assumed. | ||
+ | |||
+ | Example output: | ||
+ | < | ||
+ | Here are sample DNS entries you should add in your public DNS | ||
+ | The DKIM entry can be copied as is, but others will probably need to be adjusted | ||
+ | to your need. For example, you should either change the reporting email adress | ||
+ | for DMARC (or create the needed pseudonym) | ||
+ | |||
+ | |||
+ | default._domainkey IN TXT " | ||
+ | @ IN SPF " | ||
+ | @ IN TXT " | ||
+ | _dmarc IN TXT " | ||
+ | </ | ||
+ | |||
+ | All you have to do now is publish those records | ||
+ | |||
+ | ==== Load ==== | ||
+ | The loadcheck plugin can temporarily deny inbound emails if your server is overloaded. This plugin is always enabled and has a single setting: | ||
+ | |||
+ | * MaxLoad (int number): Default is 7. If your load is above this value, emails from the outside will be deferred. |