Re: [Dovecot] dovecot stats
Am 08.05.2013 11:25, schrieb Jan-Frode Myklebust: > Thanks, nice graphs. I've attached a graph over LMTP delays per minute as > seen from the postfix side on one of our servers. This includes delays > caused by both delivery to dovecot LMTP, and also LMTP communication > internally on the mailservers between postfix and amavis. Unfortunately it > says nothing about the delivery time to each individual dovecot backend, > since these are hiding behind dovecot director, and therefor we have no way > of knowing which of our backends are slow (if any). > > > > -jf > > > >> > i am not sure, i ll have to read more doku perhaps it makes sense to use delay stuff in log for analyse i.e after all i am not using directors, i have "real" loadbalancers private/dovecot-lmtp], delay=1.4, delays=1.2/0/0/0.17, dsn=2.0.0, status=sent Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: [Dovecot] AuthenticationFailedException: [IN-USE] Couldn't open INBOX: Permission denied
Thank you very much for the additional context. On 2013-05-08, at 9:40 PM, Ben Morrow wrote: > At 4AM + on 9/05/13 you (Earles, Jill) wrote: >> Wow, that is a lot of detail. Thank you very much. I appreciate the >> Unix security perspective - that's something I'm trying to learn more >> about and be more in tune with as a new systems administrator. >> >> We are not using dotlocks, and the adduser command does create all the >> mailbox files with the correct ownership automatically. >> >> I don't know what MTA or MDA are. > > These are standard mail jargon, so you'll probably come across them > again. MTA is Mail Transfer Agent, that is, the program which receives > incoming mail (usually by SMTP) and decides what to do with it. > Traditionally on Unix this was Sendmail; nowadays it might be Postfix or > Exim or something instead. > > MDA is Mail Delivery Agent, and it's the program the MTA hands a mail to > when it decides to deliver it to a local user. (You may also see LDA, > Local Delivery Agent, used for the same thing.) Traditionally this was > often mail(1) or something equally unsuitable; nowadays it might be > procmail or maildrop or something else. Dovecot provides an MDA called > 'deliver' or 'dovecot-lda' (they're the same program) which it's often > worth using if you haven't got a good reason not to. > > Other terms are: MUA, Mail User Agent, which is a program users use to > read mail; and MSA, Mail Submission Agent, which is the program users > use to submit new mail for delivery; traditionally this was sendmail(8), > but now it's more usual to have a special-purpose SMTP server, often > running on port 587. (Users should not submit mail directly to MX SMTP > servers, because generally mail needs to be cleaned up before being sent > off-site.) > > From the point-of-view of the mail system, a POP/IMAP server like > Dovecot is considered part of the MUA, the other part being the user's > actual client; this arrangement, and the corresponding actual- > client/submission-server split for outgoing mail, is often called > 'split-client'. > > Ben >
Re: [Dovecot] AuthenticationFailedException: [IN-USE] Couldn't open INBOX: Permission denied
At 4AM + on 9/05/13 you (Earles, Jill) wrote: > Wow, that is a lot of detail. Thank you very much. I appreciate the > Unix security perspective - that's something I'm trying to learn more > about and be more in tune with as a new systems administrator. > > We are not using dotlocks, and the adduser command does create all the > mailbox files with the correct ownership automatically. > > I don't know what MTA or MDA are. These are standard mail jargon, so you'll probably come across them again. MTA is Mail Transfer Agent, that is, the program which receives incoming mail (usually by SMTP) and decides what to do with it. Traditionally on Unix this was Sendmail; nowadays it might be Postfix or Exim or something instead. MDA is Mail Delivery Agent, and it's the program the MTA hands a mail to when it decides to deliver it to a local user. (You may also see LDA, Local Delivery Agent, used for the same thing.) Traditionally this was often mail(1) or something equally unsuitable; nowadays it might be procmail or maildrop or something else. Dovecot provides an MDA called 'deliver' or 'dovecot-lda' (they're the same program) which it's often worth using if you haven't got a good reason not to. Other terms are: MUA, Mail User Agent, which is a program users use to read mail; and MSA, Mail Submission Agent, which is the program users use to submit new mail for delivery; traditionally this was sendmail(8), but now it's more usual to have a special-purpose SMTP server, often running on port 587. (Users should not submit mail directly to MX SMTP servers, because generally mail needs to be cleaned up before being sent off-site.) >From the point-of-view of the mail system, a POP/IMAP server like Dovecot is considered part of the MUA, the other part being the user's actual client; this arrangement, and the corresponding actual- client/submission-server split for outgoing mail, is often called 'split-client'. Ben
Re: [Dovecot] AuthenticationFailedException: [IN-USE] Couldn't open INBOX: Permission denied
I should have done more work myself before writing that last message. I quickly found that MTA is Mail Transfer Agent. In my case, this is Postfix. And MDA is Mail Delivery Agent, in my case, this is Dovecot LDA. More details to read at http://wiki.dovecot.org/LDA/Postfix. Thanks again, Ben, for writing all you have about this. I know a lot more about this system that I did before I made this mistake, which is great. Cheers On 2013-05-08, at 9:25 PM, "Earles, Jill" wrote: > 0750 seems to work just fine. > > I would like to know about MTA and MDA if you're willing to give me a quick > rundown. > > Thank you very much for all of your help. > > On 2013-05-08, at 9:11 PM, "Earles, Jill" wrote: > >> Wow, that is a lot of detail. Thank you very much. I appreciate the Unix >> security perspective - that's something I'm trying to learn more about and >> be more in tune with as a new systems administrator. >> >> We are not using dotlocks, and the adduser command does create all the >> mailbox files with the correct ownership automatically. >> >> I don't know what MTA or MDA are. >> >> Based on what you've said, I think I'll try changing it to 0750 and see how >> things go. Best to start with the least privileges and go from there. >> >> On 2013-05-08, at 8:30 PM, Ben Morrow >> wrote: >> >>> At 2AM + on 9/05/13 you (Earles, Jill) wrote: >> >> May 8 17:46:49 moose dovecot: pop3(lib.sysadmin): Error: >> stat(/var/spool/mail/lib.sysadmin) failed: Permission denied > > This is interesting: normally stat only fails if the permissions on the > directory (that is, /var/spool/mail itself) are wrong. Check you haven't > changed them by mistake. Yes, that was it. Thank you! Do you know what the permissions should be on that directory? I used 0770 for now, but could change it if that's not ideal. >>> >>> Well, there are basically three possibilities. If Dovecot is not using >>> dotlocks (see http://wiki2.dovecot.org/MailboxFormat/mbox), and nothing >>> else is either, you can probably get away with 0755, provided you >>> precreate mailbox files for all users with the correct ownership. (On >>> some systems the 'adduser' command or local equivalent will do this for >>> you, or can be instructed to.) If all mail-reading and -writing programs >>> will run with group 'mail', you can reduce that to 0750 root:mail; I >>> noticed before you were using mail_privileged_group, so the Dovecot >>> mail processes will run with group mail; you would need to check your >>> MTA's configuration to see what rights your MDA runs with, and also >>> check if there are any other processes accessing the mailboxes directly. >>> >>> If you are using dotlocks, then anything accessing the mbox files needs >>> to be able to create .lock files, which means it needs write access to >>> the directory. If all the relevant programs run with the 'mail' group, >>> either by being setgid mail or by being given that group some other way, >>> then 1770 root:mail is the safest option. This at least limits the >>> potential damage to processes running with the 'mail' group, but it's >>> worth having the sticky bit to ensure users can't delete each others' >>> mail: see below. >>> >>> If you can't arrange for this, you have to use 1777, that is, world- >>> writable and sticky. The sticky bit (bit 1000) provides some minimal >>> protection against the insanity of making the directory world-writable, >>> by forbidding a process from deleting a file it didn't create. This at >>> least stops a rogue process from deleting some else's mail, but it >>> doesn't stop them from creating a mailbox for someone that doesn't have >>> one, nor does it stop them from (dot-)locking a mailbox which isn't >>> locked, and leaving it locked indefinitely. >>> >>> All of this is dreadfully insecure, especially if you're using dotlocks, >>> and the contortions Dovecot has to go through to delete a message from a >>> mailbox without needing write access to the directory are just >>> grotesque. In general, it's worth avoiding mbox if you can. >>> >>> [Note: I currently have my 'Unix security' hat on. It's not actually >>> *that* insecure, on the scale of 'silly insecure things people routinely >>> do without realising they're insecure'... :)] >>> >>> Ben >>> >> >
Re: [Dovecot] AuthenticationFailedException: [IN-USE] Couldn't open INBOX: Permission denied
0750 seems to work just fine. I would like to know about MTA and MDA if you're willing to give me a quick rundown. Thank you very much for all of your help. On 2013-05-08, at 9:11 PM, "Earles, Jill" wrote: > Wow, that is a lot of detail. Thank you very much. I appreciate the Unix > security perspective - that's something I'm trying to learn more about and be > more in tune with as a new systems administrator. > > We are not using dotlocks, and the adduser command does create all the > mailbox files with the correct ownership automatically. > > I don't know what MTA or MDA are. > > Based on what you've said, I think I'll try changing it to 0750 and see how > things go. Best to start with the least privileges and go from there. > > On 2013-05-08, at 8:30 PM, Ben Morrow > wrote: > >> At 2AM + on 9/05/13 you (Earles, Jill) wrote: > > May 8 17:46:49 moose dovecot: pop3(lib.sysadmin): Error: > stat(/var/spool/mail/lib.sysadmin) failed: Permission denied This is interesting: normally stat only fails if the permissions on the directory (that is, /var/spool/mail itself) are wrong. Check you haven't changed them by mistake. >>> >>> Yes, that was it. Thank you! Do you know what the permissions should >>> be on that directory? I used 0770 for now, but could change it if >>> that's not ideal. >> >> Well, there are basically three possibilities. If Dovecot is not using >> dotlocks (see http://wiki2.dovecot.org/MailboxFormat/mbox), and nothing >> else is either, you can probably get away with 0755, provided you >> precreate mailbox files for all users with the correct ownership. (On >> some systems the 'adduser' command or local equivalent will do this for >> you, or can be instructed to.) If all mail-reading and -writing programs >> will run with group 'mail', you can reduce that to 0750 root:mail; I >> noticed before you were using mail_privileged_group, so the Dovecot >> mail processes will run with group mail; you would need to check your >> MTA's configuration to see what rights your MDA runs with, and also >> check if there are any other processes accessing the mailboxes directly. >> >> If you are using dotlocks, then anything accessing the mbox files needs >> to be able to create .lock files, which means it needs write access to >> the directory. If all the relevant programs run with the 'mail' group, >> either by being setgid mail or by being given that group some other way, >> then 1770 root:mail is the safest option. This at least limits the >> potential damage to processes running with the 'mail' group, but it's >> worth having the sticky bit to ensure users can't delete each others' >> mail: see below. >> >> If you can't arrange for this, you have to use 1777, that is, world- >> writable and sticky. The sticky bit (bit 1000) provides some minimal >> protection against the insanity of making the directory world-writable, >> by forbidding a process from deleting a file it didn't create. This at >> least stops a rogue process from deleting some else's mail, but it >> doesn't stop them from creating a mailbox for someone that doesn't have >> one, nor does it stop them from (dot-)locking a mailbox which isn't >> locked, and leaving it locked indefinitely. >> >> All of this is dreadfully insecure, especially if you're using dotlocks, >> and the contortions Dovecot has to go through to delete a message from a >> mailbox without needing write access to the directory are just >> grotesque. In general, it's worth avoiding mbox if you can. >> >> [Note: I currently have my 'Unix security' hat on. It's not actually >> *that* insecure, on the scale of 'silly insecure things people routinely >> do without realising they're insecure'... :)] >> >> Ben >> >
Re: [Dovecot] AuthenticationFailedException: [IN-USE] Couldn't open INBOX: Permission denied
Wow, that is a lot of detail. Thank you very much. I appreciate the Unix security perspective - that's something I'm trying to learn more about and be more in tune with as a new systems administrator. We are not using dotlocks, and the adduser command does create all the mailbox files with the correct ownership automatically. I don't know what MTA or MDA are. Based on what you've said, I think I'll try changing it to 0750 and see how things go. Best to start with the least privileges and go from there. On 2013-05-08, at 8:30 PM, Ben Morrow wrote: > At 2AM + on 9/05/13 you (Earles, Jill) wrote: May 8 17:46:49 moose dovecot: pop3(lib.sysadmin): Error: stat(/var/spool/mail/lib.sysadmin) failed: Permission denied >>> >>> This is interesting: normally stat only fails if the permissions on the >>> directory (that is, /var/spool/mail itself) are wrong. Check you haven't >>> changed them by mistake. >> >> Yes, that was it. Thank you! Do you know what the permissions should >> be on that directory? I used 0770 for now, but could change it if >> that's not ideal. > > Well, there are basically three possibilities. If Dovecot is not using > dotlocks (see http://wiki2.dovecot.org/MailboxFormat/mbox), and nothing > else is either, you can probably get away with 0755, provided you > precreate mailbox files for all users with the correct ownership. (On > some systems the 'adduser' command or local equivalent will do this for > you, or can be instructed to.) If all mail-reading and -writing programs > will run with group 'mail', you can reduce that to 0750 root:mail; I > noticed before you were using mail_privileged_group, so the Dovecot > mail processes will run with group mail; you would need to check your > MTA's configuration to see what rights your MDA runs with, and also > check if there are any other processes accessing the mailboxes directly. > > If you are using dotlocks, then anything accessing the mbox files needs > to be able to create .lock files, which means it needs write access to > the directory. If all the relevant programs run with the 'mail' group, > either by being setgid mail or by being given that group some other way, > then 1770 root:mail is the safest option. This at least limits the > potential damage to processes running with the 'mail' group, but it's > worth having the sticky bit to ensure users can't delete each others' > mail: see below. > > If you can't arrange for this, you have to use 1777, that is, world- > writable and sticky. The sticky bit (bit 1000) provides some minimal > protection against the insanity of making the directory world-writable, > by forbidding a process from deleting a file it didn't create. This at > least stops a rogue process from deleting some else's mail, but it > doesn't stop them from creating a mailbox for someone that doesn't have > one, nor does it stop them from (dot-)locking a mailbox which isn't > locked, and leaving it locked indefinitely. > > All of this is dreadfully insecure, especially if you're using dotlocks, > and the contortions Dovecot has to go through to delete a message from a > mailbox without needing write access to the directory are just > grotesque. In general, it's worth avoiding mbox if you can. > > [Note: I currently have my 'Unix security' hat on. It's not actually > *that* insecure, on the scale of 'silly insecure things people routinely > do without realising they're insecure'... :)] > > Ben >
Re: [Dovecot] AuthenticationFailedException: [IN-USE] Couldn't open INBOX: Permission denied
At 2AM + on 9/05/13 you (Earles, Jill) wrote: > >> > >> May 8 17:46:49 moose dovecot: pop3(lib.sysadmin): Error: > >> stat(/var/spool/mail/lib.sysadmin) failed: Permission denied > > > > This is interesting: normally stat only fails if the permissions on the > > directory (that is, /var/spool/mail itself) are wrong. Check you haven't > > changed them by mistake. > > Yes, that was it. Thank you! Do you know what the permissions should > be on that directory? I used 0770 for now, but could change it if > that's not ideal. Well, there are basically three possibilities. If Dovecot is not using dotlocks (see http://wiki2.dovecot.org/MailboxFormat/mbox), and nothing else is either, you can probably get away with 0755, provided you precreate mailbox files for all users with the correct ownership. (On some systems the 'adduser' command or local equivalent will do this for you, or can be instructed to.) If all mail-reading and -writing programs will run with group 'mail', you can reduce that to 0750 root:mail; I noticed before you were using mail_privileged_group, so the Dovecot mail processes will run with group mail; you would need to check your MTA's configuration to see what rights your MDA runs with, and also check if there are any other processes accessing the mailboxes directly. If you are using dotlocks, then anything accessing the mbox files needs to be able to create .lock files, which means it needs write access to the directory. If all the relevant programs run with the 'mail' group, either by being setgid mail or by being given that group some other way, then 1770 root:mail is the safest option. This at least limits the potential damage to processes running with the 'mail' group, but it's worth having the sticky bit to ensure users can't delete each others' mail: see below. If you can't arrange for this, you have to use 1777, that is, world- writable and sticky. The sticky bit (bit 1000) provides some minimal protection against the insanity of making the directory world-writable, by forbidding a process from deleting a file it didn't create. This at least stops a rogue process from deleting some else's mail, but it doesn't stop them from creating a mailbox for someone that doesn't have one, nor does it stop them from (dot-)locking a mailbox which isn't locked, and leaving it locked indefinitely. All of this is dreadfully insecure, especially if you're using dotlocks, and the contortions Dovecot has to go through to delete a message from a mailbox without needing write access to the directory are just grotesque. In general, it's worth avoiding mbox if you can. [Note: I currently have my 'Unix security' hat on. It's not actually *that* insecure, on the scale of 'silly insecure things people routinely do without realising they're insecure'... :)] Ben
Re: [Dovecot] AuthenticationFailedException: [IN-USE] Couldn't open INBOX: Permission denied
Thank you very much for your quick response. Problem solved (see below for
details).
On 2013-05-08, at 6:47 PM, Ben Morrow wrote:
> At 12AM + on 9/05/13 you (Earles, Jill) wrote:
>> I've been pouring over the documentation for dovecot, but can't find a
>> solution to this problem. I recently took over administration of the
>> dovecot email service at the University where I work, and things were
>> going smoothly. We've been creating email accounts for use with JIRA,
>> a bug reporting/tracking system, and one day recently, when I tried to
>> add a new account to JIRA, I got this error returned from dovecot:
>>
>> "AuthenticationFailedException: [IN-USE] Couldn't open INBOX:
>> Permission denied"
>
> This is not a dovecot message: presumably it's from JIRA?
You're right, that is how JIRA translated the message it got from dovecot. The
message I found in the dovecot log was very similar.
>
>> I got help from Atlassian, the creators of JIRA, and they sent me
>> links to some forum posts that said that changing the permissions of
>> that user's /var/mail/ directory to 0600 would solve the problem. I
>> changed that and no longer got the error.
>
> You say '/var/mail directory' but your dovecot.conf suggests you mean a
> file in /var/spool/mail. You need to be clear about which you mean.
Sorry about that. There is a symlink between the two. Yes, I changed it on
/var/spool/mail.
>
> Dovecot changes down to the user's uid to access the mail folders, so
> assuming the owners are correct either 0600 or 0660 should be fine.
> (Which you choose depends on how paranoid you are about users reading
> each others' mail, and what the group ownership is.
>
>> Being satisfied that this was a solution, I created a bunch of new
>> email accounts today to replace exchange accounts, and then changed
>> the permissions on all the /var/mail/ directories to 0600. Now I'm
>> getting that error again, even for pre-existing email addresses,
>> including the one that I had previously fixed by changing the
>> permissions the same way. I tried changing some of the older accounts
>> back to 0660, which is what they had before, and I still get the error
>> even after restarting dovecot.
> [...]
>> # dovecot -n
>> # 2.0.9: /etc/dovecot/dovecot.conf
>> # OS: Linux 2.6.32-131.0.15.el6.x86_64 x86_64 Red Hat Enterprise Linux
>> Server release 6.4 (Santiago)
>> auth_debug = yes
>> auth_debug_passwords = yes
>
> Careful with this. You end up with passwords in the logs.
I'll get rid of this - was just grasping at straws trying to find a solution.
>
> [...]
>> Here's an except of the maillog from a recent attempt:
> [...]
>>
>> May 8 17:46:49 moose dovecot: pop3(lib.sysadmin): Error:
>> stat(/var/spool/mail/lib.sysadmin) failed: Permission denied
>
> This is interesting: normally stat only fails if the permissions on the
> directory (that is, /var/spool/mail itself) are wrong. Check you haven't
> changed them by mistake.
Yes, that was it. Thank you! Do you know what the permissions should be on
that directory? I used 0770 for now, but could change it if that's not ideal.
So glad it was a simple thing after all. And, as stupid as I feel for doing
this, it's a much better feeling than having taken down the mail server and not
knowing how to fix it.
>
>> May 8 17:46:50 moose dovecot: auth: Debug: client in:
>> AUTH#0111#011PLAIN#011service=pop3#011lip={ip removed}#011rip={ip
>> removed}#011lport=110#011rport=64420#011resp=
>
> See? You've just posted the password for 'bvauw.relais'. Change it, now.
Damn, and there I was thinking I'd been careful about removing the sensitive
stuff. It's been changed.
>
> Ben
>
Thank you again. Have a great day.
Jill
Re: [Dovecot] AuthenticationFailedException: [IN-USE] Couldn't open INBOX: Permission denied
At 12AM + on 9/05/13 you (Earles, Jill) wrote:
> I've been pouring over the documentation for dovecot, but can't find a
> solution to this problem. I recently took over administration of the
> dovecot email service at the University where I work, and things were
> going smoothly. We've been creating email accounts for use with JIRA,
> a bug reporting/tracking system, and one day recently, when I tried to
> add a new account to JIRA, I got this error returned from dovecot:
>
> "AuthenticationFailedException: [IN-USE] Couldn't open INBOX:
> Permission denied"
This is not a dovecot message: presumably it's from JIRA?
> I got help from Atlassian, the creators of JIRA, and they sent me
> links to some forum posts that said that changing the permissions of
> that user's /var/mail/ directory to 0600 would solve the problem. I
> changed that and no longer got the error.
You say '/var/mail directory' but your dovecot.conf suggests you mean a
file in /var/spool/mail. You need to be clear about which you mean.
Dovecot changes down to the user's uid to access the mail folders, so
assuming the owners are correct either 0600 or 0660 should be fine.
(Which you choose depends on how paranoid you are about users reading
each others' mail, and what the group ownership is.)
> Being satisfied that this was a solution, I created a bunch of new
> email accounts today to replace exchange accounts, and then changed
> the permissions on all the /var/mail/ directories to 0600. Now I'm
> getting that error again, even for pre-existing email addresses,
> including the one that I had previously fixed by changing the
> permissions the same way. I tried changing some of the older accounts
> back to 0660, which is what they had before, and I still get the error
> even after restarting dovecot.
[...]
> # dovecot -n
> # 2.0.9: /etc/dovecot/dovecot.conf
> # OS: Linux 2.6.32-131.0.15.el6.x86_64 x86_64 Red Hat Enterprise Linux Server
> release 6.4 (Santiago)
> auth_debug = yes
> auth_debug_passwords = yes
Careful with this. You end up with passwords in the logs.
[...]
> Here's an except of the maillog from a recent attempt:
[...]
>
> May 8 17:46:49 moose dovecot: pop3(lib.sysadmin): Error:
> stat(/var/spool/mail/lib.sysadmin) failed: Permission denied
This is interesting: normally stat only fails if the permissions on the
directory (that is, /var/spool/mail itself) are wrong. Check you haven't
changed them by mistake.
> May 8 17:46:50 moose dovecot: auth: Debug: client in:
> AUTH#0111#011PLAIN#011service=pop3#011lip={ip removed}#011rip={ip
> removed}#011lport=110#011rport=64420#011resp=
See? You've just posted the password for 'bvauw.relais'. Change it, now.
Ben
[Dovecot] AuthenticationFailedException: [IN-USE] Couldn't open INBOX: Permission denied
I've been pouring over the documentation for dovecot, but can't find a solution
to this problem. I recently took over administration of the dovecot email
service at the University where I work, and things were going smoothly. We've
been creating email accounts for use with JIRA, a bug reporting/tracking
system, and one day recently, when I tried to add a new account to JIRA, I got
this error returned from dovecot:
"AuthenticationFailedException: [IN-USE] Couldn't open INBOX: Permission denied"
I got help from Atlassian, the creators of JIRA, and they sent me links to some
forum posts that said that changing the permissions of that user's /var/mail/
directory to 0600 would solve the problem. I changed that and no longer got
the error.
Being satisfied that this was a solution, I created a bunch of new email
accounts today to replace exchange accounts, and then changed the permissions
on all the /var/mail/ directories to 0600. Now I'm getting that error again,
even for pre-existing email addresses, including the one that I had previously
fixed by changing the permissions the same way. I tried changing some of the
older accounts back to 0660, which is what they had before, and I still get the
error even after restarting dovecot.
JIRA uses POP, port 110, to connect to the dovecot mail server. I've also had
the same problem trying to connect from Mac Mail.
Our JIRA application is used for tracking issues for the UBC Libraries, and
those email addresses are critical for the creation of tickets and adding
comments to tickets. I am at a loss for what to do.
Can anyone help? Thank you very much for your time.
# dovecot -n
# 2.0.9: /etc/dovecot/dovecot.conf
# OS: Linux 2.6.32-131.0.15.el6.x86_64 x86_64 Red Hat Enterprise Linux Server
release 6.4 (Santiago)
auth_debug = yes
auth_debug_passwords = yes
disable_plaintext_auth = no
mail_access_groups = mail
mail_location = mbox:~/mail:INBOX=/var/spool/mail/%u
mail_privileged_group = mail
mbox_write_locks = fcntl
passdb {
driver = pam
}
ssl_cert = ,
method=PLAIN, rip={ip removed}, lip={ip removed}, mpid=28302
May 8 17:46:49 moose dovecot: pop3(lib.sysadmin): Error:
stat(/var/spool/mail/lib.sysadmin) failed: Permission denied
May 8 17:46:49 moose dovecot: pop3(lib.sysadmin): Error:
stat(/var/spool/mail/lib.sysadmin) failed: Permission denied
May 8 17:46:49 moose dovecot: pop3(lib.sysadmin): Error: Couldn't open INBOX:
Permission denied
May 8 17:46:49 moose dovecot: pop3(lib.sysadmin): Couldn't open INBOX top=0/0,
retr=0/0, del=0/0, size=0
May 8 17:46:50 moose dovecot: auth: Debug: auth client connected (pid=28303)
May 8 17:46:50 moose dovecot: auth: Debug: client in:
AUTH#0111#011PLAIN#011service=pop3#011lip={ip removed}#011rip={ip
removed}#011lport=110#011rport=64420#011resp=AGJ2YXV3LnJlbGFpcwByM2xAaXMuYnZAdXc=
Re: [Dovecot] Permission problem with LDA and dovecot 2.2.1
At 9PM +0200 on 8/05/13 you (Tobi) wrote:
> Am 08.05.2013 19:21, schrieb Ben Morrow:
> > At 6PM +0200 on 7/05/13 you (Tobi) wrote:
> >> I tried with removing the base_dir definition from my config, restartet
> >> dovecot and checked with the commands you provided below:
> >> <<
> >> root@nordkap:~# doveconf -d base_dir
> >> base_dir = /usr/local/var/run/dovecot
> >> root@nordkap:~# doveconf base_dir
> >> base_dir = /usr/local/var/run/dovecot
> >> root@nordkap:~# su vmail -s /bin/sh -c "doveconf base_dir"
> >> base_dir = /usr/local/var/run/dovecot
> >> >>
> >> for me it seems that all is build with /usr/local
> > OK, that's odd. I was wondering if you had some permission problem which
> > was stopping the lda from reading the config file, but apparently not.
> Sorry my subject is a bit misleading ;-)
I wasn't confused by the subject: IIRC if LDA can't read a config file,
it will simply ignore it (on the grounds that it is often running as an
ordinary user and so might not be supposed to), meaning that if the
permissions on the config file were too restrictive the LDA running as
vmail might not have seen the base_dir setting. Apparently that's not
the case...
> As I updated today to wheezy anyway I built dovecot again with the
> following options:
> <<
> ./configure --prefix=/usr/local --localstatedir=/usr/local/var
> --with-mysql --with-sql
> make && make install
> >>
> but as well with those after starting dovecot and postfix the errors of
> the lda looking in /var/run occured again.
OK... interesting choice, now you understand why /usr/local/var is not
usually used, but anyway...
> >> But after removing the symlink and restarting dovecot I get the errors
> >> again
> >> <<
> >> May 7 17:47:57 nordkap dovecot: lda: Error: userdb lookup:
> >> connect(/var/run/dovecot/auth-userdb) failed: No such file or directory
> >> May 7 17:47:57 nordkap dovecot: lda: Fatal: Internal error occurred.
> >> Refer to server log for more information.
> >> >>
> > Are you sure you're running the right copy of dovecot-lda? I think you
> > mentioned xthread that you have a Debian-provided version installed as
> > well?
> Yes I had the version from apt as well, but removed it today after
> upgrading to wheezy. The lda is called from postfix by these lines in
> master.cf
> <<
> dovecot unix- n n - - pipe
> flags=DRhu user=vmail:vmail argv=/usr/local/libexec/dovecot/deliver -f
> ${sender} -d ${user}@${nexthop}
> >>
> so according to the path prefix it should be the correct copy of
> deliver. Is there a switch to get the version from deliver? I tried the
> usual -v and --version but no success. But even without the version I'm
> 99.99873% sure that the correct binary is used :-)
OK. So the next step is to try running deliver by hand, as vmail,
feeding it a mail from stdin, to see if that fails the same way. If it
does then I would next run it under strace, to see exactly what it's
trying to do and what files it's looking at.
You could also run ldd on deliver, just to make sure it's picking up the
right versions of the dovecot libraries. The hardcoded base_dir path
appears to be baked into libdovecot.so.0, so if you run
strings /path/to/libdovecot.so.0 | grep /var
with the appropriate full path to the library ldd says deliver is using,
you can see which path got baked in.
Ben
Ben
Re: [Dovecot] IMAP SSL proxy (questions)
On Wed, 2013-05-08 at 20:57 +0100, Ben Morrow wrote: > > More importantly, it only works with clients (browsers) which are new > enough to send SNI. If you use, for instance, any version of IE on > Windows XP, it will not work. > Even old linux clients since 2006 (oldest copies of galeon and epiphany I have access to) have been SNI capable (even lynx) - M$ don't care and will not fix it, preferring you pay them hundreds of dollars and buy win7/8 instead. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Idea: POP3 deletion as a flag
On Tue, 2013-05-07 at 09:25 +0200, Axel Luttgens wrote: > Reading RFCs is kind of an art. > That we certainly agree on :) > Let's have a look at RFC 2119: > > Authors who follow these guidelines should incorporate this phrase > near the beginning of their document: > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described > in > RFC 2119. > > So, if you want to build your reasoning on those keywords for establishing > compliancy or lack thereof, you should restrict yourself to RFCs posterior to > RFC 2119 *and* coming with above phrase. > But that leaves earlier RFC's open, once again, to individual interpretation, since there is no specific type of "direction". I'm sure there are plenty of later RFC's that do not include "directions" because they are meant to be a guide. Remember, the POP3 RFC does include a "direction" elsewhere in it (as I previously mentioned), the fact it does not include a "direction" in relation to deletion or marked deleted messages, is open IMHO to be interpreted as being "your choice". > But then, §6 indicates that those keywords are to be used sparingly, not as a > general mean to convey > compliancy. > Perhaps because it should be up to individual implementers to decide how their software/systems are setup, unless something may be rather detrimental - I fail to see Timo's proposal as detrimental since it is not configured as default. Ultimately the choice is ours, it is like everything server/network-ish, if we do not want a feature, we do not build it in, or enable the config (file) option to use that feature (kind of why I was disappointed that Timo removed the ability to disable many auth functions like we could do in 1.x series). It's also like everything else with responsibility to running services, in each of our own countries, laws differ, we need to be aware of those laws (and of any country you host content in) with regards to what can or can not be done, either outright, or with provision (eg: clear statement of data retention in your T&C's or privacy policy etc). Cheers Noel <> signature.asc Description: This is a digitally signed message part
Re: [Dovecot] IMAP SSL proxy (questions)
At 10AM -0600 on 8/05/13 you (Trever L. Adams) wrote: > Hello everyone, > > I have seen: http://wiki.dovecot.org/HowTo/ImapProxy. It doesn't seem to > fit what I need. That page is for Dovecot 1.x, which is obsolete. You should be reading http://wiki2.dovecot.org/PasswordDatabase/ExtraFields/Proxy . > Unfortunately, I cannot use TLS. I have to use SSL. Also, I would rather > not duplicate the certificates for the IMAP servers. Hence nginx doesn't > seem to be a good choice either. > > I am hoping that since SSL has "Client Hello" which specifies the site > requested the the following could be done: > > Client - > Proxy [SYN] > Proxy -> Client [SYN, ACK] > Client -> Proxy [ACK] > Client -> Proxy [SSL With "Client Hello", having server_name in > Extension: server_name and sub-fields] Do you have any evidence that common IMAP clients support sending SNI? I've just checked, and mutt (for example) appears not to. > Proxy sees intended host > Proxy <-> Intended Server [SYN/SYN+ACK/ACK sequence] > Proxy -> Intended Server [Replay SSL/Client Hello] > Client <-> Proxy <-> Intended Server (Proxy is non decrypting > Man-in-the-Middle, just acting as a pseudo-invisible relay) > > I know that something somewhat like this works because this is how > Apache can do virtual hosts with SSL. Of course, it acts as the end > point intended server, not a proxy. I believe it is also somewhat how > Squid does SSL proxying, although I could be entirely wrong. More importantly, it only works with clients (browsers) which are new enough to send SNI. If you use, for instance, any version of IE on Windows XP, it will not work. > Is this possible? Can this be implemented in dovecot? I don't believe so. > If not, does anyone know of such a project. Proxy needs to not have > any exploitable holes and really only needs to understand enough SSL > to get the server_name, pass through the connection, replaying Client > Hello, and then knowing when to shut the connection. > > Just as a breif example, the use I have for this now is that I have > several imap servers which all have IPv6 addresses, but have to share an > IPv4 address. for SMTP side of things, this works well for all incoming > email. (As an aside, does anyone know of a similar setup for SSL traffic > on port 465 SSL for SMTP?) Similarly, I doubt this is possible for SMTP either, since the clients probably won't send SNI. Ben
Re: [Dovecot] Permission problem with LDA and dovecot 2.2.1
Am 08.05.2013 19:21, schrieb Ben Morrow:
At 6PM +0200 on 7/05/13 you (Tobi) wrote:
I tried with removing the base_dir definition from my config, restartet
dovecot and checked with the commands you provided below:
<<
root@nordkap:~# doveconf -d base_dir
base_dir = /usr/local/var/run/dovecot
root@nordkap:~# doveconf base_dir
base_dir = /usr/local/var/run/dovecot
root@nordkap:~# su vmail -s /bin/sh -c "doveconf base_dir"
base_dir = /usr/local/var/run/dovecot
>>
for me it seems that all is build with /usr/local
OK, that's odd. I was wondering if you had some permission problem which
was stopping the lda from reading the config file, but apparently not.
Sorry my subject is a bit misleading ;-)
As I updated today to wheezy anyway I built dovecot again with the
following options:
<<
./configure --prefix=/usr/local --localstatedir=/usr/local/var
--with-mysql --with-sql
make && make install
>>
but as well with those after starting dovecot and postfix the errors of
the lda looking in /var/run occured again.
But after removing the symlink and restarting dovecot I get the errors again
<<
May 7 17:47:57 nordkap dovecot: lda: Error: userdb lookup:
connect(/var/run/dovecot/auth-userdb) failed: No such file or directory
May 7 17:47:57 nordkap dovecot: lda: Fatal: Internal error occurred.
Refer to server log for more information.
>>
Are you sure you're running the right copy of dovecot-lda? I think you
mentioned xthread that you have a Debian-provided version installed as
well?
Yes I had the version from apt as well, but removed it today after
upgrading to wheezy. The lda is called from postfix by these lines in
master.cf
<<
dovecot unix- n n - - pipe
flags=DRhu user=vmail:vmail argv=/usr/local/libexec/dovecot/deliver -f
${sender} -d ${user}@${nexthop}
>>
so according to the path prefix it should be the correct copy of
deliver. Is there a switch to get the version from deliver? I tried the
usual -v and --version but no success. But even without the version I'm
99.99873% sure that the correct binary is used :-)
tobi
Re: [Dovecot] Permission problem with LDA and dovecot 2.2.1
At 6PM +0200 on 7/05/13 you (Tobi) wrote: > > I tried with removing the base_dir definition from my config, restartet > dovecot and checked with the commands you provided below: > << > root@nordkap:~# doveconf -d base_dir > base_dir = /usr/local/var/run/dovecot > root@nordkap:~# doveconf base_dir > base_dir = /usr/local/var/run/dovecot > root@nordkap:~# su vmail -s /bin/sh -c "doveconf base_dir" > base_dir = /usr/local/var/run/dovecot > >> > for me it seems that all is build with /usr/local OK, that's odd. I was wondering if you had some permission problem which was stopping the lda from reading the config file, but apparently not. > But after removing the symlink and restarting dovecot I get the errors again > << > May 7 17:47:57 nordkap dovecot: lda: Error: userdb lookup: > connect(/var/run/dovecot/auth-userdb) failed: No such file or directory > May 7 17:47:57 nordkap dovecot: lda: Fatal: Internal error occurred. > Refer to server log for more information. > >> Are you sure you're running the right copy of dovecot-lda? I think you mentioned xthread that you have a Debian-provided version installed as well? Ben
Re: [Dovecot] IMAP SSL proxy (questions)
Am 08.05.2013 18:04, schrieb Trever L. Adams: > Is this possible? Can this be implemented in dovecot? If not, does > anyone know of such a project. Proxy needs to not have any exploitable > holes and really only needs to understand enough SSL to get the > server_name, pass through the connection, replaying Client Hello, and > then knowing when to shut the connection it is a broken idea IMAP/PO3/SMTP is not a website with different contents you need ONE certificate and ONE server-name and you are done in case of dovecot as proxy you do not need SSL at all on the backend sevrers if they are not accessed via WAN signature.asc Description: OpenPGP digital signature
[Dovecot] IMAP SSL proxy (questions)
Hello everyone, I have seen: http://wiki.dovecot.org/HowTo/ImapProxy. It doesn't seem to fit what I need. Unfortunately, I cannot use TLS. I have to use SSL. Also, I would rather not duplicate the certificates for the IMAP servers. Hence nginx doesn't seem to be a good choice either. I am hoping that since SSL has "Client Hello" which specifies the site requested the the following could be done: Client - > Proxy [SYN] Proxy -> Client [SYN, ACK] Client -> Proxy [ACK] Client -> Proxy [SSL With "Client Hello", having server_name in Extension: server_name and sub-fields] Proxy sees intended host Proxy <-> Intended Server [SYN/SYN+ACK/ACK sequence] Proxy -> Intended Server [Replay SSL/Client Hello] Client <-> Proxy <-> Intended Server (Proxy is non decrypting Man-in-the-Middle, just acting as a pseudo-invisible relay) I know that something somewhat like this works because this is how Apache can do virtual hosts with SSL. Of course, it acts as the end point intended server, not a proxy. I believe it is also somewhat how Squid does SSL proxying, although I could be entirely wrong. Is this possible? Can this be implemented in dovecot? If not, does anyone know of such a project. Proxy needs to not have any exploitable holes and really only needs to understand enough SSL to get the server_name, pass through the connection, replaying Client Hello, and then knowing when to shut the connection. Just as a breif example, the use I have for this now is that I have several imap servers which all have IPv6 addresses, but have to share an IPv4 address. for SMTP side of things, this works well for all incoming email. (As an aside, does anyone know of a similar setup for SSL traffic on port 465 SSL for SMTP?) Thank you for any help, Trever
Re: [Dovecot] change inbox dotlock name
Le 8 mai 2013 à 14:42, Chris Saldanha a écrit : > Hi, > > Is there a configuration element that would allow me to change the dot-lock > name for the user's /var/mail inbox when it is locked? Hello Chris, This seems to be fully hard-coded. > dovecot (correctly) acquires .lock, but I'm having a problem with > procmail where some obscure code path is preventing procmail's acquisition of > a lock when it's that default name in /var/mail. But I fear I don't understand your problem description. Could you elaborate? Axel
[Dovecot] Xlist in userdb, Foldernames with whitespace?
Hello, i use dovecot 2.1.7 and exported all my XLIST FolderSettings to userdb Whole Story is here: http://dovecot.org/list/dovecot/2013-March/089209.html This is all successful, but there is one problem left. I use lines like this to realize individual XLIST Foldernames in usedb: namespace/inbox/mailbox=Sent namespace/inbox/mailbox/Sent/name=Sent namespace/inbox/mailbox/Sent/auto=subscribe namespace/inbox/mailbox/Sent/special_use=\sent My problem is to allow Foldernames with whitespace in it f.e. Sent Messages I tried to put these names in quotes in this line or mask the blank with backslash but nothing was working. Dovecot ist not accepting these settings: dovecot: imap: Debug: Added userdb setting: namespace/inbox/mailbox="Sent Messages" dovecot: imap: Debug: Unknown userdb setting: plugin/namespace/inbox/mailbox/"Sent Messages"/auto=subscribe dovecot: imap: Debug: Unknown userdb setting: plugin/namespace/inbox/mailbox/"Sent Messages"/name="Sent Messages" dovecot: imap: Debug: Unknown userdb setting: plugin/namespace/inbox/mailbox/"Sent Messages"/special_use=\sent How to code folders with whitespace etc. in my userdb settings? I tried a lot but nothing was correct. Thanks, Hajo
[Dovecot] change inbox dotlock name
Hi, Is there a configuration element that would allow me to change the dot-lock name for the user's /var/mail inbox when it is locked? dovecot (correctly) acquires .lock, but I'm having a problem with procmail where some obscure code path is preventing procmail's acquisition of a lock when it's that default name in /var/mail. The issue is not permissions (using a world-writeable and sticky-bit config for /var/mail). I'll dig into the procmail code if needed, but if dovecot could use a different filename for such locks, then that would solve my issue. procmail has such an option, and I only need to do this for inboxes. Thanks, Chris -- Chris Saldanha Parliant Corporation
Re: [Dovecot] dovecot stats
Thanks, nice graphs. I've attached a graph over LMTP delays per minute as seen from the postfix side on one of our servers. This includes delays caused by both delivery to dovecot LMTP, and also LMTP communication internally on the mailservers between postfix and amavis. Unfortunately it says nothing about the delivery time to each individual dovecot backend, since these are hiding behind dovecot director, and therefor we have no way of knowing which of our backends are slow (if any). -jf > <>
Re: [Dovecot] Permission problem with LDA and dovecot 2.2.1
Hi Tobi, > my problem is not why /usr/local is used > I choose this prefix intentionally so that I have the new dovecot > separeted from the "old" one from debian backports. As I tried to say in my mailing list post '/usr/local' is the right choice to avoid conflicts with binary packages provided by your favorite distribution. > My problem is more: why does the lda search in /var/run when all the > rest of dovecot correctly uses /usr/local/var/run > The problem is only the lda part. All other stuff from dovecot looks > in the correct location (login, plugins etc) > I wait until debian has 2.2 dovecot in repo and then this symlink is > not needed anymore ;-) It seems you didn't read my mail carefully ;) You do not have to wait for debian providing a dovecot 2.2 binary package. To solve your "symlink issue" right now, you do not even have to uninstall your current 2.2 installation, because you simply need to reconfigure your source tree using exactly the same configure options like before, only adding '--localstatedir=/var'. So if you used something like './configure --prefix=/usr/local' you simply need to run: --%<--- ./configure --prefix=/usr/local --localstatedir=/var' --%<--- Of course you also need to run 'make' and before running 'make install' you should remove your current '/var/run/dovecot' symlink. After restarting your dovecot service everything should be fine without the need to create that symlink. That's all what needs to be done. Cheers, Chris Am Tue, 7 May 2013 18:24:07 +0200 schrieb Christian Wiese : > Hi Tobi, > > take a look at the output from 'configure --help'. > The problem is the imo stupid default of '--localstatedir'. > %<-- > --localstatedir=DIR modifiable single-machine data [PREFIX/var] > %<-- > > Because you are obviously not specifying a prefix the default prefix > '/usr/local' is used, thus your localstatedir is '/usr/local/var'. > > When examining the output of 'configure --help' we will also find: > %<-- > --with-rundir=DIR Runtime data directory > (LOCALSTATEDIR/run/dovecot) > %<-- > > I guess now you see what your problem is. > > AS you are compiling dovecot on your own (not using any prebuilt > package) it is of course perfectly fine to use the default prefix > (/usr/local), but you might want to simply specify > '--localstatedir=/var' when running configure. > Then there should be no need for you symlink ;) > > Hope that helps. > > Cheers, > Chris >
Re: [Dovecot] dovecot stats
Am 08.05.2013 10:25, schrieb Jan-Frode Myklebust: > On Mon, May 6, 2013 at 4:37 PM, Timo Sirainen wrote: > >> On 29.4.2013, at 15.30, Jan-Frode Myklebust wrote: >> >> >>> Is it possible to collect info about POP3 and LMTP commands also ? >> >> No. I think they would be pretty boring statistics, since with POP3 pretty >> much everything causing disk I/O or CPU usage would be RETRs and with LMTP >> everything would be DATAs. >> >> > I think knowing the timings of writing messages to disk / reading from disk > would be very interesting and relevant data. Especially for us with mostly > POP3 clients, where LMTP DATAs and POP3 RETRs probably is accounting for > major parts of the server load. no urgent need for stats i count pop3 logins with xymon out of syslog in realtime, also logwatch reports lmtp/pop3/imap daily for each user by cron in daily terms perhaps have a look at http://sys4.de/de/blog/2013/01/10/xymon-dovecot-count-imap-pop3-logins-graph-central-rsyslog-server-ubuntu-lucid/ if you have xymon monitoring etc installed you have other stuff like cpu , mem, disk io too i ll plan to write some solution for xymon retrieve data out of dovecot stats too > > >>> Also, is "doveadm stats dump command" telling me the results of all >>> commands that has finished the last stats_command_min_time, or will it >>> maybe contain much more than 1 minute of activity ? >> >> It can contain much more. The stats process will keep as much data in >> memory as possible until it reaches the stats_memory_limit. The doveadm >> stats dump lists everything that the stats process knows. >> >> > > Ok, then I guess we'll need to limit our stats dumps based on last_seen. > > > -jf > Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: [Dovecot] dovecot stats
On Mon, May 6, 2013 at 4:37 PM, Timo Sirainen wrote: > On 29.4.2013, at 15.30, Jan-Frode Myklebust wrote: > > > > Is it possible to collect info about POP3 and LMTP commands also ? > > No. I think they would be pretty boring statistics, since with POP3 pretty > much everything causing disk I/O or CPU usage would be RETRs and with LMTP > everything would be DATAs. > > I think knowing the timings of writing messages to disk / reading from disk would be very interesting and relevant data. Especially for us with mostly POP3 clients, where LMTP DATAs and POP3 RETRs probably is accounting for major parts of the server load. > > Also, is "doveadm stats dump command" telling me the results of all > > commands that has finished the last stats_command_min_time, or will it > > maybe contain much more than 1 minute of activity ? > > It can contain much more. The stats process will keep as much data in > memory as possible until it reaches the stats_memory_limit. The doveadm > stats dump lists everything that the stats process knows. > > Ok, then I guess we'll need to limit our stats dumps based on last_seen. -jf
Re: [Dovecot] ot: mirroring/archiving to a Mac?
Le 8 mai 2013 à 02:44, voy...@sbt.net.au a écrit : > On Wed, May 8, 2013 10:34 am, Reindl Harald wrote: > >> yes >> http://developer.apple.com/library/mac/documentation/Darwin/Reference/Man >> Pages/man1/dovecot.1.html >> >> >> and for the archive itself imapsync and cron is his friend > > Reindl, > > thanks, so, dovecot should be there already, I'd just need to config it, > and, I could run imapsync on the real server to 'push' sync process to the > Mac; Hello, Note that Dovecot comes with the Server version of the OS only. Cost shouldn't be a problem -the Server package is terribly affordable- but, for the purpose you are considering, installing it on a client machine may be somewhat overkill, or even problematic (after all, a server isn't supposed to be run as a general purpose GUI machine...). On the other hand, Dovecot compiles easily and without a glitch on Mac OS X. HTH, Axel
