Uppercase username emails are rejected
When a sender writes my email address with my username uppercase, e.g. USERNAME@name.com, in the to: field of their MUA, my mail server rejects that email. /var/log/mail.log prints:
USERNAME@redacted.com: host mail.redacted.com[private/dovecot-lmtp] said: 550 5.1.1
USERNAME@redacted.com User doesn't exist: USERNAME@redacted.com (in reply to RCPT TO command)
In the manual, I found that:
auth_username_format Default: %Lu Formatting applied to username before querying the auth database. You can use the standard variables here. Examples: %Lu Lowercases the username [...]
My current setting was not the default; I had: auth_username_format = %n
So I updated that setting to: auth_username_format = %Lu expecting that %Lu would lowercase the username - and that my problem would be fixed.
It does not though. Updating this setting not only prompts my email server to still reject USERNAME@redacted.com, but now also rejects (lowercase username) username@redacted.com (which my server had no issue receiving beforehand).
So I reverted auth_username_format to: auth_username_format = %n
Emails sent to username@redacted.com land in my mailbox again - but emails sent to USERNAME@redacted.com still don't.
What can I try to troubleshoot? Which config file shall I share with you?
lua8ds--- via dovecot skrev den 2024-04-06 16:34:
So I updated that setting to: auth_username_format = %Lu
keep this in dovecot, if users can change CaSEusERNAMES that can start a new qouta !
Emails sent to username@redacted.com land in my mailbox again - but emails sent to USERNAME@redacted.com still don't.
you have the last one outside of dovecot, so it most be changed outside of dovecot :)
What can I try to troubleshoot? Which config file shall I share with you?
none
Am 06.04.2024 um 16:34 schrieb lua8ds--- via dovecot:
So I updated that setting to: auth_username_format = %Lu expecting that %Lu would lowercase the username - and that my problem would be fixed.
It's not auth where you have to fix the uppercase / lowercase issue.
Check your userdb / passdb settings. You didn't tell us what config your are using in that regard. Please see i.e.
https://doc.dovecot.org/configuration_manual/authentication/passwd_file/
There's too the possibility to define 'username_format=%Ln'.
Alexander
On 06/04/2024 17:34 EEST lua8ds--- via dovecot dovecot@dovecot.org wrote: When a sender writes my email address with my username uppercase, e.g. USERNAME@name.com, in the to: field of their MUA, my mail server rejects that email. /var/log/mail.log prints: USERNAME@redacted.com: host mail.redacted.com[private/dovecot-lmtp] said: 550 5.1.1 > USERNAME@redacted.com User doesn't exist: USERNAME@redacted.com (in reply to RCPT TO > command) In the manual, I found that: auth_username_format Default: %Lu Formatting applied to username before querying the auth database. You can use the standard variables here. Examples: %Lu Lowercases the username [...] My current setting was not the default; I had: auth_username_format = %n So I updated that setting to: auth_username_format = %Lu expecting that %Lu would lowercase the username - and that my problem would be fixed. It does not though. Updating this setting not only prompts my email server to still reject USERNAME@redacted.com, but now also rejects (lowercase username) username@redacted.com (which my server had no issue receiving beforehand). So I reverted auth_username_format to: auth_username_format = %n Emails sent to username@redacted.com land in my mailbox again - but emails sent to USERNAME@redacted.com still don't. What can I try to troubleshoot? Which config file shall I share with you? _______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org Did you try %Ln? Aki
On 06/04/2024 17:34 EEST lua8ds--- via dovecot dovecot@dovecot.org wrote: When a sender writes my email address with my username uppercase, e.g. USERNAME@name.com, in the to: field of their MUA, my mail server rejects that email. /var/log/mail.log prints: USERNAME@redacted.com: host mail.redacted.com[private/dovecot-lmtp] said: 550 5.1.1 > USERNAME@redacted.com User doesn't exist: USERNAME@redacted.com (in reply to RCPT TO > command) In the manual, I found that: auth_username_format Default: %Lu Formatting applied to username before querying the auth database. You can use the standard variables here. Examples: %Lu Lowercases the username [...] My current setting was not the default; I had: auth_username_format = %n So I updated that setting to: auth_username_format = %Lu expecting that %Lu would lowercase the username - and that my problem would be fixed. It does not though. Updating this setting not only prompts my email server to still reject USERNAME@redacted.com, but now also rejects (lowercase username) username@redacted.com (which my server had no issue receiving beforehand). So I reverted auth_username_format to: auth_username_format = %n Emails sent to username@redacted.com land in my mailbox again - but emails sent to USERNAME@redacted.com still don't. What can I try to troubleshoot? Which config file shall I share with you? _______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org Did you try %Ln? Aki
On 7/04/24 02:34, lua8ds--- via dovecot wrote:
When a sender writes my email address with my username uppercase, e.g. USERNAME@name.com, in the to: field of their MUA, my mail server rejects that email. /var/log/mail.log prints:
<USERNAME@redacted.com>: host mail.redacted.com[private/dovecot-lmtp] said: 550 5.1.1 > <USERNAME@redacted.com> User doesn't exist: USERNAME@redacted.com (in reply to RCPT TO > command)In the manual, I found that:
auth_username_format
auth_username_format is for the authentication backend and has nothing to do with receiving mail. You want to change the args line under userdb, add an "L" modifier to username_format, so something like:
args = username_format=%Ln ...
Alternatively you can probably configure your MTA to lowercase the username before it passes the message off to dovecot.
Peter
Updating:
args = username_format=%Ln
under userdb did not fix my issue.
My server still rejects incoming emails with uppercase username e.g. USERNAME@tld.
In /etc/dovecot/conf.d/auth-passwd-file.conf.ext, before I updated with your suggestion i.e. %Ln, I had:
passdb { driver = passwd-file args = scheme=CRYPT username_format=%u /etc/dovecot/users }
userdb { driver = passwd-file args = username_format=%u /etc/dovecot/users
I updated to
passdb { driver = passwd-file args = scheme=CRYPT username_format=%u /etc/dovecot/users }
userdb { driver = passwd-file args = username_format=%Ln /etc/dovecot/users
FYI after I updated and tested sending an email with uppercase username again, I ran
# systemctl reload dovecot postfix
also
# dovecot reload
What else can I try?
I tried args = username_format=%Lu too, in vain.
PS thanks for pointing that I should look at username_format rather than auth_ username_format
# dovecot -n # 2.3.7.2 (3c910f64b): /etc/dovecot/dovecot.conf # Pigeonhole version 0.5.7.2 () # OS: Linux 5.4.0-156-generic x86_64 Trisquel GNU/Linux 10.0.1, Nabia # Hostname: mail.redacted_tld auth_mechanisms = plain login auth_username_format = %n mail_location = maildir:~/Maildir mail_privileged_group = mail namespace inbox { inbox = yes location = mailbox Drafts { auto = create special_use = \Drafts } mailbox Junk { auto = create autoexpunge = 30 days special_use = \Junk } mailbox Sent { special_use = \Sent } mailbox Trash { auto = create special_use = \Trash } prefix = } passdb { driver = pam } protocols = imap lmtp imap lmtp service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0660 user = postfix } } service lmtp { unix_listener /var/spool/postfix/private/dovecot-lmtp { group = postfix mode = 0600 user = postfix } } ssl = required ssl_cert = </etc/letsencrypt/live/mail.redacted_tld/fullchain.pem ssl_client_ca_dir = /etc/ssl/certs ssl_dh = # hidden, use -P to show it ssl_key = # hidden, use -P to show it ssl_min_protocol = TLSv1.2 ssl_prefer_server_ciphers = yes userdb { driver = passwd }
"lua8ds---" == lua8ds--- via dovecot dovecot@dovecot.org writes:
Updating: args = username_format=%Ln
under userdb did not fix my issue.
My server still rejects incoming emails with uppercase username e.g. USERNAME@tld.
In /etc/dovecot/conf.d/auth-passwd-file.conf.ext, before I updated with your suggestion i.e. %Ln, I had:
passdb { driver = passwd-file args = scheme=CRYPT username_format=%u /etc/dovecot/users }
userdb { driver = passwd-file args = username_format=%u /etc/dovecot/users
I updated to
passdb { driver = passwd-file args = scheme=CRYPT username_format=%u /etc/dovecot/users }
I think you need to update both places, so that your username and password checks are done with lowercase usernames.
userdb { driver = passwd-file args = username_format=%Ln /etc/dovecot/users
FYI after I updated and tested sending an email with uppercase username again, I ran
# systemctl reload dovecot postfix
also
# dovecot reload
What else can I try?
I tried args = username_format=%Lu too, in vain.
PS thanks for pointing that I should look at username_format rather than auth_ username_format
# dovecot -n # 2.3.7.2 (3c910f64b): /etc/dovecot/dovecot.conf # Pigeonhole version 0.5.7.2 () # OS: Linux 5.4.0-156-generic x86_64 Trisquel GNU/Linux 10.0.1, Nabia # Hostname: mail.redacted_tld auth_mechanisms = plain login auth_username_format = %n mail_location = maildir:~/Maildir mail_privileged_group = mail namespace inbox { inbox = yes location = mailbox Drafts { auto = create special_use = \Drafts } mailbox Junk { auto = create autoexpunge = 30 days special_use = \Junk } mailbox Sent { special_use = \Sent } mailbox Trash { auto = create special_use = \Trash } prefix = } passdb { driver = pam } protocols = imap lmtp imap lmtp service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0660 user = postfix } } service lmtp { unix_listener /var/spool/postfix/private/dovecot-lmtp { group = postfix mode = 0600 user = postfix } } ssl = required ssl_cert = </etc/letsencrypt/live/mail.redacted_tld/fullchain.pem ssl_client_ca_dir = /etc/ssl/certs ssl_dh = # hidden, use -P to show it ssl_key = # hidden, use -P to show it ssl_min_protocol = TLSv1.2 ssl_prefer_server_ciphers = yes userdb { driver = passwd } _______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
On 14/04/24 12:09, John Stoffel via dovecot wrote:
I think you need to update both places, so that your username and password checks are done with lowercase usernames.
Generally speaking you want auth to be case-sensitive, but go ahead and try it to see if it fixes the issue.
Peter
"Peter" == Peter via dovecot dovecot@dovecot.org writes:
On 14/04/24 12:09, John Stoffel via dovecot wrote:
I think you need to update both places, so that your username and password checks are done with lowercase usernames.
Generally speaking you want auth to be case-sensitive, but go ahead and try it to see if it fixes the issue.
Umm... not for emails you don't. Since the john@stoffel.org and JOHN@stoffel.org and JOHN@STOFFEL.ORG are all the same email address... should they be different logins? Not for email...
In general, usernames should NOT be case sensitive, that way leads madness. Passwords on the other hand...
John Stoffel via dovecot skrev den 2024-04-16 14:51:
In general, usernames should NOT be case sensitive, that way leads madness. Passwords on the other hand...
lets hope for dovecot fix it to not let L missing or even optional :(
dovecot qouta is also case sensitive, one million quotas for same email address, no go
John Stoffel via dovecot skrev den 2024-04-16 14:51:
In general, usernames should NOT be case sensitive, that way leads madness.
Linux user names are case sensitive. I tend not to argue with basis unix/linux implementations, those are mostly well thought through by experts. This is from before the time that 'idiot' companies started using email addresses for logins, so it is easier (to track users across platforms), after a decade or so these idiots are starting to realize this has not been to smart, forcing them to introduce 2fa work-arounds. Having a separate undisclosed username already is a form of 2fa. This is what you get when you use a hammer on a screw instead of a screwdriver.
Marc via dovecot skrev den 2024-04-16 15:51:
Linux user names are case sensitive. I tend not to argue with basis unix/linux implementations, those are mostly well thought through by experts. This is from before the time that 'idiot' companies started using email addresses for logins, so it is easier (to track users across platforms), after a decade or so these idiots are starting to realize this has not been to smart, forcing them to introduce 2fa work-arounds. Having a separate undisclosed username already is a form of 2fa. This is what you get when you use a hammer on a screw instead of a screwdriver.
i can see you already know how to use a drill, but talk nicely on public maillists does not cost much
Linux user names are case sensitive. I tend not to argue with basis unix/linux implementations, those are mostly well thought through by experts. This is from before the time that 'idiot' companies started using email addresses for logins, so it is easier (to track users across platforms), after a decade or so these idiots are starting to realize this has not been to smart, forcing them to introduce 2fa work-arounds. Having a separate undisclosed username already is a form of 2fa. This is what you get when you use a hammer on a screw instead of a screwdriver.
i can see you already know how to use a drill, but talk nicely on public maillists does not cost much
Yes I am in demolition work!!!! ;)
On 17/04/24 00:51, John Stoffel via dovecot wrote:
"Peter" == Peter via dovecot dovecot@dovecot.org writes:
On 14/04/24 12:09, John Stoffel via dovecot wrote:
I think you need to update both places, so that your username and password checks are done with lowercase usernames.
Generally speaking you want auth to be case-sensitive, but go ahead and try it to see if it fixes the issue.
Umm... not for emails you don't. Since the john@stoffel.org and JOHN@stoffel.org and JOHN@STOFFEL.ORG are all the same email address... should they be different logins? Not for email...
There is a difference between expecting $random_stranger to get the case correct on an email address and expecting a user to get his own email address correct for the purpose of logging in, also keeping in mind that the user will generally get it entered *once* in their MUA and the MUA will store it for future logins expecting the case to be correct is not a huge ask in this scenario.
Also keep in mind that the username is not always going to be the same as the email address, in fact Dovecot is perfectly capable of having usernames that are entirely different to the email address that is associated with them.
In general, usernames should NOT be case sensitive, that way leads madness. Passwords on the other hand...
Both usernames and passwords are part of the authentication credentials. When you allow any authentication credential to be case-insensitive then you decrease the difficulty of any brute-force attack by quite a bit. There is no good reason to make usernames case-insensitive and very good reasons not to.
Peter
On 17/04/2024 08:27 EEST Peter via dovecot dovecot@dovecot.org wrote: On 17/04/24 00:51, John Stoffel via dovecot wrote: >>>>>> "Peter" == Peter via dovecot dovecot@dovecot.org writes: On 14/04/24 12:09, John Stoffel via dovecot wrote: I think you need to update both places, so that your username and password checks are done with lowercase usernames. Generally speaking you want auth to be case- sensitive, but go ahead and try it to see if it fixes the issue. Umm... not for emails you don't. Since the john@stoffel.org and JOHN@stoffel.org and JOHN@STOFFEL.ORG are all the same email address... should they be different logins? Not for email... There is a difference between expecting $random_stranger to get the case correct on an email address and expecting a user to get his own email address correct for the purpose of logging in, also keeping in mind that the user will generally get it entered *once* in their MUA and the MUA will store it for future logins expecting the case to be correct is not a huge ask in this scenario. Also keep in mind that the username is not always going to be the same as the email address, in fact Dovecot is perfectly capable of having usernames that are entirely different to the email address that is associated with them. In general, usernames should NOT be case sensitive, that way leads madness. Passwords on the other hand... Both usernames and passwords are part of the authentication credentials. When you allow any authentication credential to be case-insensitive then you decrease the difficulty of any brute-force attack by quite a bit. There is no good reason to make usernames case-insensitive and very good reasons not to. Peter _______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org Unfortunately some systems uppercase (or downcase) your email when sending mail to you. In general I would advocate using auth_username_format=%Ln or %Lu to normalize to lowercase. I dont believe you would really get that much benefit from mixed case address. Aki
On 17.04.24 08:43, Aki Tuomi wrote:
On 17/04/24 00:51, John Stoffel via dovecot wrote: >>>>>> "Peter" == Peter via dovecot <dovecot@dovecot.org> writes: Generally speaking you want auth to be case- sensitive, but go ahead and try it to see if it fixes the issue. Umm... not for emails you don't. Since the john@stoffel.org and JOHN@stoffel.org and JOHN@STOFFEL.ORG are all the same email address
No they aren't. The *host part* is case insensitive because the DNS is, but nothing in the RFCs suggests that the *user part* may be (generally) treated as such. That only came about when the makers of a certain, famously case insensitive OS started selling a mail server software better aligned with their habits.
(Back with SunOS, when account names automatically yielded deliverable e-mail addresses, my dpt. had a standing rule that admins would have an unprivileged account like, e.g., "bern" and a separate UID=0 account "Bern" for the admin work. Luckily, the login(1) triggered its OH, IT SEEMS THAT THIS TERMINAL SUPPORTS ONLY SINGLE CASE mode only if the username was *entirely* in uppercase, not on the first character ...)
Having that said, nothing keeps you from setting up your MTA/MDA so as to ignore case entirely (because people manually entering addresses never make typos, but erroneously slip onto <SHIFT> or <CAPSLOCK> all the time, I suppose ...), but it's a major no-no for (intermediate) MTAs.
Unfortunately some systems uppercase (or downcase) your email when sending mail to you.
In particular, websites you create an account on, apparently in fear that joe@shmoe would otherwise be able to create multiple accounts with Joe@shmoe, jOe@shmoe etc. etc.. They rarely object to plussed user addresses or single-person-owned domains that could have a catchall configured, though ...
(I *should* have tried a user part with "ß" on an upcaseing online service back when that umlaut officially *didn't have* an uppercase version ... ;-)
Kind regards,
Jochen Bern Systemingenieur
Binect GmbH
No they aren't. The *host part* is case insensitive because the DNS is,
Indeed. Letsencrypt is utilizing this characteristic, they query the same hostname every time with different randomized(?) capitalizations. I have no idea what the logics behind this is. Preventing this from showing in logs? Preventing rate limiters to be triggered? No idea why they do this.
, but erroneously slip onto <SHIFT> or <CAPSLOCK> all the time, I suppose ...),
:D
On 17/04/2024 12:42 EEST Marc via dovecot dovecot@dovecot.org wrote: No they aren't. The *host part* is case insensitive because the DNS is, Indeed. Letsencrypt is utilizing this characteristic, they query the same hostname every time with different randomized(?) capitalizations. I have no idea what the logics behind this is. Preventing this from showing in logs? Preventing rate limiters to be triggered? No idea why they do this. >, but erroneously slip onto <SHIFT> or <CAPSLOCK> all the time, I suppose ...), :D _______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org This is a DNS hardening thing to make it harder to spoof replies. DNS name comparison is still case insensitive. Aki
On Wed, 17 Apr 2024 at 05:42, Peter via dovecot dovecot@dovecot.org wrote:
On 17/04/24 00:51, John Stoffel via dovecot wrote:
> "Peter" == Peter via dovecot dovecot@dovecot.org writes:
On 14/04/24 12:09, John Stoffel via dovecot wrote:
I think you need to update both places, so that your username and password checks are done with lowercase usernames.
Generally speaking you want auth to be case-sensitive, but go ahead and try it to see if it fixes the issue.
Umm... not for emails you don't. Since the john@stoffel.org and JOHN@stoffel.org and JOHN@STOFFEL.ORG are all the same email address... should they be different logins? Not for email...
There is a difference between expecting $random_stranger to get the case correct on an email address and expecting a user to get his own email address correct for the purpose of logging in, also keeping in mind that the user will generally get it entered *once* in their MUA and the MUA will store it for future logins expecting the case to be correct is not a huge ask in this scenario.
Also keep in mind that the username is not always going to be the same as the email address, in fact Dovecot is perfectly capable of having usernames that are entirely different to the email address that is associated with them.
In general, usernames should NOT be case sensitive, that way leads madness. Passwords on the other hand...
Both usernames and passwords are part of the authentication credentials. When you allow any authentication credential to be case-insensitive then you decrease the difficulty of any brute-force attack by quite a bit. There is no good reason to make usernames case-insensitive and very good reasons not to.
I cannot semantically argue with your wording, they are indeed both "part of the authentication credentials.",but usernames are IDENTIFICATION, not AUTHENTICATION.
And in the same way you do not have a case sensitive name, you should not have a case sensitive username. (Society's convention is that your name is capitalised in Proper Noun format, from a information technology perspective, all lowercase is the same convention).
Regards
Simon
participants (9)
-
Aki Tuomi
-
Alexander Dalloz
-
Benny Pedersen
-
Jochen Bern
-
John Stoffel
-
lua8ds＠proton.me
-
Marc
-
Peter
-
Simon B