Re: Implications of LMTP socket being world readable and writable (0666) by default
Ah yes. Thank you both. I did not think of just overwriting the `lmtp` socket but was looking for a way to define a new socket with a different name and disable the default one. The main question remains open, though: Is the default setting insecure or am I missing something? ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
MDBOX DSYNC error: Broken physical size in mailbox
Hi All,
I currently have a small Dovecot server (Server A) and I've installed a
second dovecot mailbox server (server B) and am trying to sync mailboxes
from Server A to Server B.
Both servers sit behind two dovecot directors on separate hosts and have
identical config files (doveconf -n output below). Mailboxes on Server A
are on an NFS mount.
Server A has been working fine with no issues for a couple of years.
I'm running this command on Server A:
doveadm sync -u #user# tcp:#newservername#:24245
Small mailboxes with few items are syncing OK.. but most mailboxes fail
(sycn stops) with the following type of error: (Mailbox name, storage
file, UID and sizes vary).
dsync-local(#username#): Error: Mailbox INBOX:
Cache
/#usershomedirectory#/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.cache:
Deleting corrupted cache record uid=9: UID 9: Broken physical size in
mailbox INBOX: read(/#usershomedirectory#/mdbox/storage/m.1) failed:
Cached message size larger than expected (60616 > 8688, box=INBOX, UID=9)
If I run it again, I'll get the same error, but with a new UID.
If I do a local migration instead of server to server, I still get the
errors.
e.g. doveadm sync -u #user# maildir:~/Maildir-test/
I tried running a force resync (doveadm force-resync -u #user# -f "*)
but it didn't help.
There's no issues from an imap client accessing any emails. Using
imapsync to sync affected mailboxes works fine for example. But... if I
then run a dsync on Server B (doveadm sync -u #user#
maildir:~/Maildir-test/) on an account that was successfully migrated
with imapsync, I get the issue again.
How worried should I be about these corrupted cache records, and any
ideas how to resolve?
Thanks in advance for your help!
Paul.
--- output of doveconf -n ---
# 2.3.11.3 (502c39af9): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.11 (6c69c917)
# OS: Linux 5.3.0-1032-aws x86_64 Ubuntu 18.04.5 LTS
hostname = ###
lda_mailbox_autocreate = yes
lda_mailbox_autosubscribe = yes
login_trusted_networks = ###
mail_fsync = always
mail_location = mdbox:~/mdbox
mail_plugins = " acl notify replication"
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope
encoded-character vacation subaddress comparator-i;ascii-numeric
relational regex imap4flags copy include variables body enotify
environment mailbox date index ihave duplicate mime foreverypart extracttext
mmap_disable = yes
namespace inbox {
inbox = yes
location =
mailbox Drafts {
special_use = \Drafts
}
mailbox Junk {
special_use = \Junk
}
mailbox Sent {
special_use = \Sent
}
mailbox "Sent Messages" {
special_use = \Sent
}
mailbox Trash {
special_use = \Trash
}
prefix =
separator = /
type = private
}
namespace shared {
list = children
location =
mdbox:/mailhomes/%%d/%%n/mdbox:INDEXPVT=/mailhomes/%d/%n/shared
prefix = shared/%%u/
separator = /
subscriptions = no
type = shared
}
passdb {
args = /etc/dovecot/dovecot-ldap.conf.ext
driver = ldap
}
plugin {
acl = vfile:/tmp/global-acls:cache_secs=5
mail_plugins = " acl notify replication"
sieve = file:~/sieve;active=~/.dovecot.sieve
sieve_before = /mailhomes/sieve/global/SpamToJunk.sieve
sieve_max_actions = 32
sieve_max_redirects = 4
sieve_max_script_size = 1M
sieve_quota_max_scripts = 20
sieve_quota_max_storage = 10M
sieve_redirect_envelope_from = sender
zlib_save = bz2
zlib_save_level = 6
}
protocols = " imap lmtp sieve submission sieve"
recipient_delimiter = -
service doveadm {
inet_listener {
port = 24245
}
}
service imap-login {
process_min_avail = 2
}
service imap {
process_limit = 4096
}
service lmtp {
inet_listener lmtp {
port = 24
}
}
service managesieve-login {
inet_listener sieve {
port = 4190
}
process_min_avail = 2
service_count = 1
}
service managesieve {
process_limit = 1024
}
service submission-login {
inet_listener submission {
port = 587
}
}
ssl = required
ssl_cert =
Re: Unable to set ssl_min_protocol=TLSv1.3
Any news on setting TLS 1.3 as minimal version? I am using Debian 10 with Dovecot 2.3.4.1-5+deb10u1 and openssl 1.1.1d-0+deb10u3.
[Dovecot] Syntax of pattern in map section
I can't seem to find any documentation on the meaning/syntax of the "pattern" variable in map sections that are found in dovecot-dict-sql.conf.ext for example. I am trying to setup shared folders. The only thing[1] I found is: >>First you'll need to know what kind of dict paths the code uses. ACL >>plugin uses these paths: >> >>shared/shared-boxes/anyone/$owner >>shared/shared-boxes/user/$user/$owner >>shared/shared-boxes/group/$group/$owner What is a "dict path"? Is this some kind of hard coded identifier in the Dovecot code? I need to understand how they work because I can't use the example in http://wiki2.dovecot.org/SharedMailboxes/Shared. This is because in my PostreSQL table users are not a single column but two columns with the local and domain part[2]: Table "public.shared_mailboxes" Column | Type ---+ shared_mailbox_local | character varying(64) shared_mailbox_domain | character varying(253) shared_to_local | character varying(64) shared_to_domain | character varying(253) How should a map section look in this case? [1]http://www.dovecot.org/list/dovecot/2009-April/038922.html [2]I did this in order to use REFERENCES to ensure the user exist. Kind regards
Re: [Dovecot] Why does dovecot require the {} password sheme even if there is a $ crypt scheme.
Thanks! It does seem to work.
On Monday 13 January 2014 12:33:51 Nick Edwards wrote:
> It does, we use sha512 for long time
> in sql conf use
> default_pass_scheme = CRYPT
>
> it uses the systen crypt then, (NO - this does NOT mean it uses the
> ancient 8 char limited crypt) it will use whatever your underlying
> operating system allows, and unless you are using something thats more
> than 10 years old, it will handle better.
>
> in our sql table
>
> $6$68341f21c4d70c67$D9Rbgw.Ecvfdbvfbfgfdbc......
> ...etc
>
>
> On 1/11/14, da-dovecotlist...@abelonline.de
>
> wrote:
> > The wiki[1] says:
> > If all the passwords are in same format, you can use default_pass_scheme
> > to
> > specify it. Otherwise each password needs to be prefixed with
> > "{password-scheme}", for example "{plain}plaintext-password".
> >
> > Why doesn't dovecot recognize the crypt scheme identifier ($1$ for
> > MD5-CRYPT, $6$ for SHA512-CRYPT etc.)? At the moment I have to have the
> > following in my db for dovecot to work:
> > {SHA512-CRYPT}$6$salt$passwordhash
> >
> > [1]http://wiki2.dovecot.org/AuthDatabase/SQL
[Dovecot] Why does dovecot require the {} password sheme even if there is a $ crypt scheme.
The wiki[1] says:
If all the passwords are in same format, you can use default_pass_scheme to
specify it. Otherwise each password needs to be prefixed with
"{password-scheme}", for example "{plain}plaintext-password".
Why doesn't dovecot recognize the crypt scheme identifier ($1$ for MD5-CRYPT,
$6$ for SHA512-CRYPT etc.)? At the moment I have to have the following in my db
for dovecot to work:
{SHA512-CRYPT}$6$salt$passwordhash
[1]http://wiki2.dovecot.org/AuthDatabase/SQL
Re: [Dovecot] X.509 certificate based IMAP login
Hello Timo, On Tues., Nov 03, 2009, Timo SIRAINEN wrote: >On Mon, 2009-11-02 at 14:22 +0100, dovecotl...@encambio.com wrote: >> We would like to make it possible for users with a X.509 client >> certificate to log in without providing LDAP or any other >> credentials. > >Well.. These get you a bit further: > >ssl_ca_file = /pfx/etc/dovecot/dovecot-caroots.pem >ssl_verify_client_cert = yes >auth_ssl_username_from_cert = yes > We've got that as well as: ssl_cert_username_field = emailAddress >but to disable password check the passdb also needs to check if %k >variable's value is "valid". With SQL this would be easy. With LDAP, I >guess it doesn't really work now. Unless you used e.g. checkpassword >script to do both checks. > Thanks Timo, I'll check out the checkpassword script feature which I think is new to Dovecot since a few months. We're not using SQL at atll, so hopefully it will work with LDAP and checkpassword. Regards, Brian
[Dovecot] X.509 certificate based IMAP login
Hello list,
The dovecot version is 1.2.6 running on Solaris x86 11 (nv-b91).
The relevant configuration lines are:
passdb ldap { # LDAP database (doc/wiki/AuthDatabase.LDAP.txt.)
args = /pfx/etc/dovecot/dovecot-ldap.conf
}
The file dovecot-ldap.conf is correct and LDAP authentication is
working well.
We would like to make it possible for users with a X.509 client
certificate to log in without providing LDAP or any other
credentials. Is there something like:
passdb x509 {
args = /pfx/etc/dovecot/dovecot-caroots.pem
nopwd = yes
}
...avaibable, or is there another solution?
Thanks,
Brian
Re: [Dovecot] Trying nonplaintext mech with LDAP password-hash
Hello Timo,
An mer., avr 08, 2009, Timo Sirainen schrieb:
>On Thu, 2009-04-09 at 00:31 +0200, dovecotl...@encambio.com wrote:
>> I've already verified that this works correctly with plaintext
>> (CLEARTEXT in slapd.conf), but I really want to store the passwords
>> in LDAP using some hash. Why doesn't LDAP-MD5 work as advertised?
>
>Because it's impossible to support it. Read
>http://wiki.dovecot.org/Authentication/Mechanisms
>
>> What did the author mean by 'properly hashed passwords'? Thanks.
>
>I made it a link now to
>http://wiki.dovecot.org/Authentication/PasswordSchemes#Non-plaintext_authentication_mechanisms
>
The new text clears up the confusion. Before, it sounded as at least
CRAM-MD5 could be implemented with MD5 encoded password stoarge. I
suppose if LDAP could store passwords in CRAM-MD5 format (whatever
that is) then this goal would be achievable. Reading slapd.conf(5),
it seems LDAP can only store {SSHA}, {SHA}, {SMD5}, {MD5}, {CRYPT},
and {CLEARTEXT}. It's probably in the RFC, and CRAM-MD5 is missing
from the list.
How sad.
--
Eduard
[Dovecot] Trying nonplaintext mech with LDAP password-hash
Hello List,
The only passdb block in /pfx/etc/dovecot/dovecot.conf is:
passdb ldap {
args = /pfx/etc/dovecot/dovecot-ldap.conf
}
In /pfx/etc/dovecot/dovecot-ldap.conf:
auth_bind = no
dn = cn=mymgr,dc=host,dc=tld
dnpass =
default_pass_scheme = LDAP-MD5
In /pfx/etc/openldap/slapd.conf:
password-hash {MD5}
If I try:
$ /pfx/bin/ldapsearch <...> \
| grep '^userPassword' \
| sed -e 's;.*:: \(.*\)$;\1;' \
| mimencode -u
...I get the correct password (MD5 hashed.)
According to wiki.dovecot.org/AuthDatabase/LDAP/PasswordLookups this
should work, and indeed when starting dovecot it does not complain
about:
'CRAM-MD5 mechanism can't be supported with given passdbs'
Instead it starts right up, but when a thunderbird client
connects and tries authenticating with CRAM-MD5 it fails.
In the wiki page 'PasswordLookups' it mentions:
Supports non-plaintext authentication mechanisms (if
returning plaintext/properly hashed passwords).
I've already verified that this works correctly with plaintext
(CLEARTEXT in slapd.conf), but I really want to store the passwords
in LDAP using some hash. Why doesn't LDAP-MD5 work as advertised?
What did the author mean by 'properly hashed passwords'? Thanks.
--
Eduard
Re: [Dovecot] deliver vs lda
On mer., avr 08, 2009, Daniel L. Miller wrote:
> Timo Sirainen wrote:
>> deliver is the binary name. but it's configured inside protocol lda {}
>> section. This is getting annoying, any thoughts on what would be a good
>> unifying name?
>>
>> a) deliver binary, protocol deliver {}
>>
>> b) lda binary, protocol lda {}
>>
>> c) dovecot-lda binary, protocol lda {}
>>
>> d) mda binary, protocol mda {}
>>
>> e) dovecot-mda binary, protocol mda {}
>>
>> f) something else?
>>
>> In any case protocol lda {} would work for a while longer for backwards
>> compatibility.
>>
>> c) and e) choices also makes me think if e.g. imap and imap-login should
>> be called dovecot-imap and dovecot-imap-login instead. People have had
>> trouble finding them since ps|grep dovecot doesn't find them..
>>
>>
I like option c as well, however I don't like the idea of three
level binary and process names dovecot-this-that. Hopefully a
better solution to the imap/imap-login missing 'dovecot' will
be found.
--
Eduard
