Univention Bugzilla – Bug 53933
Valid (but exotic) emails are rejected when creating a user
Last modified: 2023-08-11 18:02:04 CEST
The following email is valid, but gets rejected when creating a user: " "@example.org see https://en.wikipedia.org/wiki/Email_address#Examples Also this one doesn't work: very.unusual."@".unusual.com@example.com see https://gist.github.com/cjaoude/fd9910626629b53c4d25 (here I am not 100% sure if it is really valid)
WORKS-4-ME in UDM (5.0-0) but not in the backend. According to [syntax.py#emailAddress](https://git.knut.univention.de/univention/ucs/-/blob/5.0-0/management/univention-directory-manager-modules/modules/univention/admin/syntax.py#L2080) our syntax is very lenient: - blanks are not allowed (bug) - must end on registered UDM "mail/domain" I tested the following with UCS 5.0-0: allowed: - "foo@bar@…" - "foo@bar.baz@…" disallowed: - "foo bar@…" But at least they don't seem to work as Postfix/Devecot rejects them with > Diagnostic-Code: smtp; 550 5.1.1 <"philipp@hahn"@qa50.pmh> User doesn't exist: Looks like Postfix does a lookup for the "quoted" local part while out LDAP stores it unquotet: > # univention-ldapsearch -LLLo ldif-wrap=no mailPrimaryAddress=philipp@hahn@qa50.pmh mailPrimaryAddress > dn: uid=phahn,cn=users,dc=qa50,dc=pmh > mailPrimaryAddress: philipp@hahn@qa50.pmh PS: U@S (or you or anybody) may setup a different syntax class for UDM "users/user" via UCR "directory/manager/web/modules/users/user/properties/mailPrimaryAddress/syntax" and "…/{mailAlternativeAddress,mailForwardAddress,e-mail}/syntax"
IMHO it is very good to reject that kind of email addresses. Even if OUR mail server combination could handle it, others won't. It would become a problem for the customer anyway. IMHO it should stay as it is.
(In reply to Daniel Tröder from comment #2) > IMHO it is very good to reject that kind of email addresses. > Even if OUR mail server combination could handle it, others won't. > It would become a problem for the customer anyway. > IMHO it should stay as it is. UDM already allows it, see: 2080 class emailAddress(simple): … 2095 » @classmethod 2096 » def parse(self, text): 2097 » » if not text.startswith('@') and \ 2098 » » » '@' in text and \ 2099 » » » not text.endswith('@') and \ 2100 » » » ' ' not in text: 2101 » » » return text 2102 » » raise univention.admin.uexceptions.valueError(_("Not a valid email address!")) You are probably creating a user via the UCS@school lib, which might be more restrictive.
(In reply to Daniel Tröder from comment #2) > IMHO it is very good to reject that kind of email addresses. > Even if OUR mail server combination could handle it, others won't. In comment #1 I only stated that UDM 5.0-0 already allows '@' in the local part, but our Postfix/Dovecot does not handle it correctly. This is inconsistent and should be fixed so that any address you use in the frontend is correctly handled in the backend. Either the backend must be fixed to handle quoted local parts - or the syntax class for the frontend must be restricted. It is okay to *temporarily* fix the syntax to match our *current* implementation, but the goal should be to allow what RFC 5322 allows. 1. Split syntax.py#emailAddress into two classes - one implementing RFC-5322 compatible addresses for every property, when an *external* address can be entered - implement an "UCS castrated" syntax for what UCS currently implements *internally* 2. Fix Postfix/Dovecot to handle all RFC-5322 compatible addresses 3. Allow the admin to configure the rules for UCS provisioned mail addresses. 4. Document it PS: There are valid reasons for 3. but by doing this your enforcing your rules on the world, which I find unacceptable: This may be your *local* decision to put further restrictions on the e-mail address your sever is providing, but never tell someone that their already exiting e-mail address from an other provider is not accepted because you refuse to implement the RFCs correctly! Personally I'm sick of "cloud services" telling me that my e-mail address is invalid because it contains a '+' or 'Umlaut' or whatever. The times of 6-bit ASCII are past - welcome to the 21th century where Unicode and IPv6 is the norm!
*** Bug 53947 has been marked as a duplicate of this bug. ***