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.
