1754: centralize Webmail authentication behind the admin panel (SSO) r=mergify[bot] a=nextgens
## What type of PR?
Enhancement: it centralizes the authentication of webmails to the admin interface.
## What does this PR do?
It implements the glue required for webmails to do SSO using the admin interface.
One of the main advantages of centralizing things this way is that it reduces significantly the attack surface available to an unauthenticated attacker (no webmail access until there is a valid Flask session).
Others include the ability to implement 2FA down the line and rate-limit things as required.
### Related issue(s)
- #783
## Prerequistes
Before we can consider review and merge, please make sure the following list is done and checked.
If an entry in not applicable, you can check it or remove it from the list.
- [x] In case of feature or enhancement: documentation updated accordingly
- [x] Unless it's docs or a minor change: add [changelog](https://mailu.io/master/contributors/guide.html#changelog) entry file.
Co-authored-by: Florent Daigniere <nextgens@freenetproject.org>
- remove PASSWORD_SCHEME altogether
- introduce CREDENTIAL_ROUNDS
- migrate all old hashes to the current format
- auto-detect/enable all hash types that passlib supports
- upgrade passlib to 1.7.4 (see #1706: ldap_salted_sha512 support)
- yaml-import is now logged via schema.Logger
- iremoved relative imports - not used in other mailu modules
- removed develepment comments
- added Mailconfig.check method to check for duplicate domain names
- converted .format() to .format_map() where possible
- switched to yaml multiline dump for dkim_key
- converted dkim_key import from regex to string functions
- automatically unhide/unexclude explicitly specified attributes on dump
- use field order when loading to stabilize import
- fail when using 'hash_password' without 'password'
- fixed logging of dkim_key
- fixed pruning and deleting of lists
- modified error messages
- added debug flag and two verbosity levels
- idna.encode does not encode upper-case letters,
so .lower() has to be called on value not on result
- split email-address on '@' only once
- converted '*'.format(*) to f-strings
- added docstrings
- removed from_dict method
- code cleanup/style (list concat, exceptions, return&else, line-length)
- added TODO comments on possible future changes
renamed single letter variables (m => match)
renamed classmethod arguments to cls (model)
removed shadowing of variables (hash, context)
shortened unneeded lambda functions (id)
converted type ... is to isinstance(...)
removed unneded imports (flask)
- stabilized CommaSeparatedList by sorting values
- CommaSeparatedList can now handle list and set input
- from_dict now handles mapped keys
- from_dict now handles null values
- class Domain: handle dkim-key None correctly
- class User: delete obsolete keys after converting
- class Alias: now uses Email._dict_input
Since direct addresses (not aliases) are case-insensitive since a while,
it makes sense for aliases to behave the same. Up until now, a wildcard
alias could trump a alias not-matching-the-case of the incoming address.
This clarifies this behavior.
closes#1387
Currently when the mail address is looked up by Postfix (using the admin
part) the address extension is removed. This is due to the address
extension being removed to look up the user, and afterwards returning
the users mail address. But by not returning the mail address including
the address extension it also isn't part anymore in the LMTP
communication to Dovecot. So Dovecot doesn't know about the extension,
and in turn the address extension can't be used in Sieve mail filtering.
This change fixes that by returning the original address by just
concatinating the "localpart" and domain again when the user is found.
Fixes#982
Even though RFC5321 2.4 explains that local-parts are to be case-sensitive,
this does not seem to be how EMail is used today. Thus, instead of reverting
user-emails back to being case sensitive, let’s make aliases case-insensitive
too. Not only more consistent, this also allows users to enjoy receiving EMails
from large airlines or car-rental agencies onto their already existing aliases.
For the rare case of case sensitive aliases existing, let’s query for the
forced-lowercase alias only in the event that the preserved-case one isn’t
found …
closes#867
At some places, the string that DOMAIN_REGISTRATION is got used like a boolean
(an easy misassumption to make while in python and dealing with the config
dict), making `DOMAIN_REGISTRATION=False` act as a truthy value. To stop such
future problems from happening, coerce environment config strings to real
bools.
closes#830
Since it’s common for wildcard~ish systems to prefer concrete objects over
wildcards, and aliases can be broad-wildcards (think catchall, %@xxx.tld), it
may be more intuitive for users that user-names rank higher than aliases. This
makes it impossible for user-names to be unreachable, since they can be
completely overridden by a catchall otherwise.
This changes default behavior, and is not configurable.
closes#815
As discussed with hoellen on matrix, since postfix indeed supports including
the recipient delimiter character in a verbatim alias, we should support so too
— and handle its precedence correctly. The clearer and simpler formulation of
the precedence-clauses are credit to @hoellen. Thanks!
This fixes delivery to an alias minus recipient delimiter in cases where a
wildcard alias would also match. For example,
* foo@xxx.tld
* %@xxx.tld
Sending to foo+spam@xxx.tld would get eaten by the catchall before this fix.
Now, the order of alias resolution is made clearer.
closes#813
Since postfix now asks us for the complete email over podop, which
includes the recipient-delimiter-and-what-follows not stripped, we need
to attempt to find both the verbatim localpart, as well as the localpart
stripped of the delimited part ….
Fixes#755
Supporting multiple backends requires that specific sqlite
collations are not used, thus lowercase is applied to all non
case-sensitive columns. However, lowercasing the database requires
temporary disabling foreign key constraints, which is not possible
on SQLite and requires we specify the constraint names.
This migration specific to sqlite and postgresql drops every
constraint, whether it is named or not, and recreates all of them
with known names so we can later disable them.