search for: orig_usernam

...mespace has a shared subscriptions file for all users, don't list subscription entries that are not visible to the user accessing it. + doveadm: Added "auth lookup" command for doing passdb lookup. + login_log_format_elements: Added %{orig_user}, %{orig_username} and %{orig_domain} expanding to the username exactly as sent by the client (before any changes auth process made). + Added ssl_prefer_server_ciphers setting. + auth_verbose_passwords: Log the password also for unknown users. + Linux: Added optional supp...

...mespace has a shared subscriptions file for all users, don't list subscription entries that are not visible to the user accessing it. + doveadm: Added "auth lookup" command for doing passdb lookup. + login_log_format_elements: Added %{orig_user}, %{orig_username} and %{orig_domain} expanding to the username exactly as sent by the client (before any changes auth process made). + Added ssl_prefer_server_ciphers setting. + auth_verbose_passwords: Log the password also for unknown users. + Linux: Added optional supp...

...'\0', NULL, "session_pid" }, /* be sure to update AUTH_REQUEST_VAR_TAB_COUNT */ { '\0', NULL, NULL } }; by { '\0', NULL, "session_pid" }, { '\0', NULL, "orig_user" }, { '\0', NULL, "orig_username" }, { '\0', NULL, "orig_domain" }, /* be sure to update AUTH_REQUEST_VAR_TAB_COUNT */ { '\0', NULL, NULL } }; In src/auth/auth-request.c around line 2116 I replaced the following lines at the end of function auth_request_get_var_expand_table_...

We are sorry to report that we have a bug in dovecot, which merits a CVE. See details below. If you haven't configured any auth_policy_* settings you are ok. This is fixed with https://git.dovecot.net/dovecot/core/commit/c3d3faa4f72a676e183f34be960cff13a5a725ae and https://git.dovecot.net/dovecot/core/commit/99abb1302ae693ccdfe0d57351fd42c67a8612fc Important vulnerability in Dovecot

...nistrators are affected? # doveconf -n | grep auth_policy_ | wc -l 0 but there /are/ default settings: # doveconf -d | grep auth_policy_ auth_policy_hash_mech = sha256 auth_policy_hash_nonce = auth_policy_hash_truncate = 12 auth_policy_reject_on_fail = no auth_policy_request_attributes = login=%{orig_username} pwhash=%{hashed_password} remote=%{real_rip} auth_policy_server_api_header = auth_policy_server_timeout_msecs = 2000 auth_policy_server_url = Is such setup vulnerable? Thanks for clarification, Andreas

On 24.01.2017 00:06, rej ex wrote: > Because we are building some monitoring application, we will need to > record all failed and successful login attempts. We need to record > remote IP, entered password in plain text, and if possible whether auth > request is for SMTP or IMAP session. SMTP? Wouldn't that be handled by your MTA, not Dovecot? AKi Tuomi wrote: > Since

Hi, I'm attempting to proxy lmtp using director to hash to the same backend as pop3/imap. My pop3/imap users are of the form: username and my lmtp users are of the form: <username at domain> Where domain is fairly redundant but does carry some useful information. Now, I can proxy lmtp using user=%{username} and destuser=%{orig_user}, and this all appears to work correctly.

There seems to be a bug with RFC822 processing in ltmp proxying that doesn't quote local parts that, for example, contain spaces. director config: director_username_hash = %Ln lmtp_proxy = yes recipient_delimiter = + protocol lmtp { auth_socket_path = director-userdb auth_username_chars = auth_username_format = %Ln passdb {

..._default_realm = auth_failure_delay = 2 secs auth_gssapi_hostname = auth_krb5_keytab = auth_master_user_separator = auth_mechanisms = plain auth_policy_hash_mech = sha256 auth_policy_hash_nonce = auth_policy_hash_truncate = 12 auth_policy_reject_on_fail = no auth_policy_request_attributes = login=%{orig_username} pwhash=%{hashed_password} remote=%{real_rip} auth_policy_server_api_header = auth_policy_server_timeout_msecs = 2000 auth_policy_server_url = auth_proxy_self = auth_realms = auth_socket_path = auth-userdb auth_ssl_require_client_cert = no auth_ssl_username_from_cert = no auth_stats = no auth_use...

...dress with no attempt whatsoever to requote that string regardless of what characters it contains, leading to the situation where a straight-through proxy fails as director is generating addresses that dovecot doesn't like. It can be corrected manually using: override_fields = destuser="%{orig_username}"@%{orig_domain} which kind of "fixes" the issue, which I had thought sufficient last year for the limited range of inputs I have, but it turns out to break director hashing as the username is then hashed containing quotes (not to mention fun with recipient_delimiter). Looking thr...

..._default_realm = auth_failure_delay = 2 secs auth_gssapi_hostname = auth_krb5_keytab = auth_master_user_separator = auth_mechanisms = plain auth_policy_hash_mech = sha256 auth_policy_hash_nonce = auth_policy_hash_truncate = 12 auth_policy_reject_on_fail = no auth_policy_request_attributes = login=%{orig_username} pwhash=%{hashed_password} remote=%{real_rip} auth_policy_server_api_header = auth_policy_server_timeout_msecs = 2000 auth_policy_server_url = auth_proxy_self = auth_realms = auth_socket_path = auth-userdb auth_ssl_require_client_cert = no auth_ssl_username_from_cert = no auth_stats = no auth_use...

Hello, I sent this into the Linux Kernel Btrfs mailing list and I got reply: "RAID-1 would be preferable" (https://lore.kernel.org/linux-btrfs/7b364356-7041-7d18-bd77-f60e0e2e2112 at lechevalier.se/T/). May I ask you for the comments as from people around the Dovecot? We are using btrfs RAID-10 (/data, 4.7TB) on a physical Supermicro server with Intel(R) Xeon(R) CPU E5-2620 v4 @