[Dovecot] configure lmtp to deliver to email addresses case insensitively
Dear List
Using dovecot 2.1.7 with LMTP and exim4 I want to accept local parts regardless of their case.
Exim does all virtual alias handling and delivers the messages to dovecot LMTP addressed to the right mailbox name. This works well except for addresses which do not need to be resolved by exim and which do have the "wrong" case in the local part.
For example: There is a mailbox and a user on the mailsystem "example.org" called "user". Mails to "user@example.org" get delivered just as they should. If an incoming message is addressed to "USER@example.org" with upper case local part, exim passes the message to LMTP with the case unaltered (RFC 2821 conform), but LMTP fails with: LMTP error after RCPT TO:USER@example.org: 550 5.1.1 USER@example.org User doesn't exist: USER@example.org
How can I tell dovecot to deliver "USER" to the mailbox "user" aswell?
Thank you for your help.
Best regards, Adrian.
(I have tried to use %Ln and %Lu in mail_location setting with no success.)
On 2013-12-16 2:36 PM, Adrian Zaugg adi@ente.limmat.ch wrote:
How can I tell dovecot to deliver "USER" to the mailbox "user" aswell?
"Username
LDAP lookups are case-insensitive. Unless you somehow normalize the username, it's possible that a user logging in as "user", "User" and "uSer" are treated differently. The easiest way to handle this is to tell Dovecot to change the username to the same case as it's in the LDAP database. You can do this by returning "user" field in the pass_attrs, as shown in the above example.
If you can't normalize the username in LDAP, you can alternatively lowercase the username in dovecot.conf:
auth_username_format = %Lu"
See: http://wiki2.dovecot.org/AuthDatabase/LDAP/PasswordLookups
This really should be the default...
--
Best regards,
*/Charles/*
Hi Marcus
The change of adding an L to
auth_username_format = %Ln"indeed has the side effect, that LMTP delivers wrongly cased addresses. But the main effect and disadvantage is, that authenticating logins with wrongly cased usernames do also succeed, which I actually do not like to happen.
Isn't there another solution? A feature request for a new option lmtp_username_format?
Regards, Adrian.
Am 16.12.13 21:25 schrieb Charles Marcus:
On 2013-12-16 2:36 PM, Adrian Zaugg adi@ente.limmat.ch wrote:
How can I tell dovecot to deliver "USER" to the mailbox "user" aswell?
"Username
LDAP lookups are case-insensitive. Unless you somehow normalize the username, it's possible that a user logging in as "user", "User" and "uSer" are treated differently. The easiest way to handle this is to tell Dovecot to change the username to the same case as it's in the LDAP database. You can do this by returning "user" field in the pass_attrs, as shown in the above example.
If you can't normalize the username in LDAP, you can alternatively lowercase the username in dovecot.conf:
auth_username_format = %Lu"
See: http://wiki2.dovecot.org/AuthDatabase/LDAP/PasswordLookups
This really should be the default...
On 2013-12-16 4:32 PM, Adrian Zaugg adi@ente.limmat.ch wrote:
The change of adding an L to
auth_username_format = %Ln"
indeed has the side effect, that LMTP delivers wrongly cased addresses. But the main effect and disadvantage is, that authenticating logins with wrongly cased usernames do also succeed, which I actually do not like to happen.
Trying very hard to understand why this would be a problem.
Isn't there another solution? A feature request for a new option lmtp_username_format?
No idea, as I see no value in differentiating...
--
Best regards,
*/Charles/*
Am 16.12.13 22:55 schrieb Charles Marcus:
On 2013-12-16 4:32 PM, Adrian Zaugg adi@ente.limmat.ch wrote:
But the main effect and disadvantage is, that authenticating logins with wrongly cased usernames do also succeed, which I actually do not like to happen.
Trying very hard to understand why this would be a problem. On *nix hosts login names are always case sensitive. Why should this change with the same login name for eMails when it doesn't for for ssh, FTP, Webserver-Login, Database-Login ... ? It's nicer if a system acts consistent.
Regards, Adrian.
Am 16.12.2013 15:25 schrieb Charles Marcus:
auth_username_format = %Lu" This really should be the default...
I disagree. That solve a symptom, not the problem.
As of rfc3522 a localpart *may* be used case sensitive or not. I suggest a switch "my_local_parts_are_casesensitive = yes/no" or "my_local_parts_are_caseINsensitive = no/yes" The name and default must be well selected and not break existing behaviour.
I think that's more transparent then changing an mostly unvisible setting.
Andreas
-- Andreas Schulze Internetdienste | P252
DATEV eG 90329 Nürnberg | Telefon +49 911 319-0 | Telefax +49 911 319-3196 E-Mail info @datev.de | Internet www.datev.de Sitz: 90429 Nürnberg, Paumgartnerstr. 6-14 | Registergericht Nürnberg, GenReg Nr.70 Vorstand Prof. Dieter Kempf (Vorsitzender) Dipl.-Kfm. Wolfgang Stegmann (stellvertretender Vorsitzender) Dipl.-Kfm. Michael Leistenschneider Dipl.-Kfm. Dr. Robert Mayr Jörg Rabe v. Pappenheim Dipl.-Vw. Eckhard Schwarzer Vorsitzender des Aufsichtsrates: Reinhard Verholen
On 2013-12-17 2:39 AM, Andreas Schulze andreas.schulze@datev.de wrote:
Am 16.12.2013 15:25 schrieb Charles Marcus:
auth_username_format = %Lu" This really should be the default... I disagree. That solve a symptom, not the problem.
As of rfc3522 a localpart*may* be used case sensitive or not. I suggest a switch "my_local_parts_are_casesensitive = yes/no" or "my_local_parts_are_caseINsensitive = no/yes" The name and default must be well selected and not break existing behaviour.
I think that's more transparent then changing an mostly unvisible setting.
Your system, your rules, however...
Just because you *can* do something doesn't mean you *should* do it - and just because something is RFC compliant doesn't mean you should always implement it that way.
There are very few compelling arguments for supporting identical usernames differing only by case. One is some kind of legacy (unix) environment where you already have a lot of these... but I can't readily think of another (good one)...
--
Best regards,
*/Charles/*
Am 17.12.2013 16:55, schrieb Charles Marcus:
On 2013-12-17 2:39 AM, Andreas Schulze andreas.schulze@datev.de wrote:
Am 16.12.2013 15:25 schrieb Charles Marcus:
auth_username_format = %Lu" This really should be the default... I disagree. That solve a symptom, not the problem.
As of rfc3522 a localpart*may* be used case sensitive or not. I suggest a switch "my_local_parts_are_casesensitive = yes/no" or "my_local_parts_are_caseINsensitive = no/yes" The name and default must be well selected and not break existing behaviour.
I think that's more transparent then changing an mostly unvisible setting.
Your system, your rules, however...
Just because you *can* do something doesn't mean you *should* do it - and just because something is RFC compliant doesn't mean you should always implement it that way.
There are very few compelling arguments for supporting identical usernames differing only by case. One is some kind of legacy (unix) environment where you already have a lot of these... but I can't readily think of another (good one)...
in fact it does always harm because users
there are enough writing their address uppercase while the server was never configured that way, there are enough writing FirstnameLastname@domain.tld and you can hardly find a normal person who accepts that writing a message to "YOU@domain.tld" goes to a different person than "you@domain.tld" or bounce in one of the cases
On 2013-12-17 11:02 AM, Reindl Harald h.reindl@thelounge.net wrote:
there are enough writingFirstnameLastname@domain.tld and you can hardly find a normal person who accepts that writing a message to"YOU@domain.tld" goes to a different person than"you@domain.tld" or bounce in one of the cases
I agree, but as I said - his system/server, his rules...
On 12/17/2013 8:02 AM, Reindl Harald wrote:
there are enough writing their address uppercase while the server was never configured that way, there are enough writing FirstnameLastname@domain.tld and you can hardly find a normal person who accepts that writing a message to "YOU@domain.tld" goes to a different person than "you@domain.tld" or bounce in one of the cases
There are also listservs and other things out there which case fold email addresses--some fold to lowercase, some to uppercase. Current best practice is treat the entire email address as case insensitive.
participants (5)
-
Adrian Zaugg
-
Andreas Schulze
-
Charles Marcus
-
Darren Pilgrim
-
Reindl Harald