Re: Email hosting provider
On Mon, Mar 21, 2016 at 07:06:39AM +, Andre Rodier wrote: > Sorry if I am off topic a little. It's not that bad, as you say, only a little off topic. :) > I am looking for an email host provider that supports dovecot, > sieve and manage sieve. Ideally with the roundcube webmail and > managesieve plugin I can't suggest any provider, sorry, but I want to point out that if your provider gives you the described tools on the server, you can easily set up your own webmail clients. If you can use a MUA like Thunderbird, you can also use your own webmail. If the goal is to outsource all server functionality this suggestion obviously won't be useful, but I know I have seen a lot of companies who lack email expertise on staff, yet they run many HTTP servers with advanced features. > Better if it is in Europe or switzerland. I don't mind paying a > little. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: [Dovecot] Dovecot replication - I'm stuck
On Mon, Oct 28, 2013 at 01:43:48AM +0100, IT geek 31 wrote: I've been following the wiki document at http://wiki2.dovecot.org/Replication, but I've become stuck. I'm running version 2.1.3 on NetBSD 5.2 (v2.2+ isn't available as a package yet, and compiling my own is well outside my wheelhouse). I have a couple of questions: The wiki page keeps referring to vmail. Is this a just system user I need to create? Presumably on both Dovecot boxes? If I don't use virtual users, do I need this? No. If you're using system users, each user owns his/her own mail. Replication would have to be done as root (or of course by a special user with sudo or other privilege escalation.) Scroll further down that page to the part about dsync wrapper script for root SSH login (v2.2+), but oops, you don't have 2.2. Sad. I guess you'll either have to upgrade or figure out another way to do this (probably out of Dovecot scope.) Here is my dovecot -n: snip -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Strange output from LIST command
On Thu, Oct 24, 2013 at 03:48:27PM +0200, azurIt wrote: Od: Steffen Kaiser skdove...@smail.inf.fh-brs.de On Thu, 24 Oct 2013, azurIt wrote: Ok, how am i suppose to send a bug report? Everyone is ignoring this here on mailing list so this is probably not a good way but i didn't find any other on Dovecot web site. Thank you. Timo monitors this list well. So maybe: a) he is occupied with paid work or vacation, b) you've sent in no patch, c) this bug is not fatal in order to have him kick in immediately. How am i suppose to know that my report was even noticed by any developer? Again: take Steffen's word for it. Timo monitors this list well. Sometime's he's busy. If it's worth it to you, contact his company and sponsor a fix. Otherwise, wait. Sometimes Timo gets behind on replies here, but he goes back and answers every significant thread. He will reply.[1] [1] Offer void where taxed or prohibited, or if, God forbid, he got hit by a bus. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
[Dovecot] to/about Reindl (was: Login into other user's account ...)
[ Reply-To set: let's not make this another pointless thread ] On Mon, Oct 21, 2013 at 03:37:10PM +0200, Reindl Harald wrote: Am 21.10.2013 15:30, schrieb Charles Marcus: Thanks Steffen... I kill-filed Reindl a while back due to his abusive, arrogant nature... what was absusive in this thread? I think you misunderstand. Charles was actually paying you a partial compliment. He was not saying that your response was abusive. He was saying that you actually seem to have a clue most of the time. FWIW I agree on both counts. You tend to get abusive sometimes, but your technical accuracy is very good. and the abusive reply to you in the following thread was well deserved after your prove it http://dovecot.org/list/dovecot/2013-February/088587.html The idea that abuse is well deserved could be the origin of your difficulty in fitting in with online technical communities. There's really nothing worth getting angry over. If I think someone has been rude to me, my best response is no response. I haven't seen that from you. You never let anything pass. You'll probably ignore my Reply-To: header and reply to this. Too bad - I held off for a long time, because he does actually seem to have a clue most of the time. because i read docs, not only for dovecot, for a lot of other server software far away from mail and the underlying RFC's too Yes, that is obvious. You have a lot to contribute. Too bad we can only get that at a price that many posters consider too high. Sincere best wishes to you. EOT. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Using dovecot as LDA for postfix
and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Email address with special characters in userdb
On Mon, Oct 14, 2013 at 01:24:45AM -0400, Arnon Weinberg wrote: I have a userdb file set up in passwd-file format containing the following entries: doveadm user test1*te...@test.com test1-te...@test.com test1éte...@test.com test1@te...@test.com test1%te...@test.com snip I believe these are all valid characters for email addresses (per the RFC) except '@' (which ironically works without escaping). No exception is made for @. *All* 7-bit printable characters, ASCII 32 through 127, are allowed. RFC 5321. How can I get them working? dovecot --version 2.1.16 See auth_username_chars in your conf.d/10-auth.conf file. RFC 5321 notwithstanding, it's reasonable and usually a good idea to limit the characters that YOUR SITE will allow in usernames. You can still send mail to eat@Joe's@example.com, but in general, if you plan to use such addresses in your own domains, you should consider rewriting them in your MTA (aliases(5) or similar.) -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] POP3 Setup help - more info
On Mon, Oct 14, 2013 at 11:16:06AM -0400, Thomas I Higgins wrote: Well my last email went unaswered Not so. You got two replies. If you are not going to read your replies, you cannot be helped. - I assume because I didn't provide enough detailed information. Both replies noted this. One asked for clarification. Not a surprise if that is the case. Anyway, I also noted that there is no dovecot/pop3 process like there is for IMAP. Not certain that is wrong, but I am guessing it is. I am enclosing the output from a doveconf -an query - hopefully you can see a screenshot, No, I can't. (I could, but I won't, to be exact.) Please don't post binary attachments to public mailing lists. otherwise I have to figure out how to get it in text form Yes, you should. In addition to the ignored replies in the other thread, I'll ask this: why do you want to use POP3? IMAP can do everything POP3 can do, and it's superior in many ways. POP3 should have died out a decade ago. (work disables cp scp traffic). Hopefully this will provide information that will help define what I am missing? -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Doveadm with a 2nd Instance
On Wed, Oct 09, 2013 at 02:24:04PM -0400, Chris Lasater wrote: I figured this one out. The bug is associated with the default run/dovecot base_dir. If you move both instances to a different location then (or at least the one named dovecot) it works fine and I can control both instances properly. Thank you for following up. I haven't had the chance to get back to this yet, but if the list doesn't hear back from me, assume it worked. :) On 09/26/2013 09:02 AM, /dev/rob0 wrote: On Thu, Sep 26, 2013 at 12:45:01AM -0400, Chris Lasater wrote: I am trying to use 2 instances of Dovecot on the same server so I can have a Director managing my connections, everything appears to be working, but I can not use doveadm to control my 2nd instance, but doveconf seems to work fine. I have noticed the same thing. It seems that doveadm ignores -i. dovecot works with -c /path/to/other/dovecot.conf, but it too ignores -i. We got the idea to try -i instance_name from http://wiki2.dovecot.org/Tools/Doveadm/Instance , but doveadm help itself does not show a -i. I have stopped and started both my instances so the config running is what is in the config file, but when I use -i Director with doveadm it uses the other instances config. And this is a big problem for trying to use doveadm director commands when the director instance uses the nonstandard paths. I haven't found a way to do that yet! -c /path/to/other/dovecot.conf didn't work. http://wiki2.dovecot.org/Tools/Doveadm/Director Currently on 2.2.5, about to switch to 2.2.6 EE. It seemed like it worked back in 2.0.9 before upgrading. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
[Dovecot] [ot] Re: Using MailDir but local messages still save in mbox format
On Mon, Sep 30, 2013 at 10:27:19AM +0200, Axel Luttgens wrote: Or add such a line to your crontab: MAIL=yourself@your.virtual.domain so as to override the default recipient, ie the user the job runs as. Probably a better idea, but that feature is not available in all known cron implementations. Mike should check his own crontab(1) manual. Do you mean that some distributions are liable to mess with such a basic behavior of the venerable cron command? But yes, always a good idea to check the relevant man pages. ;-) In Linux land, Slackware uses the simpler Dillon's cron which lacks some of the features of the more popular Vixie cron. I bet a lot of commercial Unix flavors are also using simpler cron implementations than Vixie's. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Using MailDir but local messages still save in mbox format
On Sat, Sep 28, 2013 at 04:26:03PM +0200, Axel Luttgens wrote: Le 27 sept. 2013 à 09:35, Mike Edwards a écrit : I think I just fixed the problem but I am not sure if I did it the right way.. It seems that it is postfix that did it, not dovecot. I found this in the log for every local message... Sep 26 11:10:10 zeus postfix/local[14565]: 9B0294AA15E: to=vm...@my.domain.com, orig_to=vmail, relay=local, delay=9, delays=9/0.01/0/0.02, dsn=2.0.0, status=sent (delivered to mailbox) So, I went to the postfix master.cf and commented out this line... #local unix - n n - - local Was that the correct way to do it? Hello Mike, You probably have cured the symptoms... ;-) I doubt it. The correct way to not route mail to local(8) is to take the domain in question out of mydestination. With no local transport available, but a domain is still listed in mydestination, Postfix will probably just complain about transport not available. Your cron command has very likely been built for making use of the sendmail command. When facing a naked recipient address such as vmail, Postfix' sendmail will look for an alias, then for a system user bearing that name. No, this is wrong. Where did you see this? A bare localpart address without domain has @$myorigin appended. See postconf.5.html#append_at_myorigin for details. The munged @domain shown above is Mike's $myorigin, and it is listed in his $mydestination. There's probably no alias for vmail, but you clearly have a system user named vmail; so, sendmail will proceed with a local delivery for user vmail. Nitpicking here, but sendmail does not do the delivery, only the acceptance and enqueueing. The now-commented local checks the alias_maps and does the delivery. So, you could for example define an alias: vmail: yourself@your.virtual.domain since you're potentially more interested than user vmail in the messages emitted by the cron job. This won't work if local_transport points to a service which is undefined. Or add such a line to your crontab: MAIL=yourself@your.virtual.domain so as to override the default recipient, ie the user the job runs as. Probably a better idea, but that feature is not available in all known cron implementations. Mike should check his own crontab(1) manual. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Doveadm with a 2nd Instance
On Thu, Sep 26, 2013 at 12:45:01AM -0400, Chris Lasater wrote: I am trying to use 2 instances of Dovecot on the same server so I can have a Director managing my connections, everything appears to be working, but I can not use doveadm to control my 2nd instance, but doveconf seems to work fine. I have noticed the same thing. It seems that doveadm ignores -i. dovecot works with -c /path/to/other/dovecot.conf, but it too ignores -i. We got the idea to try -i instance_name from http://wiki2.dovecot.org/Tools/Doveadm/Instance , but doveadm help itself does not show a -i. I have stopped and started both my instances so the config running is what is in the config file, but when I use -i Director with doveadm it uses the other instances config. And this is a big problem for trying to use doveadm director commands when the director instance uses the nonstandard paths. I haven't found a way to do that yet! -c /path/to/other/dovecot.conf didn't work. http://wiki2.dovecot.org/Tools/Doveadm/Director Currently on 2.2.5, about to switch to 2.2.6 EE. It seemed like it worked back in 2.0.9 before upgrading. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Ring SYNC appears to have got lost, resending after upgrade
This issue still occurs. It varies which of the four director instances gets it, but it seems that once one of them does, the only fix is to restart all four. On Mon, Sep 09, 2013 at 07:41:10AM -0500, /dev/rob0 wrote: On Mon, Sep 09, 2013 at 11:13:36AM +0200, Patrick Westenberg wrote: on Saturday I upgraded two dovecot servers from squeeze to wheezy and dovecot from 2.1.x to 2.2.5 (compiled from sources). After the upgrade everything worked fine at first. On Sunday Morning I recognized these errors (they occured after a reload for logging purpose on midnight) on one server: director: Error: Ring SYNC appears to have got lost, resending After reloading/restarting both dovecot services the error occured on both servers. After some research I deleted some zlib-File which isn't needed anymore in dovecot 2.2.x and reinstalled dovecot. The error message disappeared. Today the error occured again (after the reload on midnight) and again on one node only until reloading/restarting the other node too. However, there is an additional error message: Sep 09 10:27:07 director: Error: Ring SYNC appears to have got lost, resending Sep 09 10:27:10 director: Panic: file login-connection.c: line 88 (login_host_callback): assertion failed: (strncmp(request-line, OK\t, 3) == 0) I had the same issue (CentOS 6.4 upgraded with third-party RPMs) on Thu/Fri, and I asked Timo about it in IRC. Apparently a 2.2.6 release is due soon. He gave me two hg links claimed to fix it: http://hg.dovecot.org/dovecot-2.2/rev/f7a37b169f4a http://hg.dovecot.org/dovecot-2.2/rev/9531ec8afe8b However I did have the lost ring SYNC error recur after the cluster was upgraded to the RPM packages currently in Dovecot's EE repo (non-free, pay for access) which does include these fixes. Restart of all director instances worked for me. Actually I stopped all, then started all. So far so good. We're going to go live with this cluster soon, I hope. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
[Dovecot] zlib_save per-user or per-mailbox?
We'd like to be able to activate zlib_save per-user or per-mailbox, but it seems to be global, all or nothing. Search of this list revealed a comment from Timo in 2012: http://www.dovecot.org/list/dovecot/2012-March/064909.html where he was thinking that compression per-namespace would be a worthy feature. Was that done? I'm in the process of replacing a 2.0 system with 2.2 EE. The old system had zlib_save activated, but seems to deliver to maildirs without compression. Does a userdb_mail entry override global zlib_save? (I'm about to test that, but duh, I am asking first.) Thanks. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] zlib_save per-user or per-mailbox?
On Thu, Sep 19, 2013 at 06:14:32PM -0500, /dev/rob0 wrote: We'd like to be able to activate zlib_save per-user or per-mailbox, but it seems to be global, all or nothing. Search of this list revealed a comment from Timo in 2012: http://www.dovecot.org/list/dovecot/2012-March/064909.html where he was thinking that compression per-namespace would be a worthy feature. Was that done? I'm in the process of replacing a 2.0 system with 2.2 EE. The old system had zlib_save activated, but seems to deliver to maildirs without compression. Does a userdb_mail entry override global zlib_save? (I'm about to test that, but duh, I am asking first.) The test user having a nonstandard userdb_mail maildir:~/mail, new mail was delivered in compressed format. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Change mail_location for one user?
Top-posting fixed.
On Fri, Sep 13, 2013 at 03:15:15AM -0400, Scott Galambos wrote:
On 9/13/2013 2:40 AM, Steffen Kaiser wrote:
On Thu, 12 Sep 2013, Scott Galambos wrote:
What would I have to do to make only sarah's mail_location
~/Maildir now? My userdb is:
$: doveconf -n userdb
userdb {
driver = passwd
}
you need to pass Extra Fields to Dovecot, see last example in:
http://wiki2.dovecot.org/UserDatabase/ExtraFields
passwd-file is similiar to passwd, but I don't know, if you break
something (outside Dovecot), if you add the last field to /etc/passwd.
Because Dovecot supports multiple userdb's, you could add a
Reread that: _multiple_ means more than one.
passwd-file userdb _before_ passwd userdb, copy the line of sarah
from /etc/passwd into that new file and add the extra fields
there. See http://wiki2.dovecot.org/AuthDatabase/PasswdFile
userdb {
driver = passwd-file
args = username_format=%n /etc/dovecot/imap.passwd
}
userdb {
driver = passwd
}
I tried something similar already.
Close, but not the same. Look back at Steffen's post. There are TWO
userdb definitions. Do it that way and all is well. He answered you
completely.
passdb {
driver = shadow
}
userdb {
driver = passwd-file
args = username_format=%n /path/to/passwd
}
With only the one sarah user defined in /path/to/passwd. But then all
other users cannot log in anymore.
Only one user had a userdb entry. If you specify a userdb, the
built-in defaults do not apply.
Thunderbird says Sending of
password did not succeed. Does anyone know if specifying a userdb
stops passdb/shadow from being used? Do I need to copy all users
from the passdb/shadow system to /path/to/passwd? Was hoping to just
specify single users I wanted to override in /path/to/passwd.
--
http://rob0.nodns4.us/ -- system administration and consulting
Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Ring SYNC appears to have got lost, resending after upgrade
pop3-login {
executable = pop3-login director
}
ssl_cert = /etc/ssl/certs/wildcard.xxx.crt
ssl_key = /etc/ssl/private/wildcard.xxx.key
protocol !smtp {
passdb {
args = proxy=y nopassword=y starttls=any-cert
driver = static
}
}
protocol smtp {
passdb {
args = /usr/local/etc/dovecot/dovecot-sql.conf.ext
driver = sql
}
userdb {
args = /usr/local/etc/dovecot/dovecot-sql.conf.ext
driver = sql
}
}
protocol lmtp {
auth_socket_path = director-userdb
}
--
http://rob0.nodns4.us/ -- system administration and consulting
Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] local AND virtual mail locations ?
You posted today that it must not be possible to serve both virtual and system users on a single Dovecot instance. This is wrong. On Mon, Aug 26, 2013 at 06:11:08PM +0200, Pierre-Philipp Braun wrote: Quoting /dev/rob0 26/08/2013 15:17, mail_location: mbox:~/mail/:INBOX=/var/mail/%u mail_location: mbox:/var/spool/virtual/%d/%n.imap:INBOX=/var/spool/virtual/%d/%n This exercise becomes trivial when you follow the advice of the Dovecot wiki and give your virtual users a $HOME. (Well, to be simple, you'd also have to have INBOX in $HOME. An alternative is to specify INBOX for virtual users in your virtual userdb.) Thank for your answer. Are you referring to the VirtualUsers page? (http://wiki.dovecot.org/VirtualUsers) Ok I tried the mbox:~/ and userdb home= trick, # dovecot -n # 1.2.17: /usr/local/etc/dovecot.conf # OS: FreeBSD 8.3-RELEASE amd64 protocols: imap ssl: no disable_plaintext_auth: no login_dir: /var/run/dovecot/login login_executable: /usr/local/libexec/dovecot/imap-login first_valid_uid: 6 first_valid_gid: 6 mail_privileged_group: mail mail_location: mbox:~/ Mbox refers to a file name. Here you have given just a directory. http://wiki.dovecot.org/FindMailLocation http://wiki.dovecot.org/MailLocation/Mbox http://wiki.dovecot.org/MailboxFormat/mbox imap_client_workarounds: delay-newmail netscape-eoh tb-extra-mailbox-sep auth default: passdb: driver: passwd-file args: username_format=%n /etc/virtual/%d/passwd passdb: driver: passwd I think the second passdb should possibly be first, but it should work. You probably also need either shadow or pam as driver, not passwd. userdb: driver: static args: uid=mail gid=mail home=/var/spool/virtual/%d/%n.imap You forgot your userdb: with driver: passwd. That must precede the static userdb, because a static userdb, by definition, matches everything. http://wiki.dovecot.org/AuthDatabase/Passwd but I end up with the same result, everything is read from the virtual folders, namely /var/spool/virtual. How to also access local users' email? Yes, give them a proper userdb. This won't work on your second server either, without a userdb. If you can get the userdb right there, it would also work here. [snip] I tried with uid 999 and even if I update the ownerships on /etc/virtual/ /var/spool/virtual /var/spool/mqueue/ (no need for I don't know what /etc/virtual is. I presume that /var/spool/mqueue is the Sendmail MTA queue directory. I don't know, but it does not sound right to me that it should be owned by a virtual mailbox owner. Don't go changing ownerships at random. ONLY the virtual mailboxes should be owned by your shared-UID/GID virtual mailbox owner. /var/mail/ which get the sticky bit, here) the smtp daemon isn't able to write to the virtual mbox anymore, and I don't know why. It probably logged why/why not. I have searched the whole file system for relying '6' UID, nothing wrong is left. I don't see why my smtp deamon won't work once I change the UID _and_ update the file and folder ownerships. Maybe some freebsd system security which is today unknown to me. So I switched back to uid 6. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Disabled pop3-login
On Mon, Aug 26, 2013 at 02:28:02AM -0400, Gedalya wrote: On 08/26/2013 12:43 AM, LuKreme wrote: On 25 Aug 2013, at 18:00 , Reindl Harald h.rei...@thelounge.net wrote: Am 26.08.2013 01:42, schrieb LuKreme: In my dovecot.conf I do not have pop3-login anabled (since I do not support pop3) but you do not have it disabled protocols = imap First, that is imap. Second, the string pop3 does not appear anywhere in the output of dovecot.conf. Third, there is no protocols line in dovecot.conf either. Are you saying that to DISABLE pop3-login I have to ENABLE IMAP specifically even though IMAP already works fine? It sounds like that's exactly what he's saying. All dovecot configuration values have defaults. Reindl is saying that the default for protocols includes pop3, and your experience seems to prove he's right. If you do set that configuration item, it will include only what you specify. The original doveconf -n in the OP indicated that managesieve is desired, so that should also be in the protocols line: protocols = imap sieve -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] local AND virtual mail locations ?
On Mon, Aug 26, 2013 at 02:50:54PM +0200, Pierre-Philipp Braun wrote:
I would like to use Dovecot not only for virtual mboxes, but also for
local users. In other words, I would like to use different
mail_locations depending on passdb passwd-file versus passwd.
I believe that the default mail_location would be overridden by
userdb, not passdb.
I need that as the smtp daemon I am using (david parsons' postoffice
smtp server) serves both but is only able to process messages through
procmail on local users. Here are the two mail_locations I would
like to use:
mail_location: mbox:~/mail/:INBOX=/var/mail/%u
mail_location:
mbox:/var/spool/virtual/%d/%n.imap:INBOX=/var/spool/virtual/%d/%n
This exercise becomes trivial when you follow the advice of the
Dovecot wiki and give your virtual users a $HOME. (Well, to be
simple, you'd also have to have INBOX in $HOME. An alternative is to
specify INBOX for virtual users in your virtual userdb.)
depending on those passdb stanzas, respectively:
passdb passwd-file {
args = username_format=%n /etc/virtual/%d/passwd
}
passdb passwd {
}
Any help would be appreciated.
Here's my Dovecot version and current working configuration for
virtual users only:
# dovecot -n
dovecot -n
# 1.2.17: /usr/local/etc/dovecot.conf
Very old! Consider an upgrade to 2.2.
# OS: FreeBSD 8.3-RELEASE amd64 ufs
protocols: imap
ssl: no
disable_plaintext_auth: no
Hmmm, plaintext AUTH without TLS/SSL could be dangerous. If a spammer
can get in a position to sniff those credentials, you could be
inundated with spam to relay.
login_dir: /var/run/dovecot/login
login_executable: /usr/local/libexec/dovecot/imap-login
first_valid_uid: 6
first_valid_gid: 6
mail_location:
mbox:/var/spool/virtual/%d/%n.imap:INBOX=/var/spool/virtual/%d/%n
imap_client_workarounds: tb-extra-mailbox-sep
auth default:
user: mail
passdb:
driver: passwd-file
args: username_format=%n /etc/virtual/%d/passwd
userdb:
driver: static
args: uid=6 gid=6
I find that first_valid_uid and first_valid_gid don't look
pretty but it seems mandatory for the standard 'mail' user and
group ownerships to work on the virtual mbox files and folders.
I created the user while the group already existed. If you
have any advices on that too, I would be pleased.
There is no standard UID/GID for virtual mailboxes. In fact there
is no need to have them all share the same UID/GID. But on a shared
UID/GID virtual system, typically you should set a higher UID/GID
such that you exclude all the system accounts (100 or 500 or maybe
1000 depending on OS. If your OS starts human user accounts at UID
1000, UID 999 would be a good choice for virtual mailbox owner, with
that as first_valid_uid also.)
--
http://rob0.nodns4.us/ -- system administration and consulting
Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Dovecot auth error
On Sun, Aug 25, 2013 at 04:33:49AM -0700, mehrdad nosrati wrote: I'm newbie to Squirrelmail and just installed Dovecot in CentOS6.3. When I try to login to the Squirrelmail, then I get the following error: auth: Info: passwd(myusern...@myserver.com): unknown user http://wiki2.dovecot.org/QuickConfiguration#Authentication For system/PAM users, typically you'd also tell your MUA (Squirrelmail here) to omit the @domain from the username. my config file is as follow: # /usr/bin/doveconf -n -c /etc/dovecot/dovecot.conf # 2.0.9: /etc/dovecot/dovecot.conf -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] SMTP Proxy
On Mon, Aug 26, 2013 at 12:53:20PM -0300, Leonardo Rodrigues wrote: Em 26/08/13 11:58, /dev/rob0 escreveu: On Mon, Aug 26, 2013 at 11:49:50AM -0300, Leonardo Rodrigues wrote: extra informations ... smtp authentication is done by postfix using: A bit of extra information which might help: what is the goal? Exactly what problem are you trying to solve? You have given us nothing to go on here. Well, actually i have already done a well detailed post on the dovecot mailing list some days ago explaining my whole problem, but got no answers on that. If you'd like to check it, it's archived on: http://dovecot.org/list/dovecot/2013-August/092012.html So you did. I didn't have an opinion on that at first sight, but on review, perhaps this is an idea for you: http://wiki2.dovecot.org/PasswordDatabase/IMAP It might not be relevant at all, so I posted to this thread. You should update the other thread if it helped. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Logging passwords on auth failure/dealing with botnets
On Thu, Aug 22, 2013 at 04:16:51PM +, Michael Smith (DF) wrote: Or another option, is there any good DNS based RBLs for botnet IPs, and is there any way to tie that in to the dovecot auth system? I've been looking for botnet rbls, but what I've found so far doesn't seem to work very well. Most of the IPs that I've had to firewall don't exist in them. I guess I would first have tried Spamhaus XBL, but I guess you checked that already. The problem with using XBL, anyway, is that you might have legitimate logins from listed hosts. Example: a traveler using hotel wifi. We (TINW) really would need a new DNSBL type (or a special result) for this sort of abuse. It's a nice idea, worth building upon, if someone can fund it (or find the time to develop it, which really amounts to the same thing.) Imagine also a Dovecot network of reporters, where brute force attempts worldwide are reported from Dovecots to the DNSBL, not merely a one-way tie in. I'd also suggest listing SSH brute force attacks in the same DNSBL, possibly with a different result (127.0.0.$port, so IMAP attackers list as 127.0.0.143, SSH attackers as 127.0.0.22. Yes, we'd have to incorporate the third quad for ports 255, but the general idea is for result codes to be both machine and human readable as much as possible.) -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Postfix aliases with quota-status service
On Tue, Aug 06, 2013 at 09:27:20PM +0300, Timo Sirainen wrote: On 6.8.2013, at 20.57, Thomas Leuxner t...@leuxner.net wrote: * Timo Sirainen t...@iki.fi 2013.08.06 19:42: The idea behind quota_grace is that the last mail would be allowed to take the user somewhat over quota (e.g. up to 109% quota usage). On the next mail delivery user is already over quota, so the size of the mail is irrelevant because a mail of any size will be rejected. The initial quota-status implementation didn't even support SIZE extension since I didn't remember it existed. I'm referring to the Postfix side _only_ or the initial SMTP Handshake if you like. My point is that there is no safe way to reject mails at this level *if* the remote server doesn't play nice. I think this was the whole point of writing a policy service for Postfix. I'm not *talking* about quotas that will be handled by the delivery agents... Either you're still misunderstanding me, or vice versa. The quota rejections can be done complete in SMTP side even without SIZE: Another way, in Postfix, is to wait for end-of-DATA. Regardless of SIZE being given, at that point, the actual size is known. Of course as Thomas would probably point out, such a rejection is unsafe, because ANY overquota recipient would cause rejection for EVERY recipient; SMTP cannot have per-recipient results except at RCPT TO:. Personally, I'd much rather allow the last overquota mail, even in cases where the user goes far over the quota. Apparently Thomas intends to have a solid, inflexible quota. In that case I'd suggest going for a lower quota and adding quota_grace. Let quota_grace plus quota be the most you can tolerate in your users' mailboxes. 1) quota at 99% : MAIL FROM:sen...@example.com 250 2.1.0 Ok RCPT TO:t...@dovecot.org 250 2.1.0 Ok DATA ... . 250 2.0.0 Ok: queued as 12345 2) quota is now at 103% : MAIL FROM:send...@example.com 250 2.1.0 Ok RCPT TO:t...@dovecot.org 554 5.2.2 User is over quota -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Maildir Synchronization warnings
On Fri, Aug 02, 2013 at 03:37:04PM +0300, Timo Sirainen wrote: On Fri, 2013-08-02 at 20:21 +0800, Kavish Karkera wrote: We have 2 pop/imap servers running with director. Dovecot version = 2.1.12 Dovecot version = 2.1.13 .. mail_nfs_index = yes mail_nfs_storage = yes To improve performance you can remove these two since you're using director. Also you could set maildir_very_dirty_syncs=yes. What about mail_fsync=always and mmap_disable=yes? These are needed for non-director NFS, but what about with director? -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Case-insensitive detail mailboxes?
On Fri, Jul 26, 2013 at 10:04:22AM +0100, Darac Marjal wrote:
On Thu, Jul 25, 2013 at 11:29:56AM -0500, /dev/rob0 wrote:
We're using sieve with LMTP. We want to have
lda_mailbox_autocreate and lmtp_save_to_detail_mailbox. Is
there a way to make the detail case-insensitive? If so I
have not found it yet.
I suppose we could lowercase the input string for the SQL
userdb query, but that's not what is wanted. The idea being
that if a user makes a mailbox called Test is that
user+t...@example.com and user+t...@example.com should both
go to that Test mailbox. If it was lowercased, a mailbox
called Test would be ignored and test used.
With autocreate, this could be a problem if mail is
delivered to autocreated case-sensitive mailboxes that the
user won't see.
Hmmm, maybe a global sieve script?
I use the following sieve snippet rather than
lmtp_save_to_detail_mailbox:
if envelope :detail :regex to (.+) {
set :upperfirst :lower detail ${1};
fileinto :create Tagged/${detail};
stop;
}
Aha! On further examination I found a similar example here:
http://wiki2.dovecot.org/Pigeonhole/Sieve/Examples#Plus_Addressed_mail_filtering
I will need to tweak this a bit more, because we want to allow the
user to create a mailbox as s/he wants, whether all CAPS, all
lowercase, or Title Case (as our default setting would create a new
folder if it wasn't found.) But you've surely set me on the right
track here! Thank you!
So, if the detail portion of the TO address exists, set a variable
detail to be the first-letter-uppercased version of that portion
(test - Test, TEST - Test and so on) and file the message into
Tagged/Test, creating that if necessary.
--
http://rob0.nodns4.us/ -- system administration and consulting
Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
[Dovecot] Case-insensitive detail mailboxes?
We're using sieve with LMTP. We want to have lda_mailbox_autocreate and lmtp_save_to_detail_mailbox. Is there a way to make the detail case-insensitive? If so I have not found it yet. I suppose we could lowercase the input string for the SQL userdb query, but that's not what is wanted. The idea being that if a user makes a mailbox called Test is that user+t...@example.com and user+t...@example.com should both go to that Test mailbox. If it was lowercased, a mailbox called Test would be ignored and test used. With autocreate, this could be a problem if mail is delivered to autocreated case-sensitive mailboxes that the user won't see. Hmmm, maybe a global sieve script? -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] An unconstructive grumble
On Mon, Jun 03, 2013 at 06:23:09AM -0700, dd wrote: 5 hours of configuration attempts, error after confusing error, documentation with examples that only show extracts of working configurations. I really feel like throwing in the towel with dovecot. It should not be this hard ... Why not? You're really not in a position to make this claim. But having said that... and frankly almost impossible to understand and configure for such an incedibly simple configuration. /home/vmail/domain.name/username/cur /home/vmail/domain.name/username/new /home/vmail/domain.name/username/tmp 3 virtual users. All I want is a username and password to access my email. ... you complicated things by wanting virtual users. System users would have been much simpler to set up. Also, you missed the fact that virtual users should have a $HOME directory just like system users: http://wiki2.dovecot.org/VirtualUsers http://wiki2.dovecot.org/VirtualUsers/Home The only constructive suggestion I can make here is to scrap it and start over with system users. Let PAM / your OS handle the username and password and other daunting tasks. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] An unconstructive grumble
On Mon, Jun 03, 2013 at 05:10:35PM +0200, Simon B wrote: On 3 Jun 2013 16:49, /dev/rob0 r...@gmx.co.uk wrote: On Mon, Jun 03, 2013 at 06:23:09AM -0700, dd wrote: 3 virtual users. All I want is a username and password to access my email. ... you complicated things by wanting virtual users. System users would have been much simpler to set up. Also, you missed the fact that virtual users should have a $HOME directory just like system users: I've never understood this antipathy to virtual users. But your knowledge is greater than mine :) My antipathy? I have none. Virtual users are ideal in certain circumstances. They are NOT ideal for people who are just starting out and have no idea how all the pieces fit and work together. That way lies frustration and madness (and if you noticed, a very high percentage of the questions we see on this list.) I started out with system users, and I learned how it all works. Taking it a piece at a time is always best when starting into unfamiliar territory. http://wiki2.dovecot.org/VirtualUsers http://wiki2.dovecot.org/VirtualUsers/Home I sort of see why for legacy reasons a $home directory might once have been needed. But surely however you word it all you're doing is telling the server where to put the mails, the structure you want and the format of the files. 3 variables... No, there are other files kept in the $HOME. Quoting the link: Some uses for home directory are: - By default Sieve scripts are in user's home directory. - Duplicate mail check database is in user's home directory. Suppression of duplicate rejects/vacations won't work if home directory isn't specified. - Debugging: If an imap or pop3 process crashes, the core file is written to the user's home directory. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Passwordless auth?
On Thu, May 23, 2013 at 04:10:01PM -0700, Dan Mahoney, System Admin wrote: I'd love to hear about any other ways people have thought about to do this. Any ideas? Are you familiar with the mutt(1) MUA? I use it with a: set tunnel=MAILDIR=~/Mail/ /usr/libexec/dovecot/imap So it speaks IMAP, but to its own /usr/libexec/dovecot/imap process, not through a network socket. Maybe you could adapt this idea in some way. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Looking for a good way to manage passwords for CRAM-MD5
On Sun, May 12, 2013 at 05:40:10AM -0700, Professa Dementia wrote: On 5/12/2013 4:17 AM, Steinar Bang wrote: I prefer not to use clear text passwords, even over an encrypted connection. Why? Enforce the encrypted link by not allowing unencrypted connections. The simplest is iptables to block ports 110 and 143, while allowing 993 and 995. I don't understand this advice. Why would someone who is apparently interested in heightened transport security restrict himself to the older generation SSL v.2, which was long ago superceded by TLS v.1? http://en.wikipedia.org/wiki/Transport_Layer_Security#SSL_1.0.2C_2.0_and_3.0 http://wiki2.dovecot.org/SSL Quoting from the latter page: Some admins want to require SSL/TLS, but don't realize that this is also possible with STARTTLS (Dovecot has disable_plaintext_auth=yes and ssl=required settings). -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Moving mail servers, moving mailboxes
On Wed, Apr 17, 2013 at 07:18:54AM -0700, Gregory Sloop wrote: As long as I'm asking about mailbox formats, is it possible to use DBox with postfix - it appears on the Wiki that it's not, but then I find posts on the web that appear to indicate it *is* possible. Postfix has native support only for mbox and maildir. But Postfix can invoke the Dovecot LDA via a pipe(8) transport(5), or lmtp(8) to Dovecot's LMTP service. http://wiki2.dovecot.org/HowTo/PostfixDovecotLMTP http://wiki2.dovecot.org/LDA http://wiki2.dovecot.org/LMTP -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Postfix/Dovecot/lmtp with virtual and local users
I'm interested in this as well, and having looked over the wiki2 pages on LDA and LMTP, and the files conf.d/15-lda.conf and conf.d/20-lmtp.conf to which they refer, I still don't see how the lmtpd knows a given user@domain is a system user. For virtual domains, I guess the assumption is that the Dovecot username is user@domain. (Even that assumption is not necessarily valid; there is no requirement to format virtual usernames that way.) The closest I can find is hostname in 15-lda.conf, but that does not really say anything about it being used to identify a system user. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Dovecot as LDA with Postfix and virtual users
On Sun, Mar 17, 2013 at 04:57:36PM +0100, Christian Benke wrote: On 17 March 2013 02:58, /dev/rob0 r...@gmx.co.uk wrote: On Sun, Mar 17, 2013 at 01:20:55AM +0100, Christian Benke wrote: Some part in the configuration seems to miss though, as mails are received by Postfix, but instead of giving it to Dovecot for delivery, it delivers the mails itself. Perhaps surprisingly, this is a Postfix issue, not a Dovecot one. No, i was expecting it :-) I just wasn't sure where it belongs to. Mar 17 00:02:46 poab postfix/local[15341]: 66AD04E23EE: to=benkkk AT example.com, relay=local, delay=0.35, delays=0.3/0.01/0/0.04, dsn=2.0.0, status=sent (delivered to mailbox) This is postfix/local, which means it is not being routed to your virtual_transport. It means example.com is in mydestination. You did not even set mydestination, thus you get the default. You really should review the Postfix Basic Configuration README: No, i tried a lot yesterday and i started from a working postfix/dovecot-setup with PAM. The config i posted above was merely the last incarnation. Should probably have emphasized that. I commented out mydestination because i received warnings that i shouldn't list them in both mydestination and virtual_mailbox_domains. With mydestination commented out you get the default, which is not an empty set. $ /usr/sbin/postconf -d mydestination mydestination = $myhostname, localhost.$mydomain, localhost Still, dovecot LDA has not been called either when the mydestination-parameter was present: Mar 16 21:54:56 poab postfix/smtpd[4197]: connect from mail-we0-f176.google.com[74.125.82.176] Mar 16 21:54:56 poab postfix/smtpd[4197]: setting up TLS connection from mail-we0-f176.google.com[74.125.82.176] Mar 16 21:54:56 poab postfix/smtpd[4197]: Anonymous TLS connection established from mail-we0-f176.google.com[74.125.82.176]: TLSv1 with cipher RC4-SHA (128/128 bits) Mar 16 21:54:56 poab dovecot: auth: Debug: Loading modules from directory: /usr/lib/dovecot/modules/auth Mar 16 21:54:56 poab dovecot: auth: Debug: Module loaded: /usr/lib/dovecot/modules/auth/libdriver_mysql.so Mar 16 21:54:56 poab dovecot: auth: Debug: Module loaded: /usr/lib/dovecot/modules/auth/libdriver_pgsql.so Mar 16 21:54:56 poab dovecot: auth: Debug: Module loaded: /usr/lib/dovecot/modules/auth/libdriver_sqlite.so Mar 16 21:54:56 poab dovecot: auth: Debug: passwd-file /etc/dovecot/users: Read 1 users in 0 secs Mar 16 21:54:56 poab dovecot: auth: Debug: auth client connected (pid=0) Mar 16 21:54:56 poab postfix/trivial-rewrite[4202]: warning: do not list domain example.com in BOTH mydestination and virtual_mailbox_domains Mar 16 21:54:56 poab postfix/smtpd[4197]: 856034E1FD1: client=mail-we0-f176.google.com[74.125.82.176] Mar 16 21:54:56 poab postfix/cleanup[4203]: 856034E1FD1: message-id=CAAMQ8bS2bi6HG=u8bmc+e-_yu47wrb6dwxhh2rgsushdvpn...@mail.gmail.com Mar 16 21:54:56 poab postfix/qmgr[4195]: 856034E1FD1: from=benkkk AT wheemail.com, size=1644, nrcpt=1 (queue active) Mar 16 21:54:56 poab postfix/trivial-rewrite[4202]: warning: do not list domain example.com in BOTH mydestination and virtual_mailbox_domains This is undocumented, but when a domain is in some other class in addition to mydestination, mydestination takes priority. Don't count on that: just ensure that each address class definition (see the Address Class README) is unique. Mar 16 21:54:56 poab postfix/smtpd[4197]: disconnect from mail-we0-f176.google.com[74.125.82.176] Mar 16 21:54:56 poab postfix/local[4204]: 856034E1FD1: to=benkkk AT example.com, relay=local, delay=0.39, delays=0.33/0.01/0/0.06, dsn=2.0.0, status=sent (delivered to mailbox) Thus we see again, mail is handled by the local_transport, local(8). Mar 16 21:54:56 poab postfix/qmgr[4195]: 856034E1FD1: removed Perhaps you'd be better off without the virtual mailboxes anyway? Perhaps, and that's where i actually started from. Virtual users are an attractive feature tough and as it didn't seem too intimidating, i thought i could give it a try. 6 hours later, i was wiser. Virtual mailboxes have their place, indeed, but more so for large numbers of domains and users. For a small-timer (as it sounds like you are), I wouldn't say they're attractive. Increased complexity, decreased functionality, [usually] security tradeoffs. (System users who own all and ONLY their own mail are not going to endanger others' mail. Virtual mailboxes typically are owned by a shared UID+GID, and a compromise of that UID or GID could threaten all mail.) I've gone back to the working PAM-config today and will try to figure out SASL for now, maybe going back to virtual users later. But i'm still interested in comments regarding the mydestination issue, i can go back to the virtual user settings quickly to try. If your domain is NOT listed in mydestination, but it IS listed in virtual_mailbox_domains, it will be handled by your
Re: [Dovecot] Dovecot as LDA with Postfix and virtual users
On Sun, Mar 17, 2013 at 01:20:55AM +0100, Christian Benke wrote: I've been trying to configure Dovecot to work as LDA for file-based virtual users with Postfix. Some part in the configuration seems to miss though, as mails are received by Postfix, but instead of giving it to Dovecot for delivery, it delivers the mails itself. Perhaps surprisingly, this is a Postfix issue, not a Dovecot one. Postfix drops the mail in /var/mail/user/mbox, if Dovecot would be called, it should deliver it to /var/vmail/domain/user/Maildir. I've made sure to add the dovecot-service to postfix/master.cf according to http://wiki2.dovecot.org/LDA/Postfix and tried all kinds of settings and did quadruple checks for errors. I'm using Debian 6.0 with Dovecot 2.1.7(From backports) and Postfix 2.7.1 I've been trying to figure out what's missing for a few hours now and have to give up for today. I hope someone can help me with a hint what's missing or wrong :-/ Here's an excerpt from my mail.log, my postconf -n and dovecot -n: [snip] Mar 17 00:02:46 poab postfix/local[15341]: 66AD04E23EE: to=benkkk AT example.com, relay=local, delay=0.35, delays=0.3/0.01/0/0.04, dsn=2.0.0, status=sent (delivered to mailbox) This is postfix/local, which means it is not being routed to your virtual_transport. It means example.com is in mydestination. Mar 17 00:02:46 poab postfix/qmgr[14844]: 66AD04E23EE: removed # postconf -n alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases append_dot_mydomain = no biff = no broken_sasl_auth_clients = yes config_directory = /etc/postfix debug_peer_level = 3 inet_interfaces = all inet_protocols = all mailbox_size_limit = 512000 myhostname = example.com ... You did not even set mydestination, thus you get the default. You really should review the Postfix Basic Configuration README: http://www.postfix.org/BASIC_CONFIGURATION_README.html Perhaps you'd be better off without the virtual mailboxes anyway? [snip] Central Asia by bike, starting May 2013 - http://poab.org Wow, a great adventure, good luck! -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Dovecot SASL Client support?
On Tue, Jan 08, 2013 at 08:59:09AM -0500, Charles Marcus wrote: So that postfix can use dovecot-sasl for remotely authenticating against another SMTP server, ie, for secure relays... I don't think this makes sense for Dovecot to implement -- maybe P@rick and/or Timo will correct this if I am wrong. Server SASL is a natural offshoot of an imapd, because the same credentials are used, and just as with an IMAP client, the imapd merely has to validate the credentials. Client SASL is different. The credentials are not necessarily in use by the imapd otherwise, and the job of the client SASL library is to generate the authentication, not to validate it. I don't expect to see Dovecot providing client SASL. You mention secure relays; for this I generally use OpenVPN. With a tunnel between the sending and relaying systems, the mail goes through said tunnel. Another good choice where this might not be possible is to use TLS certificate authentication: http://www.postfix.org/TLS_README.html#server_access http://www.postfix.org/TLS_README.html#client_tls_policy -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] unknown users
On Mon, Jan 07, 2013 at 08:00:37PM +0100, Averlon wrote: can anyone tell me where these unknown users come from. Jan 7 19:43:11 f42252se postfix/pipe[14632]: 9A86C30007C: to=redm...@averlon.loc, relay=spamassassin, delay=2.2, delays=0.05/0/0/2.1, dsn=2.0.0, status=sent (delivered via spamassassin service) Jan 7 19:43:11 f42252se postfix/qmgr[14561]: 9A86C30007C: removed The original message is successfully delivered to your content filter. Jan 7 19:43:11 f42252se dovecot: auth: Debug: master in: USER#0111#011redm...@averlon.loc#011service=lda Jan 7 19:43:11 f42252se dovecot: auth: Debug: ldap(redm...@averlon.loc): pass search: base=ou=user,dc=averlon,dc=loc scope=onelevel filter=((objectClass=posixAccount)(uid=redm...@averlon.loc)) fields=uid,userPassword Here's one of your LDAP queries. Jan 7 19:43:11 f42252se dovecot: auth: ldap(redm...@averlon.loc): *unknown user* Jan 7 19:43:11 f42252se dovecot: auth: Debug: master out: NOTFOUND#0111 Jan 7 19:43:11 f42252se postfix/pipe[14637]: BE0AC30007F: to=redm...@averlon.loc, relay=dovecot, delay=0.02, delays=0/0/0/0.01, dsn=5.1.1, status=bounced (user unknown) The content filter reinjects via sendmail(1), and the pipe(8) to the Dovecot LDA fails. Your LDAP query is not returning what you expect, or you're not querying for the right thing. Jan 7 19:43:11 f42252se postfix/cleanup[14631]: C279030007E: message-id=20130107184311.c2790300...@mail.av.loc Jan 7 19:43:11 f42252se postfix/qmgr[14561]: C279030007E: from=, size=3182, nrcpt=1 (queue active) Jan 7 19:43:11 f42252se postfix/bounce[14639]: BE0AC30007F: sender non-delivery notification: C279030007E Jan 7 19:43:11 f42252se postfix/qmgr[14561]: BE0AC30007F: removed Jan 7 19:43:11 f42252se dovecot: auth: Debug: master in: USER#0111#011avad...@av.loc#011service=lda Jan 7 19:43:11 f42252se dovecot: auth: Debug: ldap(avad...@av.loc): pass search: base=ou=user,dc=averlon,dc=loc scope=onelevel filter=((objectClass=posixAccount)(uid=avad...@av.loc)) fields=uid,userPassword There's another one of your queries, looking up the sender address for delivery of the bounce. Jan 7 19:43:11 f42252se dovecot: auth: ldap(avad...@av.loc): *unknown user* Jan 7 19:43:11 f42252se dovecot: auth: Debug: master out: NOTFOUND#0111 Jan 7 19:43:11 f42252se postfix/pipe[14637]: C279030007E: to=avad...@av.loc, relay=dovecot, delay=0.01, delays=0/0/0/0.01, dsn=5.1.1, status=bounced (user unknown) Jan 7 19:43:11 f42252se postfix/qmgr[14561]: C279030007E: removed Same thing happens to the bounce. Being undeliverable, your mail is gone. +++ Tell me what you need as additional info. Turn off verbose logging in Postfix, as Charles pointed out. I guess it's only the TLS logging that you have made verbose. Review the Dovecot wiki / wiki2 (you didn't say what version you are using?) page on LDAP. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] dovecot: lda(root): Fatal: Invalid user settings. Refer to server log for more information.
On Fri, Nov 16, 2012 at 12:47:52PM -0800, Thufir wrote: I ran dovecot -a and the blizzard of data seemed ok to my limited knowledge. Is there another log I should look into to trace this error down? It's actually a Postfix problem. Postfix is invoking your Dovecot LDA with wrong permissions. Dovecot and system info: thufir@dur:~$ thufir@dur:~$ dovecot --version 2.0.19 thufir@dur:~$ thufir@dur:~$ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=12.04 DISTRIB_CODENAME=precise DISTRIB_DESCRIPTION=Ubuntu 12.04.1 LTS thufir@dur:~$ testing postfix dovecot (http://packages.ubuntu.com/precise/dovecot-postfix): root@dur:/etc/postfix# root@dur:/etc/postfix# telnet localhost 25 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 dur.bounceme.net ESMTP Postfix (Ubuntu) helo me 250 dur.bounceme.net mail from:f...@bar.com Angle brackets are required on envelope addresses (and I bet you don't own bar.com): MAIL FROM:f...@example.com 250 2.1.0 Ok rcpt to:r...@dur.bounceme.net RCPT TO:r...@dur.bounceme.net 250 2.1.5 Ok data 354 End data with CRLF.CRLF subject:ping 3 blah blah . A header must have a space after the colon. Header and body are separated by a blank line. See RFC 5322. 250 2.0.0 Ok: queued as 35EC92A0D72 quit 221 2.0.0 Bye Connection closed by foreign host. root@dur:/etc/postfix# root@dur:/etc/postfix# tail /var/log/mail.log Nov 16 12:30:07 dur postfix/smtpd[4113]: connect from localhost[127.0.0.1] Nov 16 12:30:40 dur postfix/smtpd[4113]: 35EC92A0D72: client=localhost[127.0.0.1] Nov 16 12:30:52 dur postfix/cleanup[4133]: 35EC92A0D72: message-id=20121116203040.35ec92a0...@dur.bounceme.net Nov 16 12:30:52 dur postfix/qmgr[1681]: 35EC92A0D72: from=f...@bar.com, size=321, nrcpt=1 (queue active) Nov 16 12:30:52 dur dovecot: lda(root): Error: chdir(/root/) failed: Permission denied (euid=65534(nobody) egid=65534(nogroup) missing +x perm: /root, dir owned by 0:0 mode=0700) The fix to this is simply not to deliver mail to root. You should have aliased root to a mortal user. Postfix will not invoke a mailbox_command as root. In broader terms, you should only use root for actual system administration, and not for user tasks such as reading and sending mail. See and edit /etc/aliases, then run newaliases. Example: root: thufir http://www.postfix.org/postconf.5.html#default_privs http://www.postfix.org/postconf.5.html#mailbox_command http://www.postfix.org/local.8.html http://www.postfix.org/aliases.5.html After you have done this, requeue the message: # postsuper -r 35EC92A0D72 (or just delete it, s/-r/-d/, and try another test.) http://www.postfix.org/postsuper.1.html Nov 16 12:30:52 dur dovecot: lda(root): Error: chdir(/root) failed: Permission denied Nov 16 12:30:52 dur dovecot: lda(root): Error: user root: Initialization failed: Initializing mail storage from mail_location setting failed: stat(/root/Maildir) failed: Permission denied (euid=65534(nobody) egid=65534(nogroup) missing +x perm: /root, dir owned by 0:0 mode=0700) Nov 16 12:30:52 dur dovecot: lda(root): Fatal: Invalid user settings. Refer to server log for more information. Nov 16 12:30:52 dur postfix/local[4134]: 35EC92A0D72: to=r...@dur.bounceme.net, relay=local, delay=25, delays=25/0.02/0/0.12, dsn=4.3.0, status=deferred (temporary failure) Nov 16 12:30:56 dur postfix/smtpd[4113]: disconnect from localhost[127.0.0.1] root@dur:/etc/postfix# -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] dovecot: lda(root): Fatal: Invalid user settings. Refer to server log for more information.
On Fri, Nov 16, 2012 at 10:15:24PM +, Ben Morrow wrote: postfix's local(8) will not allow you to deliver mail as root. Strictly speaking it will deliver to/as root, but not if invoking commands, which is what the OP was doing. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] dovecot: lda(root): Fatal: Invalid user settings. Refer to
On Fri, Nov 16, 2012 at 05:32:16PM -0800, Thufir wrote:
On Fri, 16 Nov 2012 16:09:54 -0600, /dev/rob0 wrote:
The fix to this is simply not to deliver mail to root. You
should have aliased root to a mortal user. Postfix will not
invoke a mailbox_command as root.
Ah, thank you. Not dovecot at all, makes sense. I was sending
to root because of a problem with keychain preventing usage of
the mail command for users:
http://ubuntuforums.org/showthread.php?t=2065461
Anyhow, that's fixed so that I can now use the mail command as a
mortal, as you put it. I think I'm on my way, and that this is a
postfix and not dovecot problem. The mail doesn't arrive, but the
log shows as delivered (I think) and then removed for some reason:
It was delivered and removed from the queue.
thufir@dur:~$ telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 dur.bounceme.net ESMTP Postfix (Ubuntu)
HELO me
250 dur.bounceme.net
mail from:thu...@example.com
250 2.1.0 Ok
rcpt to:thufir@localhost
250 2.1.5 Ok
data
354 End data with CRLF.CRLF
subject: never arrives
postfix problem?
.
250 2.0.0 Ok: queued as 3C8392A0007
quit
221 2.0.0 Bye
Connection closed by foreign host.
thufir@dur:~$
thufir@dur:~$ mail
No mail for thufir
Your mail(1) MUA is not configured (or unable) to look in the place
where the mail was, in fact, delivered.
thufir@dur:~$ tail /var/log/mail.log
Nov 16 17:19:04 dur postfix/smtpd[2975]: connect from localhost[127.0.0.1]
Nov 16 17:19:32 dur postfix/smtpd[2975]: disconnect from localhost
[127.0.0.1]
Nov 16 17:19:36 dur postfix/smtpd[2975]: connect from localhost[127.0.0.1]
Nov 16 17:20:06 dur postfix/smtpd[2975]: 3C8392A0007: client=localhost
[127.0.0.1]
Nov 16 17:20:48 dur postfix/cleanup[2985]: 3C8392A0007: message-
id=20121117012006.3c8392a0...@dur.bounceme.net
Nov 16 17:20:48 dur postfix/qmgr[1521]: 3C8392A0007:
from=thu...@example.com, size=336, nrcpt=1 (queue active)
Nov 16 17:20:48 dur dovecot: lda(thufir):
msgid=20121117012006.3c8392a0...@dur.bounceme.net: saved mail to INBOX
Dovecot says it delivered it ...
Nov 16 17:20:48 dur postfix/local[2988]: 3C8392A0007:
to=thufir@localhost, relay=local, delay=55, delays=55/0.02/0/0.17,
dsn=2.0.0, status=sent (delivered to command: /usr/lib/dovecot/deliver -
c /etc/dovecot/conf.d/01-mail-stack-delivery.conf -m ${EXTENSION})
Nov 16 17:20:48 dur postfix/qmgr[1521]: 3C8392A0007: removed
... and duly reported this success to Postfix, which deleted it from
the queue as a result.
Nov 16 17:20:54 dur postfix/smtpd[2975]: disconnect from localhost
[127.0.0.1]
Judging from your previous post where deliver tried to write to
/root/Maildir/, I suppose your mail will be found in
~thufir/Maildir/new/ .
Now Postfix is fine, Dovecot seems to be fine also. Your remaining
issue is with mail. If it's old BSD mailx, that is not very
configurable. Consider other choices, such as mutt, alpine, or
Heirloom mailx.
--
http://rob0.nodns4.us/ -- system administration and consulting
Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] POLL: v2.2 to allow one mail over quota?
On Mon, Oct 29, 2012 at 10:39:51PM +0200, Timo Sirainen wrote: Currently if user is 1MB under quota and someone tries to deliver mail that is over 1MB, Dovecot rejects the mail. But smaller mails aren't rejected probably for days. So user might not even realize that they didn't receive one of the mails. Also having a user almost over quota is a rather strange state I think. So what do you think about v2.2 allowing delivery of one last mail even if it brings the user over quota? Except add a limit that if the message size is as much as the user's entire quota limit it wouldn't be added (or 50% or ..?). Also IMAP wouldn't allow this, since user would get an error anyway. I could make this also optional, but if nobody really wants to keep the old behavior there's really no point in adding the option. I think the thing to do is to adjust the admin's thinking about it. Yes, if the current mailstore is under quota, by all means, you should accept the next email up to the maximum size the server accepts. No exception, just take it. You control $quota and $maxMsg. Set your quota with that in mind, where $(($quota - 1 + $maxMsg)) total is something you can live with. That said, I have been fortunate to never have to set up a quota. Storage is cheap. An occasional cron job can point out individual users who might be beyond what you'd consider reasonable, and to those users, apply a LART. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Changing password for users
On Fri, Oct 26, 2012 at 11:04:13PM +0200, Tom Hendrikx wrote: Using a database for managing virtual users seems overkill, until you run into issues like this. I have a postgres backend for 20ish users, and I can plugin everything I want. Postfixadmin works geat, and there are many password plugins for squirrelmail/roundcube/etc that work with such a database. Disclaimer: I tried the file-based approach too, but kept building kludges for things that were a lot simpler with a database. In the end, I joined the dark side. SQLite gives me the best of both worlds: file-based stability with SQL flexibility and easy backups. There is no Postfixadmin-type solution out there yet, but if you're fine with sqlite3(1) in the console, you won't miss it. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Locking /var/mail/user issue with postfix and dovecot
On Thu, Oct 25, 2012 at 10:23:29AM +0300, Robert JR wrote: Stan, sorry but you didnot understand my question at all, dovecot in this case is reading the mailbox file while user downloading the mail and not WRITING. only postfix write when a mail arrives and DOVECOT only read the mail. And even if both write to the file, I I can't answer (don't know), but I can tell you that this is not true. Dovecot also writes to the file: updating message read flags and such. Any help will be greatly appreciated. Maildir is not for everyone, but it does handle issues like this smoothly. The delivery agent is always able to deliver new mail. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Creating Maildir and populating with emails via external Python process
From: Tom Hendrikx t...@whyscream.net I'm intrigued by this. Why are you using some self-baked(?) python script to fetch the mail in stead of using ready-made components like fetchmail? Unless there's a special reason not to, try using the LDA (and fetchmail/getmail for that matter). This sounds exactly what you want: http://pyropus.ca/software/getmail/configuration.html#destination-mdaexternal On Thu, Oct 25, 2012 at 12:54:43PM -0700, Bradley Rintoul wrote: I am brand new to this whole email thing. I am looking at this article right now: http://www.tuxradar.com/content/get-started-fetchmail-procmail-and-dovecot I did not see where you described the ultimate goal. That should have been the starting point of this thread. Describe the problem, not how you think it should be solved, because you are new to this, and your ideas might benefit from some scrutiny. Use plain language. I have not reviewed your howto, but personally I would recommend neither fetchmail (I'd choose getmail) nor procmail (other choices exist, depending on what you are trying to do.) -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] spamc can't seem to call /usr/lib/dovecot/deliver
There seems to be much confusion in this thread. I might be able to
help clear up some of it, but probably not all, because I agree with
Robert about using amavisd-new for filtering and LMTP for delivery.
On Tue, Oct 23, 2012 at 02:52:45PM -0600, Troy Vitullo wrote:
My server uses a system comprised of postfix, dovecot and dspam to
filter and deliver mail.
Postfix used the following flags in calling spamc and dovecot:
flags=DRhu user=dovecot:secmail argv=/usr/bin/spamc -u ${recipient}
-e /usr/lib/dovecot/deliver -d ${recipient}
This looks like you might be using pipe(8). If so, refer to the
manual, and note that you are invoking this command as user dovecot
and group secmail.
That is wrong use of the dovecot user. You probably should have
made and used a dedicated vmail user. And according to your own
post, q.v., the group secmail is definitely wrong.
after an upgrade from Debian lenny to squeeze we were able to get
everything working except spam filtering. Spamassassin is able to
judge whether the mail coming in is spam but everything stops
there.
Automated or semi-automated upgrades are often a source of pain.
In mail.err I see:
pamc[3608]: exec failed: Permission denied
I guess that is spamc, and yes, of course.
spamc shows the same thing in syslog:
exec failed: Permission denied
postfix delays the email:
postfix/pipe[3607]: 50DEFF180EE: to=[mail], relay=dovecot,
delay=1.7, delays=0.07/0.01/0/1.6, dsn=4.3.0, status=deferred
(system resource problem)
Here are the permissions for deliver:
-rwsr-x--- 1 root dovecot 865084 May 25 2011 /usr/lib/dovecot/deliver
The pipe command is not executed as root. Nor is it invoked with the
GID dovecot. You specified group secmail. Therefore the other
permissions are what apply. --- is no read, no write, no execute.
Here are the relevant groups:
s1:~# grep dovecot /etc/group
secmail:x:119:postfix,spamd,dovecot
This is not relevant. The process has EGID secmail, and the fact that
dovecot is a member of secmail does not matter. Bottom line here: it
seems that you misunderstood what the group permissions meant.
dovecot:x:111:
here's the dovecot user:
s1:~# grep dovecot /etc/passwd
dovecot:x:108:111:Dovecot mail server,,,:/usr/lib/dovecot:/bin/false
here's dovecot -n:
# 1.2.15: /etc/dovecot/dovecot.conf
You upgraded -- to 1.2.15? Why?
snip
Many thanks in advance for any advice you can give.
Again, you should check on the wiki about the appropriate use of the
dovecot user, and also read the wiki about virtual mailboxes. Fix
that. Even if you make it work with permissions, you are breaking
Dovecot's security model of privilege separation. The dovecot user
is for Dovecot's internal use only, not for delivering mail and
ownership of mailboxes.
The poster who was talking about postconf(5) mailbox_command was
bringing in a red herring. That is for local(8) delivery, and you
evidently are using pipe(8).
--
http://rob0.nodns4.us/ -- system administration and consulting
Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] spamc can't seem to call /usr/lib/dovecot/deliver
On Wed, Oct 24, 2012 at 12:28:48PM -0400, Bill Shirley wrote: I don't understand why you strongly recommend against using the mailbox_command. Is there a security risk here? One issue is that mailbox_command is only used for local(8) delivery. You brought that up for the OP, who is reporting a problem in trying to use pipe(8). mailbox_command is not relevant for pipe. That added more confusion to the issue at hand. I can't speak for Robert, but as I said in the other post I agree with him, so I will say why. You will get better overall performance with amavisd-new and LMTP, rather than invoking a command via pipe for every delivery. No, mailbox_command in itself is not a security risk, except insofar as you could DoS yourself with more deliveries at once than the system is able to handle. Some risk of DoS is present for any kind of content filtering, though. But amavisd-new after-queue reduces that risk. I've read all the howtos. Eww. I have not. I have made extensive referral to the documentation, however, and that is what I recommend. Many thousands of people who are generating web content do not know much about email. You don't want to turn to them for advice about this! (FWIW, many of the howtos I have looked at are very bad.) There are many ways to setup a mail server. That's the beauty of postfix, spamassassin, dovecot, etc; you can make it do what you want. Yes, some setups are bad. Yes and yes. I am not the original poster. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] spamc can't seem to call /usr/lib/dovecot/deliver
On Wed, Oct 24, 2012 at 01:28:41PM -0400, Bill Shirley wrote: On 10/24/2012 12:32 PM, /dev/rob0 wrote: There seems to be much confusion in this thread. I might be able able to help clear up some of it, but probably not all, because I agree with Robert about using amavisd-new for filtering and LMTP for delivery. On Tue, Oct 23, 2012 at 02:52:45PM -0600, Troy Vitullo wrote: snip postfix/pipe[3607]: 50DEFF180EE: to=[mail], relay=dovecot, delay=1.7, delays=0.07/0.01/0/1.6, dsn=4.3.0, status=deferred (system resource problem) The poster who was talking about postconf(5) mailbox_command was bringing in a red herring. That is for local(8) delivery, and you evidently are using pipe(8). Just a note: the original post did NOT have the word 'virtual' in it. If it did, I missed it and apologize for introducing confusion. It did not, but it did indeed include the pipe log output shown above, and therefore ^mailbox_.* postconf settings do not apply. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] spamc can't seem to call /usr/lib/dovecot/deliver
On Wed, Oct 24, 2012 at 01:21:58PM -0400, Bill Shirley wrote: On 10/24/2012 12:44 PM, /dev/rob0 wrote: I can't speak for Robert, but as I said in the other post I agree with him, so I will say why. You will get better overall performance with amavisd-new and LMTP, rather than invoking a command via pipe for every delivery. Admittedly, I have not used amavisd-new or LMTP; they may be better. But will they allow spamassassin per-user prefs? Amavisd-new is indeed capable of per-user preferences. Performance is a plus; another daemon is not. That saying, I'll run another daemon if I get something out of it. Any benchmarks on this? A daemon is generally (I'd almost daresay always) less overhead than the invocation of many single-delivery processes. No benchmarking is needed to support this fact. That said, for many small sites, it does not matter much. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] spamc can't seem to call /usr/lib/dovecot/deliver
On Wed, Oct 24, 2012 at 02:04:39PM -0400, Bill Shirley wrote: On 10/24/2012 1:39 PM, /dev/rob0 wrote: On Wed, Oct 24, 2012 at 01:28:41PM -0400, Bill Shirley wrote: On 10/24/2012 12:32 PM, /dev/rob0 wrote: On Tue, Oct 23, 2012 at 02:52:45PM -0600, Troy Vitullo wrote: snip postfix/pipe[3607]: 50DEFF180EE: to=[mail], relay=dovecot, delay=1.7, delays=0.07/0.01/0/1.6, dsn=4.3.0, status=deferred (system resource problem) The poster who was talking about postconf(5) mailbox_command was bringing in a red herring. That is for local(8) delivery, and you evidently are using pipe(8). Just a note: the original post did NOT have the word 'virtual' in it. If it did, I missed it and apologize for introducing confusion. It did not, but it did indeed include the pipe log output shown above, and therefore ^mailbox_.* postconf settings do not apply. Could be he was going about it the wrong way; mixing the two. Do you know whether he's trying to do virtual or local? There are lots of wrong ways. The most wrongful of the OP's ways I found was the misuse of the dovecot user. The second most wrong, which was the actual problem at hand, was a misunderstanding of how group permissions are applied. Mixing virtual and local in Postfix and Dovecot is no problem at all, and in fact multiple modes of delivery are possible, even within a given address class or even within a domain. All we know here is what the OP posted. You don't usually use pipe for delivery to local (Unix) users. My postings describe my implementation. For the OP to change to local delivery would require reworking his setup extensively, on the Postfix side, and here we are on the Dovecot list, so I wouldn't go into that here. But sure, there are other (and for many purposes, better) means of doing what he might want to do. I'm just trying to help him. But I don't think my posts are being received that way. Regarding Robert's flame comment in the other subthread, I agree with you; I saw no flame. And I did not suggest that you were not trying to help. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] how to best import Evolution/Thunderbird mail into dovecot?
On Wed, Oct 17, 2012 at 07:57:38PM +0200, Christoph Anton Mitterer wrote: On Wed, 2012-10-17 at 16:51 +0200, Dennis Guhl wrote: First thing I tried was to simply copy mail within Evolution (i.e. draggingdropping it from the local folders to the IMAP folders from dovecot). This seems to be the smartest idea. Well as I've mentioned... on looses the info in the From_ lines (that is the RCPT TO address and the date of arrival) because Evolution does not correctly migrated them (actually I'm not sure whether IMAP would allow that). Perhaps you mean the ^From mbox delimiter line. You do not need mbox delimiters in maildir files. Did you mention whether or not you're using maildir? -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] how to best import Evolution/Thunderbird mail into dovecot?
On Wed, Oct 17, 2012 at 08:21:47PM +0200, Christoph Anton Mitterer wrote: On Wed, 2012-10-17 at 13:12 -0500, /dev/rob0 wrote: Did you mention whether or not you're using maildir? The reason is mainly that I have gazillions of mail in a ~ 60 GB archive... even with an fs optimised for small files I'd loose far too much space per mail than I want to afford. Fine, maildir is not the perfect solution for everyone. But I'm confused about why Evolution/Thunderbird local folders to IMAP folders does not work. That should be the best approach. If it does not work, you're going to have some perl/python/ruby scripting to do. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Anyone else seeing lots of random duplicate messages???
On Tue, Sep 04, 2012 at 12:40:48PM -0400, Charles Marcus wrote: On 2012-09-04 12:37 PM, Charles Marcus cmar...@media-brokers.com wrote: Almost every message I'm getting through this list is duplicated, down to the same exact message-ID... Anyone else seeing this? Even this one was duplicated... I think you're seeing double. Check to see if someone spiked your coffee. :) -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject: On Tue, Sep 04, 2012 at 12:40:48PM -0400, Charles Marcus wrote: On 2012-09-04 12:37 PM, Charles Marcus cmar...@media-brokers.com wrote: Almost every message I'm getting through this list is duplicated, down to the same exact message-ID... Anyone else seeing this? Even this one was duplicated... I think you're seeing double. Check to see if someone spiked your coffee. :) -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] auth trouble
On Tue, Jun 05, 2012 at 09:38:49AM -0600, Glenn English wrote: On Jun 4, 2012, at 8:45 PM, Joseph Tam wrote: If dovecot-auth is getting input from a local socket, then rhost information is irrelevant since the host doing the asking is the server itself (maybe from another daemon connected to a remote host). Thanks for the confirmation of my suspicions What suspicions were confirmed? Maybe someone is brute forcing your server's Postfix authenticated SMTP service since Postfix can be configured to use Dovecot's SASL authentication framework. And these brute force attempts would be logged, each one. and for the suggestion -- I do have Postfix using Dovecot-Auth checking for SASL. I think I'm going to re-install and run Tripwire... I think you are overreacting. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Berkeley DB with Dovecot
On Mon, May 21, 2012 at 02:37:28PM +0200, Sven Hartge wrote: Jerry je...@seibercom.net wrote: On Mon, 21 May 2012 06:14:10 -0400 Charles Marcus articulated: Out of curiousity... How is the performance of SQLite? I'm assuming it is only recommended for servers that are not under heavy load... SQLite support in Postfix is fairly young. I'm not sure about Dovecot, but again I doubt it has been around as long as real RDB systems. It hasn't existed as long as they have! 2000 May 29 was the initial Alpha release. In contrast, MySQL appeared in 1995, and PostgreSQL evolved in 1996 from a much older project. SQLite.org has a very old article where someone did some read and write benchmarking against MySQL and PostgreSQL. In those tests it did very well. This is what I'd expect, since there is nothing between the application and the database. The SQLite file will be cached in system RAM if it is frequently accessed, which in a moderate mail server, it certainly would be. I don't have a busy system, but I expect it could handle anything one might throw at it. What are the main advantages/disadvantages of using SQLite over MySQL? At this point there is no easy frontend for SQLite-managed mail servers. If you want to give a non-technical user the ability to manage accounts, at this point, you'd probably have to write a GUI interface. (That should not be a problem for a competent programmer in just about any language.) Being younger code, it is less well tested. If you recall, I stumbled upon a potentially serious bug in Postfix, fixed in 2.8.9 and 2.9.0. Poorly managed file permissions could have led to SQL injection attacks. (But Postfix does complain about it if the logs is not owned by and only writable by root.) SQLite.org has a good when to use SQLite page: http://sqlite.org/whentouse.html I found numerous links for just that sort of information on Google Bing. These two seem rather informative. http://stackoverflow.com/questions/2824135/how-fast-is-berkeley-db-sql-compared-to-sqlite http://www.oracle.com/technetwork/database/berkeleydb/learnmore/bdbvssqlite-wp-186779.pdf Hmm. Those documenets only talk about heavy writing to the database which is not involved in the Dovecot scenario discussed here, where the database is used as a data storage for the configuration which is mostly read. Note that the same is true of BDB. I wouldn't expect SQLite to beat BDB on raw read speed, but I'd expect it to show respectably, as did the Oracle author (as he stated in the stackoverflow page.) SQLite might vary widely depending on the schema and SQL queries. BDB, OTOH, is not going to vary in that regard: it's only a Key-to- Value mapping. In comparing SQLite to BDB, I did optimize my own setup to reduce some of the multiple queries Postfix does. If a lookup of user@domain has no result, my queries also check for domain, and that value would be returned. So it's possible that 3 simple BDB lookups are going to be beaten by 1-2 complex SQL queries in SQLite. So the question, how fast SQLite is during read operations compared to BDB is still unanswered. Indeed it is not. We need someone to do the testing. :) -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Berkeley DB with Dovecot
On Sun, May 20, 2012 at 08:11:33AM -0400, Jerry wrote: On Sun, 20 May 2012 06:35:46 -0500 Stan Hoeppner articulated: On 5/20/2012 6:19 AM, Jerry wrote: seems like it could potentially be a very useful feature. I have used it myself when a full blown MySQL configuration seemed like over-kill on other small projects. SQLite is the appropriate solution for this scenario. Requires loading another application when it is not necessary. What application in particular? SQLite is a file format, not a daemon. Both Dovecot and Postfix support it well (in the latter case, use at least 2.8.9 or 2.9 due to a bug.) sqlite3(1) is the console client for SQLite. You can use that or any other SQLite client to maintain your database file. My own sordid SQLite mail server howto is linked at the .sig site. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] dovecot smtp authentication with sendmail
On Mon, May 07, 2012 at 10:04:02PM -0400, jeff donovan wrote: On May 7, 2012, at 9:11 PM, Hadi Salem wrote: It’s possible to use sasl dovecot smtp authentication with sendmail ? yes via postfix. Which is to say: no. Sendmail MTA has not implemented Dovecot SASL. Postfix's sendmail(1) binary receives mail via stdin, and does not authenticate. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Authentication process holding open filehandles
On Mon, May 07, 2012 at 10:53:53AM +1000, George Barnett wrote:
We're using dovecot to provide pop3 for a number of mailboxes.
The setup is pretty simple:
I would suggest trying to educate your users to move off of POP3.
Each user / domain has a mailstore in
/data/mailstore/domain/user/Maildir (backed by NFS).
Passwords are in simple passwd-file format in the top level domain
directory eg:
# cat /data/mailstore/foo.com/.passwd
user:{plain}password
The passdb setup looks like this.
passdb {
args = username_format=%n /data/mailstore/%d/.passwd
driver = passwd-file
}
The problem we're having is that when we want to remove a domain
from the system and we go to rm -rf /data/mailstore/domain/ we
are unable to because the auth process is still holding onto the
file handles for the password file.
Can somebody suggest an alternative pattern that I could use for
storing password files? Ideally, we'd avoid one large file to
prevent locking issues and would also keep the passwd-file setup
since it's simple.
SQLite. Learn a bit of SQL, which is not difficult, and it is not
hard to manage. My own little howto, including the schema and a
complete explanation of everything is here:
http://rob0.nodns4.us/howto/
It would be possible to have the password files in a separate dir,
but over time I'm guessing that would lead to nfs turds? Easy to
clean up I suppose, but maybe there's a simpler solution I'm
missing?
--
http://rob0.nodns4.us/ -- system administration and consulting
Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] replication howto
On Mon, Mar 19, 2012 at 09:35:34AM +0100, Michael Grimm wrote: On 15.03.2012 22:05, Timo Sirainen wrote: On 15.3.2012, at 22.48, Michael Grimm wrote: Actually it's a bad idea to use root for ssh from a security point of view. A hacked root account isn't fun. Thus, normally one needs to explicitly change the config of the sshd daemon to to allow root logins (at least with FreeBSD what I'm using). Thus, I do recommend to use an unprivileged user like vmail. Then again it's safer to use system user accounts than a single vmail account that has access to everyone's emails. Root has access to everyone's mail as well. I think you are missing the point, that being: if all your mail are belong to vmail, somebody set up us the bomb if the vmail account is compromised. (Obviously that's true with a root compromise as well, but that is unavoidable. Effects of a root compromise can be limited with technologies like Apparmor and SELinux, but that is difficult to configure properly and only provides limited benefit: compromised root can do everything real root was allowed to do.) The point is: vmail has added a SECOND vulnerable point from which disaster can ensue. If mailbox ownership is distributed among multiple UID/GID, compromise of any one of those only endangers the mails to which it had access. And if you allow ssh login only with public key authentication I don't think there are much security issues. And finally, it would be possible to write a small wrapper that allows the root's public key auth to only execute dsync-user.sh script that can't do anything except sync a specified user's mails. All those safety measures can be applied for the vmail user as well. Actually, that's what I did in my case, plus allowing ssh only between both mail servers (firewall rule). Sure, but there too, all your email eggs are in the vmail basket. No, disaster is not imminent nor even likely to ensue, but the fact stands that you and millions of other virtual-only sites do have this additional potential vulnerability. It is well supported in Dovecot to be able to use a unique UID and GID for every virtual mailbox, but management of such a system presents more challenges than the single-vmail-user approach. Consequently the popular virtual frontends don't support it. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Building Dovecot RHEL RPMs with custom LDAP packages
On Mon, Mar 19, 2012 at 01:20:22PM +0200, Nikolaos Milas wrote: We are (still) mainly using CentOS 5 (5.8 x86_64). As CentOS / RHEL 5 standard OpenLDAP packages are rather old (2.3.x), we've been using LTB OpenLDAP packages (http://ltb-project.org/wiki/download#openldap), which get installed in non-standard file system locations. ISTM that herein lies the whole problem. Why did you not rpmbuild your OpenLDAP? That would have avoided all further fuss. Another observation I can offer, unwelcome as it may be: your OS choice was not a good one when you want the features of recent software. Perhaps you should rethink that choice. You have invested much effort in this task. So, I would like to re-build Dovecot packages based on these OpenLDAP libraries, esp. because I see that dovecot RPM packages are built using OpenLDAP v2.3 libraries. I am not much experienced in building RPMs and preparing spec files. And that is really more a question for a CentOS forum than here. In http://dl.atrpms.net/all/dovecot.spec I see: BuildRequires: openldap-devel, cyrus-sasl-devel The latter requirement seems curious to me. In what way does Dovecot use Cyrus SASL? -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Building Dovecot RHEL RPMs with custom LDAP packages
On Mon, Mar 19, 2012 at 03:47:24PM +0200, Nikolaos Milas wrote: On 19/3/2012 2:32 μμ, /dev/rob0 wrote: ISTM that herein lies the whole problem. Why did you not rpmbuild your OpenLDAP? That would have avoided all further fuss. Thanks for the reply. First, how would I rpmbuild my openldap v2.4.x as a standard CentOS 5 package (i.e. replacing native openldap-2.3.43-25)? If I were more experienced, I could have tried to engineer openldap-2.3.43-25.el5.src.rpm to upgrade the system to use That's what I would have tried. 2.4.x... But still, I haven't seen any OpenLDAP packages attempting to do so, probably because of the tight integration of CentOS with some openldap v2.3 libraries. I don't have anything to tell you there, and I note that we are now fully off-topic. :) I think it's good that third-party packages (even of the same software) give the ability to not mess with standard system. The same is true for reputable Symas OpenLDAP packages. So, I simply use LTB OpenLDAP, even though it's installed at non-standard locations. Failing the SRPM translation, why not just install into the CentOS standard locations? ... oops, I typed too fast ... (This has an added benefit of easy migration. You can setup any/all of those on the same system and decide which one to enable at any time.) So you are in fact using both the CentOS OpenLDAP and your own version? This does not sound good at all. :( Another observation I can offer, unwelcome as it may be: your OS choice was not a good one when you want the features of recent software. Perhaps you should rethink that choice. You have invested much effort in this task. I like CentOS from many aspects as an enterprise server OS. I wouldn't change it. I don't doubt that CentOS/RHEL offers many benefits, but my point here is that in this endeavor you are seeing the drawbacks. Yet, it's important to me to be able to build/combine non-standard packages. Even with CentOS 6, I would still continue to use LTB OpenLDAP for a number of reasons. It's true that I've invested much effort in this task, but mostly because my knowledge on this subject is very basic. And there too, the better forum, with more of the skills you need, would be the CentOS one. :) Note that Dovecot RPM works fine as is (compiled with OpenLDAP 2.3), i.e. there is no real need in re-building it using OpenLDAP 2.4 libs. We just try to make things better (and make our life a bit more difficult) :-) And that is really more a question for a CentOS forum than here. True, but I am hoping that there might be some Dovecot RHEL/CentOS packagers in this list, and that would help resolve issues more effectively, as it is a Dovecot-specific (even if for a package thereof) question. So, any help will be appreciated! The latter requirement seems curious to me. In what way does Dovecot use Cyrus SASL? Hmm, I can't tell. I hope atrpm packager(s), if present on this list, can provide some feedback. I was thinking maybe Timo would know. As far as I can tell it doesn't. I do see in configure.in's check for LDAP, a search for sasl.h or sasl/sasl.h, so it appears that Cyrus SASL might be required to build Dovecot's LDAP support. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] No passdbs specified in configuration file with passdb/userdb in protocol sections
On Mon, Mar 12, 2012 at 12:00:11AM -0400, b...@bitrate.net wrote: the problem with this is that while each of the passdb/userdb configs for the various protocols does indeed work, if a result is not found in one of them, the global passdb appears to then function as a catch-all. how can i tell dovecot it doesn't need a global passdb? each of the protocols' passdb/userdb configs is functioning as desired, but having dovecot look elsewhere upon failure ends up defeating the purpose. A simple workaround: use an empty passwd-file passdb as global. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Multiple locations, 2 servers - planning questions...
On Mon, Feb 27, 2012 at 06:59:14PM +0100, Adam Szpakowski wrote: On 27.02.2012 17:54, Charles Marcus wrote: These two locations will be connected via a private Gb ethernet connection, and each location will have its own internet connection (I think - still waiting on some numbers to present to the owner to see what he wants to do in that regard, but that will be my recommendation), so bandwidth for replication won't be an issue. [cut] I do have a basic question... How many users will be in this new, remote location? Will the traffic be so vast, that 1GbE link will not be enough, or are you using two servers for reliability? The simpler the configuration, it is almost always the better. Maybe you can stay with one server in yours primary location? This was exactly my thought as reading it. If you have some control over client configuration, use offline IMAP, where clients maintain a local copy of what's on the server. (That's a good idea anyway, distributed backups of mail which possibly is important.) -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Why is dovecot involved in my smtp process
On Thu, Feb 23, 2012 at 10:16:34AM -0500, Steve Campbell wrote: I've been trying to get smtp auth set up for days. All my sendmail and sasl2 stuff seems to be proper, but the user can't use the system on port 587, which is where I require authorization. Now I see where messages are in my maillog of the type: auth: pam_unix(dovecot:auth) : authentication failure Why is dovecot involved in my smtp processes and how do I fix this. I would question that these failures are in fact related to what Sendmail is doing. Does Sendmail even support Dovecot SASL? AFAIK it does not, therefore there is no way that Dovecot could possibly interfere with SMTP AUTH in Sendmail. I've got some very mad users. And you are jumping to conclusions. I suggest that you take this matter to a Sendmail forum. When you do, provide all relevant configuration as well as complete logging to show the problem. No useful help is possible with what you posted here. The 10-auth.conf file is pretty much stock except for allowing plain text logins. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Why is dovecot involved in my smtp process
On Thu, Feb 23, 2012 at 12:10:20PM -0500, Steve Campbell wrote: On 2/23/2012 11:33 AM, /dev/rob0 wrote: On Thu, Feb 23, 2012 at 10:16:34AM -0500, Steve Campbell wrote: Why is dovecot involved in my smtp processes and how do I fix this. I would question that these failures are in fact related to what Sendmail is doing. Does Sendmail even support Dovecot SASL? AFAIK it does not, therefore there is no way that Dovecot could possibly interfere with SMTP AUTH in Sendmail. Why is sendmail using Dovecot sasl when I have the regular sasl set up. Fortunately it seems that Peter has identified the issue: Cyrus SASL being configured to use IMAP for authentication. snip In other words, don't use sendmail if I use dovecot? I didn't say that at all, and did not mean to imply it. I'm really having problems following the logic here. Seems that postfix and dovecot are the only way to go if I use alternate ports with smtp auth. Is that what everyone is implying? One thing I *did* say is that what you posted was inadequate to be able to provide real help. And it seems that your issue is only tangentially related to Dovecot. I'll try to see what sendmail guys are saying, but I don't think they'll provide much as long as it involves dovecot. As Peter said, consult the Cyrus SASL documentation. If your SASL will be using IMAP for authentication, you need to ensure that it does so correctly for your Dovecot IMAP. As an alternative, change how Cyrus SASL is configured. The usual suggestion for Sendmail users is to use the same data backend for Cyrus SASL and Dovecot. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
[Dovecot] A Postfix/Dovecot example with SQLite backend [crossposted]
There are many mail howtos on the web ... can one more hurt? http://rob0.nodns4.us/howto/README http://rob0.nodns4.us/howto/ http://rob0.nodns4.us/howto/latest.tar.gz (all files) (Sorry, not HTML yet. That is on the agenda.) This is a multiple address class sample implementation of a Postfix MTA and Dovecot IMAP server using a SQLite3 data backend. Domain lookups, user maps, access and transport maps: all using a single, shared SQLite database file. What, other than the SQLite backend, distinguishes this from other mail system howtos? The Postfix high points include a complete implementation of all address classes and per-address transport(5) maps, virtual(8) UID/GID maps, and smtpd(8) recipient access(5) maps. (The latter is using smtpd_restriction_classes, which are not discussed in detail, but are implemented in an interesting way.) On the Dovecot side, it's mostly standard stuff. The SQL deny userdb implementation, and the seamless integration of system and SQL users, might be interesting. I think the database itself is the best part of this example. It's as close to normalized as I think it can reasonably be. A significant fact is that each revision of the system has tended to simplify the schema. That's a good sign, I think. One central Domain table lists all domains and hostnames to which the server makes reference. Likewise, a central Address table lists all addresses (with a pointer to the Domain table for each record.) The Alias table defines relationships between Address entries. (Both local(8) and virtual(5) alias maps exist in that table.) Comments and suggestions are welcome, on-list if it's topical to whichever list (please don't crosspost unless comments are relevant to both lists), or offlist to the address in the README file (or as detailed below.) Thanks for your interest. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Temporary forbid some users login ?
On Wed, Feb 01, 2012 at 12:55:44PM +0100, Joseba Torre wrote:
El 01/02/12 06:55, Frank Bonnet escribió:
is there a way to forbid SOME ( not all ) users's login with
dovecot 2 ? I need to move their IMAP folders to another place
with more disk space but I don't want to stop dovecot IMAP
service for the other users as the moving process will be a
bit long ( 1 Tb to move )
Take a look to conf.d/auth-deny.conf.ext
You can setup a new passdb (a passwd-file can do it) with deny
= yes, and add/remove users to that passwd-file as needed.
Heh, funny, three different answers in this thread and AFAICT they
are all correct to some extent.
I think the passdb { deny=yes } is the best answer. I implemented
this in SQL using a tri-state active column. Standard active=1
means the MTA accepts mail and the user can login. active=0 will
disable both. The third state, active=-1 has the MTA continuing to
accept mail, but triggers my deny=yes passdb.
--
http://rob0.nodns4.us/ -- system administration and consulting
Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On Tue, Jan 17, 2012 at 12:22:35AM +, Ed W wrote: Note I personally believe there are valid reasons to store plaintext passwords - this seems to cause huge criticism due to the ensuing disaster which can happen if the database is pinched, but it does allow for enhanced security in the password exchange, so ultimately it depends on where your biggest risk lies... Exactly. In any security decision, consider the threat model first. There are too many kneejerk secure ideas in circulation. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] could not start dovecot - unknown section type
On Wednesday 11 January 2012 20:30:49 Daminto Lie wrote: I was wondering if I could get some help with the following error when trying to start dovecot service on Ubuntu Server 10.04. The error message is as follows * Starting IMAP/POP3 mail server dovecot Error: Error in configuration file /usr/local/etc/dovecot/dovecot.conf line 15: Unknown section type Fatal: Invalid configuration in /usr/local/etc/dovecot/dovecot.conf [fail] I have just managed to upgrade it from 1.2.19 to 2.0.17. Then, I tried to start the dovecot by running the command $ sudo /etc/init.d/dovecot start And I received the above message. It would seem that you did not upgrade the init script, and the old one is reading the config file and expecting a different format. You used source to upgrade, which means you did not upgrade in the conventional sense -- you installed new software. Either fix the script or run without it: dovecot start See: http://wiki2.dovecot.org/CompilingSource http://wiki2.dovecot.org/RunningDovecot Below is the configuration for dovecot.conf snip -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
[Dovecot] OT: offlist replies (was: Re: Slackware Dovecot recompile with SSL/TLS question)
On Mon, Aug 15, 2011 at 09:21:22PM -0500, I wrote stuff under this header: Reply-To: dovecot@dovecot.org List mail belongs on the list. The only reason to reply offlist as described below is if specifically requested, or if not relevant to the issue at hand. I have no particular interest in this nor any other problem posted on list unless I have been hired to fix it. I see offlist mail as detailed below in the .sig, but I won't participate in offlist discussions which belong on the list. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: [Dovecot] Slackware Dovecot recompile with SSL/TLS question
On Mon, Aug 15, 2011 at 06:07:37PM -0500, CopalFreak wrote: Slackware 13.1.0 Dovecot 2.0.8 Postfix 2.4.3 That's rather old, BTW. MySQL (virtual users) Spamassassin 3.3.1 ClamAV 0.97.1 (without Amavis) Have wild-card SSL certs and CA from GoDaddy ##postconf -a cyrus dovecot I compiled Dovecot without SASL support and need to re-compile it WITH SASL support, The Subject line says SSL/TLS, and then here you say SASL. I suppose the Subject is correct, right? I don't recall there being options to enable/disable SASL in Dovecot. but I don't want to mess up my existing configuration. (I have it the way I want it as far as where it's installed, where the conf files are located, UID, GID settings, etc.) Dovecot 2.0.13 is out and I would prefer to use the newer version assuming it doesn't have any problems that would prevent me from using it. Is there a way to re-compile (or upgrade) so that it doesn't change any of my existing settings? Did you look at the wiki yet? Upgrading from one minor version to another should be rather simple. Check the NEWS. http://wiki2.dovecot.org/Upgrading http://dovecot.org/doc/NEWS I would like to be able to bring it down, do upgrade, maybe copy some config files over the defaults etc, and bring it all back up within a few minutes instead of a week of tweaking and fixing stuff. Spend some time in advance, and this should be simple. Is there a way to do something like this : stop dovecot No, this is too early in the process. Compile first. backup all dovecot conf files ./configure CPPFLAGS=-I/path/to/openssl LDFLAGS=-L/path/to/openssl --config_dir /etc/dovecot/dovecot.conf (or something like that..not sure what it actually is) make Here's where you'd dovecot stop. sudo make install edit conf files to point to SSL certs Actually you can edit the modular /etc/dovecot/conf.d/10-ssl.conf file ahead of time, then just uncomment the include line at this point. start dovecot IN CASE anything goes wrong, copy old config files back and restart dovecot to make it go back the way it was (only it's using the new 2.0.13 version) any suggestions and/or tips on how-to do this would be greatly appreciated. You might gain some confidence by doing this in a virtual machine and/or chroot in advance. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: [Dovecot] Store quota on passwd-file?? Not work
On Thu, Jul 28, 2011 at 01:37:35AM +0200, Sébastien FOURCADE wrote:
Hello all, I have installed Dovecot 1.2.15 and Postfix 2.7.1 on
my Debian 6.This install no include MySQL, I prefer to store
Password/User in a file... File /etc/dovecot/passwd contains
snip
What is the correct syntax for my file to use a different
per-user quota ? This example not work on my Dovecot
I have no answer for you, having no need for quotas. However, I can
suggest that you consider sqlite as an alternative. You have the
speed and availability of a passwd file, with the added benefit of
having everything fully supported in both Postfix and Dovecot.
I recently upgraded from a setup with a virtual mailbox domain in
passwd file on the Dovecot side. I also had to maintain the
virtual_mailbox_maps for Postfix, a separate file.
Now I have a sqlite database doing both. It is mode 644 root:root,
kept as a hardlink in two directories:
$ ls -ld /etc/{postfix,dovecot}/private
drwxr-x--- 2 root dovecot 4096 Jul 16 00:14 /etc/dovecot/private/
drwxr-x--- 2 root postfix 4096 Jul 27 10:45 /etc/postfix/private/
# ls -l /etc/{postfix,dovecot}/private
/etc/dovecot/private:
total 108
-rw-r--r-- 3 root root 574 Jul 18 00:02 README
-rw-r--r-- 2 root root 54129 Jul 14 17:54 harrier.sqlite.sql
-rw-r--r-- 2 root root 46080 Jul 27 10:45 mail.sqlite
/etc/postfix/private:
total 144
-rw-r--r-- 1 root root 34285 Jul 19 04:40 2011-07-19-dump.sql
-rw-r--r-- 3 root root574 Jul 18 00:02 README
-rw-r--r-- 2 root root 54129 Jul 14 17:54 harrier.sqlite.sql
-rw-r--r-- 2 root root 46080 Jul 27 10:45 mail.sqlite
This keeps sensitive data safe in the absence of a RDBMS' access
control, and everything seems to work fine. I've got a lot in that
little database, including per-domain SMTP restrictions. No reason
you couldn't do a quota in there, and also have Postfix check it as
check_recipient_access before accepting mail.
I would also suggest newer versions of both Postfix and Dovecot, of
course, but AFAIK your 1.2.15 should be good enough.
--
Offlist mail to this address is discarded unless
/dev/rob0 or not-spam is in Subject: header
Re: [Dovecot] virtual users
On Mon, Jul 04, 2011 at 02:58:34PM +0300, Amira Othman wrote: Iam using dovecot-1.0.7-7.el5 and postfix-2.3.3-2.3.el5_6 on centos 5.6 I want to configure mail server without system account .I can send using the virtual account but can't receive and I have this in log file relay=local, delay=0.02, delays=0.02/0/0/0, dsn=5.1.1, status=bounced (unknown user: hoda) This is a Postfix problem, not a Dovecot one. It says that the recipient domain is in this list: mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain ... but the hoda user or alias does not exist in /etc/passwd nor /etc/aliases. See: http://www.postfix.org/VIRTUAL_README.html http://www.postfix.org/ADDRESS_CLASS_README.html The upgrade advice is very good. You should not be starting out with something so long past the end of its support. Follow up on Postfix issues on the Postfix list. However, your issue will probably be solved with some time in the documentation. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: [Dovecot] virtual users
On Mon, Jul 04, 2011 at 09:02:59AM -0500, I wrote: On Mon, Jul 04, 2011 at 02:58:34PM +0300, Amira Othman wrote: Iam using dovecot-1.0.7-7.el5 and postfix-2.3.3-2.3.el5_6 on centos 5.6 I want to configure mail server without system account .I can send using the virtual account but can't receive and I have this in log file relay=local, delay=0.02, delays=0.02/0/0/0, dsn=5.1.1, status=bounced (unknown user: hoda) This is a Postfix problem, not a Dovecot one. It says that the recipient domain is in this list: mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain ... but the hoda user or alias does not exist in /etc/passwd nor /etc/aliases. See: http://www.postfix.org/VIRTUAL_README.html http://www.postfix.org/ADDRESS_CLASS_README.html This list should also include: http://www.postfix.org/BASIC_CONFIGURATION_README.html because mydestination, myhostname, and mydomain settings are covered therein. The upgrade advice is very good. You should not be starting out with something so long past the end of its support. Follow up on Postfix issues on the Postfix list. However, your issue will probably be solved with some time in the documentation. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: [Dovecot] integrating procmail
On Wed, May 18, 2011 at 03:20:08PM -0700, errno wrote: On Wednesday, May 18, 2011 03:07:44 PM Jerry wrote: On Wed, 18 May 2011 14:50:54 -0700 errno er...@cox.net articulated: Below, I've provide the relevant snippets of my current functional configuration; how best to integrate procmail into the mix? Why procmail? Use sieve instead. It is fully supported in Dovecot and IMHO far easier to use. I hear you, and agree - I was able to determine that sieve was better supported. Unfortunately, I'm doing this for a client who is rather set in his ways and already has a largish custom procmail filter he wants/needs to use. For me to tell him, no we need to use sieve instead, he will see that as a failure on my part; and/or will request that I install and configure a different combination of software that will facilitate his familiar territory of procmail. Seeing as I already have postfix and dovecot functioning, I'd rather just get procmail in there and be done with it; is this possible? This is all on the Postfix side. Leave Dovecot out of it. And it's trivial. main.cf: mydestination = localhost, localhost.$mydomain[, ... ] virtual_alias_maps = (set to something) virtual_alias_maps includes this: real@email.address setnways@localhost Create a Unix user, setnways. ~setnways/.forward: |/path/to/procmail Populate ~setnways/.procmailrc as desired. Obviously this won't work if you have disabled local(8) delivery. Note: I set reply-to this list, but it would be more appropriate on postfix-users. Start a new thread there if you need help. See also: http://www.postfix.org/virtual.5.html http://www.postfix.org/aliases.5.html http://www.postfix.org/local.8.html And your OS documentation if needed. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: [Dovecot] is reverse dns down ?
On Mon, May 02, 2011 at 10:30:44PM +1100, Voytek Eymont wrote: Hi guys, is that a genuine email from the list, I'm getting it rejected as it's missing reverse hostname: May 2 21:21:41 postfix/smtpd[18033]: NOQUEUE: reject: RCPT from unknown[194.89.34.45]: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [194.89.34.45]; from=dovecot-boun...@dovecot.org to=voy...@sbt.net.au proto=ESMTP helo=mkentta.iki.fi # host mkentta.iki.fi mkentta.iki.fi has address 194.89.34.45 mkentta.iki.fi mail is handled by 10 mkentta.iki.fi. mkentta.iki.fi mail is handled by 100 smtp.menturagroup.com. # host 194.89.34.45 Host 45.34.89.194.in-addr.arpa. not found: 3(NXDOMAIN) We discussed this the other day under Timo's thread about dovecot.org. It seems that ns.ripe.net., one of the NS hosts for 89.194.in-addr.arpa., is not returning the PTR for 45.34.89.194.in-addr.arpa. AFAICS the other NS hosts seem to be working fine, but if your resolver was unlucky enough to hit ns.ripe.net., you have a host with no PTR. It's like Russian roulette with rDNS. I suspect it might be a casualty of DNSSEC, but I get the same noerror response when querying with +dnssec and +nodnssec. At this point those who use the normally safe and reasonable reject_unknown_reverse_client_hostname restriction should consider whitelisting mkentta.iki.fi[194.89.34.45] in the MTA. And Timo needs to scream louder at the ISP. ;) -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: [Dovecot] dovecot.org mirrors?
On Fri, Apr 29, 2011 at 08:10:45PM +0300, Timo Sirainen wrote: The mirroring setup is finished. There's a master server now handling dovecot.org and a mirror server handling www/hg/wiki. Would be nice to get another reliable fast mirror server if someone wants to donate one :) Requirements are: - Apache2 with WSGI - Mercurial - Patched moinmoin - ssh + rsync so I can push changes immediately I think I had offered you a mirror and/or DNS slaves in the past. ATM we can't manage the Mercurial and moinmoin, but that might change in the near future. I can still offer you two DNS slaves, if you're interested in that, but there are other free/gratis services available which can do that quite well. BTW. Apparently there's still something wrong with dovecot.org's reverse DNS record. It appears to be ok, but some DNS servers have cached it wrong. I don't know why. We've complained to the ISP. Sounds like the TTL was too long before a change was made. Also dovecot.org is currently sharing IP with some other stuff, but should get its own IP some day. dovecot.org.3600IN A 194.89.34.45 45.34.89.194.in-addr.arpa. 86400 IN PTR mkentta.iki.fi. mkentta.iki.fi. 86400 IN A 194.89.34.45 Looks fine, although the PTR is mkentta.iki.fi. and not dovecot.org. I'd use mkentta.iki.fi as the HELO name if sending mail from there, but that shouldn't be much of a problem. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: [Dovecot] dovecot created mailbox empty - all mail forwarded to main MX server and cyrus-dovecot conflict
On Sat, Jul 03, 2010 at 08:36:03PM +0800, Hans Neukomm wrote: after lots of trial and error and the help of THIS mail list, FWIW this one is posted on the wrong list; this one's a Postfix issue. Your hint for that should have been to see that the logs demonstrating the problem were entirely from Postfix. finally my dovecot-postfix combination seems to work yet the dovecot mail spool always is empty all mail forwarded to my main mail server - but i have no mail relay configured. why is the mail NOT in the dovecot inbox but forwarded to another mail server ?? Because the kriyayoga host does not know it's supposed to be the final destination for kriyayoga.com. Anything not recognized as a locally-hosted destination will be routed as per DNS lookup. http://www.postfix.org/ADDRESS_CLASS_README.html http://www.postfix.org/VIRTUAL_README.html and why does postconf -A show cyrus and NOT dovecot ?? Irrelevant to your issue, this is normal. Dovecot does not have a client SASL implementation. below some relevant config data. my goal is to have a clean simple dovecot+postfix mail system with nothing else (cyrus or so) involved when ever possible. -- DNS MX stuff dig mx kriyayoga.com ;; ANSWER SECTION: kriyayoga.com. 3600IN MX 10 smtp.kriyayoga.com. kriyayoga.com. 3600IN MX 0 mail.kriyayoga.com. The dual MX is usually not a good idea. To do it right is far from simple. Your lower priority MX host will be a spam magnet. the new dovecot setup is tested on smtp.kriyayoga.com and when successfully working shall be used on both mail MX servers. Two mailstores? Again, this is not simple to set up. -- postfix stuff relevant to dovecot postconf -A cyrus postconf -a cyrus dovecot my postconf -n shows nothing about cyrus in the config NOR anything about mail-relay to my main MX relayhost = mailbox_transport = mailbox_command = Those all being default settings, they do not belong in main.cf. smtpd_sasl_type = dovecot virtual_transport = dovecot -- below the mail log for sending mail to my dovecot box Jul 3 20:31:08 kriyayoga postfix/smtpd[27801]: connect from unknown[124.108.51.96] Jul 3 20:31:08 kriyayoga dovecot: auth(default): new auth connection: pid=27801 Jul 3 20:31:09 kriyayoga dovecot: auth(default): client in: AUTH#0111#011PLAIN#011service=smtp#011nologin#011lip=78.46.101.111#011rip=124.108.51.96#011resp=aGFucwBoYW5zAEk4Q3Nhd084MUR4Y1JlTTh1QmgwTA== Jul 3 20:31:09 kriyayoga dovecot: auth(default): passwd-file(hans,124.108.51.96): lookup: user=hans file=/etc/dovecot/passwd Jul 3 20:31:09 kriyayoga dovecot: auth(default): client out: OK#0111#011user=hans Okay, those are Dovecot logs, but not entirely relevant to the problem. The user hans authenticated successfully and is being permitted to relay to an external domain, kriyayoga.com. Jul 3 20:31:09 kriyayoga postfix/smtpd[27801]: BC90129D9F: client=unknown[124.108.51.96], sasl_method=PLAIN, sasl_username=hans Jul 3 20:31:10 kriyayoga postfix/cleanup[27807]: BC90129D9F: message-id=201007032031.07830.h...@kriyayoga.com Jul 3 20:31:10 kriyayoga postfix/qmgr[14627]: BC90129D9F: from=h...@kriyayoga.com, size=1287, nrcpt=2 (queue active) Jul 3 20:31:10 kriyayoga postfix/smtp[27808]: BC90129D9F: to=h...@kriyayoga.com, relay=mail.kriyayoga.com[88.198.14.45]:25, delay=0.95, delays=0.5/0.01/0.17/0.26, dsn=2.0.0, status=sent (250 Ok: queued as 97FCE138024) Jul 3 20:31:10 kriyayoga postfix/smtp[27808]: BC90129D9F: to=h...@kriyayoga.com, relay=mail.kriyayoga.com[88.198.14.45]:25, delay=0.95, delays=0.5/0.01/0.17/0.26, dsn=2.0.0, status=sent (250 Ok: queued as 97FCE138024) According to the MX records you posted, mail.kriyayoga.com. is the highest priority (0) MX host for kriyayoga.com. So the rest of the non-spamming world is going to send all kriyayoga.com. mail there as well. Jul 3 20:31:10 kriyayoga postfix/qmgr[14627]: BC90129D9F: removed at this point the mail is gone already - NO mail in my dovecot inbox - NO error - just automatically relayed to my main MX If you need to followup on this to the Postfix list, see: http://www.postfix.org/DEBUG_README.html#mail -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
[Dovecot] system v. virtual mailboxes, was Re: Thunderbird problem
On Tue, Jun 29, 2010 at 07:28:52AM -0400, Charles Marcus wrote: On 2010-06-28 9:05 PM, Stan Hoeppner wrote: I guess this is different with virtual users than with system users? Are you using virtual or system users Charles? Virtual of course... doesn't everyone? ;) Virtual mailboxes have their place, of course, but they're overused, especially at small sites. I suppose this might be in part because most HOWTOs are for virtual. I recently saw someone asking for help, having set up a simple server with virtual mailbox (yes, singular) and mysql! The querent was trying to add a SECOND account and did not know how! I started into mail on a very small scale, and that approach served me well. I set up Postfix by reading the comments in main.cf; later when I got the idea that I might want POP3 or IMAP, I uncommented lines in inetd.conf (popa3d I think, and uw-imap), and they worked. When kids got old enough to use email, adduser[1] and there they go. I didn't get into virtual mailboxes until later, on a job, and when I did, I knew enough to question the wisdom of it. Why did we need this additional authentication database? All our users were using Samba via system accounts too. It could have been all integrated! The advantages I was told of doing it the virtual way were all based on misunderstandings. (One common one: I don't want mail users to have shell access. Giving them a shell of /bin/false and/or setting sshd_config(5) access controls does the job.) I think many if not most of the questions we see on these lists are from people who have made a bad choice of using virtual mailboxes, often as a direct consequence of that choice. Email grew up with Unix, so it's no accident that Unix shell usage has very nice integration with email. Probably a lot of the folks reading this list would not even need an IMAPd if they knew more about these things. I often encounter frustrated newbies who tried to do the whole thing all at once. It makes much more sense to start off small, throw in the relational databases later, learning the finer points of how to manage your OS along the way. The secret is that you can have a fully-functional mail server with very little bother, using system accounts. Postfix (or other MTA) and Dovecot will pretty much Just Work, right out of the box. [1] adduser is a Slackware-specific frontend wrapper script for useradd(8) and other tools from the shadow package. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: [Dovecot] Ok, I've given up
On Wed, Jun 16, 2010 at 10:59:55PM -0700, Chuck McManis wrote:
In the interest of moving forward on this project
I looked back at your other thread and at this one, and, hmmm. I
invite you to join us in the new millennium.
1. POP3 sucks.
IMAP can do everything POP3 can do, and many things POP3 cannot.
Check it out, and you will want to give up POP3.
2. mbox sucks, mostly.
Mostly; mbox is slightly better for POP retrieve-and-delete usage,
but there, see #1 above. Maildir gives the administrator, and a
shell user, many options.
2a. mutt and alpine are both Unix console-based MUAs which
understand maildir *and* IMAP. I'm using mutt with IMAP,
because it has advantages over direct maildir access.
3. qmail is dead.
Over ten years without any coordinated development, five years
since the last (only?) netqmail release. Email has changed a lot
in those years, and yes, you can patch qmail to get most of the
functionality of a modern MTA, but IME that was a crapshoot. Why
fight it, when other, well-maintained, featureful MTA choices
exist?
3a. qmail is both much more vulnerable to spam AND by default,
the source of much spam.
I've given up trying to
get Dovecot to support mailboxes, rather I've tweaked around in qmail and
had it deliver into a mail directory on a disk, that isn't NFS mounted. That
got me past the various locking complaints and operation not supported on
home directories that were mounted from the NetApp filer.
Going as vanilla as possible I've managed to both send an email that qmail
delivered and fetch the email with my 3 test clients (Eudora, Thunderbird,
and Evolution) (I know they are, in a sense, all variations on a theme but
MUA monoculture seems to be inevitable these days).
So a few questions for the other esteemed system operators here if you know
the answer I'd love to hear it.
Question 1) Are my user's passwords safe from prying eyes?
Not enough information provided to be able to answer that.
First, part of this effort was to move off of an APOP infrastructure into
something more secure against password eavesdropping. To that end I've
configured Dovecot with simply:
protocols = pop3
service pop3-login {
inet_listener pop3s {
port = 995
ssl = yes
}
}
Note that there is NO port = 110 listener and yet Dovecot seems to listen
You would want to find out WHAT is listening on 110. Tools like
netstat(8) (8 in Linux, probably section 1 in BSD) are useful.
there anyway. My question, can I be sure that it is not accepting non-SSL
based connections? Attempts to use plaintext on 110 were rebuffed so that
seems to be the case. My intent is that if my user is using this in an
airport they won't give away their email password to a bad guy who is
sniffing all the packets.
Question 2) Is there any way to run dovecot from tcpserver ?
One of the things I like is the program tcpserver. I like it because I can
simply not allow large chunks of the internet to connect at all to certain
Yeah, Wietse wrote a similar program back in that era too, TCP
wrappers. Similarly, it was abandoned. Most Unix and Unix-like
operating systems have the ability to do packet filtering which is
more powerful and more flexible.
ports. (I use this for SSH in particular since all the kids love throwing
dictionary attacks around). I'd like to give my POP3 ports equivalent
protection. I also like the logging facilities of the supervise / multilog
service.
To use this I'd need Dovecot to accept the connection handed to it, and not
do the whole setsid daemon thing since tcpserver will start another one if
needed. I can send the logging out to stderr (thanks!) and get the logging
There's another DJB-ism that I don't care for; syslog(3)/syslogd(8)
works well. Those TAI64N timestamps are a pain.
stuff but still wondering about the 'hand you a connection.'
--
Offlist mail to this address is discarded unless
/dev/rob0 or not-spam is in Subject: header
Re: [Dovecot] Mailing list's prefix
On Fri, Mar 05, 2010 at 12:45:45AM +0200, Timo Sirainen wrote: On 4.3.2010, at 22.59, Timo Sirainen wrote: Do you think I'd break a lot of people's filters if I removed the prefix? :) Anyone strongly for/against removing it? It seems kind of annoying to me whenever I happen to think about it. Well, it's beginning to sound like there are non-filtering reasons why the prefix can be good. So I guess it's better to keep things the way they are now :) Hrm. I guess I'm too late for the voting, then. I use tagged addresses (envelope recipient) to control routing into folders. I would like to see the prefix go away. (I know it doesn't look like it, because I use this same address as posting address on numerous mailing lists. But I generally set it NOMAIL after subscribing, and I read through a different address.) -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: [Dovecot] Moving
On Mon, Jan 11, 2010 at 09:02:25AM -0500, Stewart Dean wrote: My apologies for posting this to the list; I meant to send it Timo only Now that you're back in your native land. . If and only if you're interested, I'D be interested in hearing what you thought of America Nonetheless, it would be interesting to see his reply, maybe as a blog entry link or something. :) -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: [Dovecot] Mail root to root and permissions problem
On Tue, Dec 15, 2009 at 02:11:28PM +0100, Benny Pedersen wrote:
On tir 15 dec 2009 11:41:41 CET, Steffen Kaiser wrote
On Tue, 15 Dec 2009, Antonello Onida wrote:
error
ex: from r...@* to r...@*.
Command output: Can't open log file /var/log/dovecot.log: Permission denied
/error
Operations like dovecot: 2009-12-15 11:17:24 Warning: Killed
with signal 15 are writen.
It's a permission problem: dovecot.log is owned by root and
grupped by adm (chmodded 640).
At first shot (if you would always get the error), I would say,
you use system users and those users must not write to the log
file.
Add write-permission for all (chmod a+w) or reconfigure Dovecot to
let deliver use syslog:
protocol lda {
...
# Log to syslog
log_path =
info_log_path =
syslog_facility = mail
}
or more simple :)
mkdir -p /var/log/dovecot
chown dovecot /var/log/dovecot
# chgrp mail /var/log/dovecot
configure global dovecot to use logdir as /var/log/dovecot
rule to remember is permissons got the parent permissions, and this
is why it fails above
please correct me if i am wrong
I think you might be. The OP has not presented complete information,
but my guess is that deliver(1) is being invoked by postfix/local(8),
which refuses to run processes as root. Instead, $default_privs (see
postconf(5)) is used. root should be aliased to a non-root user.
I'm not clear on why other mail is apparently able to open and write
the Dovecot log, but I'm pretty sure that the syslog approach would
work. So would a+w, ugly though it is.
I'm not sure about your idea. Yes, *if* deliver runs as dovecot:mail
it should work. But lacking information, we don't really know. My
advice to OP:
1. Check aliases(5), ensure that root: youru...@localhost is
present. (Also assumes that localhost, localhost.$mydomain are
both listed in $mydestination and that youruser is a valid
system account.)
2. Using syslog is a good idea anyway, rather than having each
deliver to open, lock, and write the logfile.
3. If problem persists, complete postconf -n ; dovecot -n
output and all logging (non-verbose) for a single delivery
should be provided, so we don't have to guess.
--
Offlist mail to this address is discarded unless
/dev/rob0 or not-spam is in Subject: header
Re: [Dovecot] SASL plain authentication failed; unable to lookup user record
On Wed, Dec 09, 2009 at 11:21:56AM -0800, JP wrote: i'll guess the solution to my problem will be something simple and obvious, I think so. [snip] config stuff: # postconf -n mail_owner = _postfix That strange non-default setting might be one of the problems. queue_directory = /private/var/spool/postfix That's equally strange and also a likely part of the problem. smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated reject This is not suitable for mail exchange, and not needed anyway. This says you reject anything which has not authenticated or is not in mynetworrks. smtpd_helo_restrictions = reject_invalid_helo_hostname reject_non_fqdn_helo_hostname These are good restrictions to use, but they will block some MUA submission. They belong __ | below v smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks reject_unauth_destination check_policy_service unix:private/policy reject in here after the two permit_* restrictions. smtpd_pw_server_security_options = plain, login cram-md5 smtpd_use_pw_server = yes postconf: warning: smtpd_pw_server_security_options: unknown parameter postconf: warning: smtpd_use_pw_server: unknown parameter This is patched. Talk to Apple for support. The patching could be a part of the problem as well. smtpd_sasl_path = private/auth This pathname, as documented, is relative to $queue_directory. See above for your strange non-default setting. virtual_mailbox_base = /etc/postfix/datastore This is really bizarre. Sure, files can go anywhere you want, but is there anything wrong with traditional Unix standards? I'm reminded of the famous quote: Those who don't understand Unix are doomed to reinvent it, poorly. # dovecotd -n # 1.1.17apple0.5: /private/etc/dovecot/dovecot.conf Warning: fd limit 256 is lower than what Dovecot can use under full load (more than 456). Either grow the limit or change login_max_processes_count and max_mail_processes settings Hmmm, that sounds like something you might want to consider. auth default: verbose: yes debug: yes debug_passwords: yes passdb: driver: passwd-file args: username_format=%n /etc/postfix/datastore/%d-passwd userdb: driver: passwd-file args: username_format=%n /etc/postfix/datastore/%d-passwd socket: type: listen client: path: /var/spool/postfix/private/auth I see a problem in that path! mode: 432 user: postfix group: postfix I see a problem in that user (and maybe group)! it would seem that something's not right between postfix and dovecot. Perhaps Dovecot should create a socket in the place Postfix needs it, with ownership such that Postfix can use it. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: [Dovecot] SASL plain authentication failed; unable to lookup user record
JP dove...@dovecot.exjay.com I'm sorry I offended you, but I really do not understand how you found condescension in my reply. I could explain some things, but I have better things to do. Please help me ensure that I never offend you again by adding me to your ignore list or killfile. Thank you. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: [Dovecot] virtual domains and SSL certificates
On Sun, Dec 06, 2009 at 04:23:36PM +, Dick Middleton wrote: I bring it up again because I've just been trying the release candidate for Thunderbird 3. This has a config wizard which derives from ones email address the mail server address etc. It doesn't handle SSL virtual mail servers very well because of this problem. I'd consider that a bug in the wizard, wouldn't you? I have encountered a web server called Cherokee (http://www.cherokee-project.com) which has virtual server capability that *demands* a different certificate for each virtual server. How can that be I thought? This is what Cherokee documentation says: [snip] Cherokee supports the clean and standard method of dealing with this issue called Server Name Indication (SNI) that sends the name of the virtual host during the TLS negotiation. If SNI is supported by your SSL/TLS library, the SSL layer does not need to be restarted. Since the host info can be put in the SSL handshake, things will simply work as long as there is a web browser with SNI support at the other side. Currently every modern web browser supports this, and Cherokee has TLS SNI support for the OpenSSL backends. Note that for SNI to work, client support is required. Web browsers known to support it are Mozilla Firefox 2.0+, Opera 8.0+, Internet Explorer 7 (Vista, not XP) or later and Google Chrome. /QUOTE If Cherokee can do it why not dovecot? Is this something that is, or could be, being considered? It does assume that TB3 and other mail clients support SNI but whatever, I suspect that once TB3 is released the subject will pop-up more frequently. It also assumes that the IMAP protocol has SNI support. IMAP != HTTP. I don't know, but my thought is don't hold your breath. Consider TLS in IMAP and SMTP. The protocols were years ahead of the clients. Even now we see lots of issues with MUAs with inadequate (or NO) TLS support. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: [Dovecot] new to dovecot
On Tue, Nov 24, 2009 at 10:25:22PM +0100, Lars Nielsen wrote: I have installed debian with exim4 postgresql 8.3 and dovecot 1.0.15. I have the mail delivery part done, so when i send mail it gets delivered in ~/MailDir/ -^ D mail_location: maildir:~/Maildir ---^ d D is not d. You want to have the MTA/LDA deliver to the same location where Dovecot expects to read mail. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: [Dovecot] Newbee, some questions
On Sun, Nov 22, 2009 at 01:55:22PM -0500, Thomas Harold wrote: We used Postfix only for a long time (SMTP/POP3), ... Um, no, Postfix does not serve POP3. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
