Re: [Dovecot] Ok, I've given up
On Thu, Jun 17, 2010 at 9:26 AM, Charles Marcus wrote: > On 2010-06-17 11:52 AM, Chuck McManis wrote: > > but I've been evaluating a ZFS based file server as well to see if it > > can get the same level of reliability. > > Care to share which one? Or just a FreeBSD based one of your own making? > Its just a FreeBSD 8.0 system with a Marvell 8 port SATA card and a couple of TB of of SATA drives. I configured ZFS pretty much with all the default knobs. One of my SATA "drives" is actually outside the box so that I can turn it off to introduce a "failed drive" to the system to evaluate error handling and recovery. I've been considering NexentaStor Comunity Edition. The boss doesn't > like spending money, and we don't really *need* anything super fancy, > but I really like what I hear about ZFS... > For most NAS stuff so far it seems pretty reasonable. Its both not as space efficient and better than the NetApp in terms of total available space becaus the NetApp box lops off like 65GB of every drive in a combination of 'right sizing' and reserving space. ZFS uses the whole drive but has ginormously fat metadata blocks that it mirrors a lot. The Netapp box out performs it in terms of both bulk transfers and IOPs but I've done practically no tuning on the ZFS system. --Chuck > > -- > > Best regards, > > Charles >
Re: [Dovecot] Ok, I've given up
Thanks for the response, some snippage to cut down on list traffic ... On Thu, Jun 17, 2010 at 7:14 AM, /dev/rob0 wrote: > > On Thu, Jun 17, 2010 at 12:20 AM, /dev/rob0 wrote: > > > 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. > > You didn't have any comment on the above; I hope those suggestions > were useful. > Absolutely, I pulled the mutt packages and built it and played around with it. Its very nice. It will work better than doing a maildir2mbox before running, thanks for that. > > So SMTP hasn't changed much in 30 years ;-) I'd be interested in > > what you consider a 'modern' MTA. > > One that supports many/most ESMTP features without patching (so, > netqmail, "Last modified: Wed Feb 2 23:37:31 EST 2005", can be > considered "without patching".) > I actually have the equivalent of a netqmail++. We had used it at FreeGate and I became pretty comfortable in the source base so its what I'm familiar with. > RFCs 5321 & 5322 were released in 2008. Various ESMTP extensions > which are in common use came after the end of qmail development. > Fair point. > Spammers are working every day to cause more abuse. Postmasters are > trying to stay ahead of them, but we still see that over 90% of all > traffic to port 25/tcp is abuse. > Yup. (well 73% in my case but I've got a small domain off in an unused corner of the universe) > I've looked pretty thoroughly at sendmail, postfix, > > and qmail and of the three qmail is fairly reliable. > > Perhaps it is. Does it do what you need? You mentioned wanting to > protect users' passwords. STARTTLS and AUTH are not supported by > qmail without patching, and I wouldn't be so confident in those > patches, if I was running qmail. > This is true, although as I've said I'm pretty comfortable around Dan's source code (even if I abhor his coding style). > Good. You might also want to consider zen.spamhaus.org. I find that > rejecting non-FQDN HELO names will stop around 25% of all connections > I get, but perhaps if you've maintained your tcpserver access lists > well, you're not getting as many of those. If not, you're lucky, > because here too, qmail has no native ability to perform access > checks based on the HELO/EHLO name. > I've gone back and forth on FQDN bouncing. I used to reject it out of hand (if you're using tcpserver you can use it to pass along a signal that the IP and name don't match, and then in qmail you can compare the HELO name with the $REMOTEHOST value to bounce (or spike) on mismatch)). But enough people seem to screw this up but be legitimate that I've switching to using it as a strong signal to the spam classifier as 'likely spam'. I've got the equivalent of the 'fail2ban' utility which auto-blocks any address which sends an obvious spam (non-address for example) > The qmail design of accept-then-bounce is thoroughly discredited. I > hosted a domain which didn't have email, and 90% of my logs were > backscattering qmail woodpeckers coming back again and again after > "554 5.7.1 : Relay access denied ..." > I've always considered the accept-then- and the was pretty configurable. I just spike (aka send to /dev/null) and ban (update the tcpserver rules). About 8 years ago I was still helpfully bouncing stuff until I added up how much b/w I was consuming by sending bounces to folks who didn't send the email in the first place and stopped doing that. Which is a long way of saying I agree with you that accept-and-bounce isn't a useful policy for MTAs > Software written in the 1990s and no longer maintained, I call > abandoned. > Ok, but generally the patches for qmail have been feature patches, not bug fixes it seems. I can accept your definition of abandoned as software that doesn't get changed by the author and there is no official maintainer of a version. > [snip] > > Sure, who can resist questions like these? :) > > > Provide a system that gives shell and email service to a dozen > > users, hosts perhaps 15 or so mailing lists, provides DNS for 20 - > > 30 machines. > > "Provides DNS for ..." meaning, it is the "nameserver" host for these > 20-30 clients? > Yes, name resolution and a name cache for the folks on the network. > > Preferred OS and what makes it the one you choose? > > Familiarity. Most of my Unix admin time has been done in Slackware > Linux. I like the simplicity and the ease of management. Any Unix or > GNU/Linux can do the job ... the admin's personal preference and > experience is what matters. > Fair enough, I tend to land on FreeBSD for server software and Ubuntu/Gentoo for desktop. > Preferred MTA and what makes it the one you choose? > > I spent my time to become proficient in Postfix. I think Sendmail > and Exim are also good choices. > After your message I went hunting for 'state of the art' MTAs, it seems sendmail, postfix, qmail, and ex
Re: [Dovecot] Ok, I've given up
Thanks Timo.
--Chuck
On Thu, Jun 17, 2010 at 4:34 AM, Timo Sirainen wrote:
> On 17.6.2010, at 6.59, Chuck McManis wrote:
>
> > 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
> > there anyway.
>
> Yes, it's doing that by default. If you want to disable it, use
>
> service pop3-login {
> inet_listener pop3 {
>port = 0
> }
> }
>
> > My question, can I be sure that it is not accepting non-SSL
> > based connections?
>
> disable_plaintext_auth = yes is also default, so it won't allow users to
> log in via non-SSL anyway (with 110 port it requires starttls). Of course,
> this might not prevent some clients from trying to send the password anyway.
>
> > Question 2) Is there any way to run dovecot from tcpserver ?
>
> v1.x yes (but there have been some problems), v2.0 no.
>
> > 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
> > ports.
>
> v2.0 supports tcpwrappers if that helps.
Re: [Dovecot] Ok, I've given up
On Thu, Jun 17, 2010 at 12:20 AM, /dev/rob0 wrote:
> 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.
>
So SMTP hasn't changed much in 30 years ;-) I'd be interested in what you
consider a 'modern' MTA. I've looked pretty thoroughly at sendmail, postfix,
and qmail and of the three qmail is fairly reliable. Not sure what makes a
particular MTA more 'vulnerable' to spam. I don't run an open relay and I
generally find barracuda central a decent rbl source. Between that and using
tcpserver to simply not accept connections from zombies spam hasn't really
been an issue.
>
> > 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.
>
Actually I know its dovecot that opens 110. I see it in netstat and I've got
lsof to tell me that its being held open by the pop3 process:
dovecot 82197 root 15uIPv4 0xc435d4f00t0 TCP
*:pop3 (LISTEN)
I'm not new to system administration mind you, just new to using dovecot.
And looking through tcpdump logs of what the clients send and vs what
dovecot responds, basically it is listening too, and refusing to answer, any
requests on 110. So it seems like we should be able to have it not listen
there. From watching the packets I've managed to convince myself that
dovecot is only allowing SSL connections to go through authentication. But
if there is a vulnerability in its pop3 code I worry about someone getting
squirrelly with the 110 port, hence my desire to just have it not listen
there at all.
> 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
>
[Dovecot] Ok with a bit more wiki reading ...
So if I want to run dovecot from tcpserver it seems like I can simply run `pop3-login --ssl` from tcpserver (its sort of like running it from inetd) and it says it will 'talk to dovecot'. Can I disable all listeners in dovecot then? Will is still talk to it? Trying some experiments now ... --Chuck
[Dovecot] Ok, I've given up
Sigh,
In the interest of moving forward on this project 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?
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
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
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
stuff but still wondering about the 'hand you a connection.'
--Chuck
Re: [Dovecot] New admin, not much success
On Wed, Jun 16, 2010 at 9:19 AM, William Blunn > wrote: > [snip]... . With Maildir, everything works out-of-the-box with no > configuration without breaking a sweat; mailbox corruption is simply > designed-out. > > Bill > I may end up and go back to a maildir implementation, that would at least change my problem from "POP3 server that understands SSL and mbox" to "command line MUA that understands Maildir" ;-) --Chuck
Re: [Dovecot] New admin, not much success
On Wed, Jun 16, 2010 at 8:53 AM, Timo Sirainen wrote: > On Wed, 2010-06-16 at 08:46 -0700, Chuck McManis wrote: > > (random 2.0 bug report, unless you set info_log_path > > in conf.d/10-logging the additonal information doesn't come out) > > With or without setting log_path? If you didn't set log_path, it goes to > syslog and maybe to a different file (or maybe syslog loses it > completely). "doveadm log find" might find where it goes. > > Without setting log_path. Its possible that my syslog setup is just tossing info messages sent to the MAIL facility, I'll check that a bit later. The debug stuff seems to land in /var/log/debug.log by default.
Re: [Dovecot] New admin, not much success
On Wed, Jun 16, 2010 at 8:44 AM, William Blunn > wrote: > Timo Sirainen wrote: > >> On Wed, 2010-06-16 at 08:28 -0700, Chuck McManis wrote: >> >> >>> Jun 16 08:22:07 eeebox dovecot: pop3(cmcmanis): Error: user cmcmanis: >>> Initialization failed: Initializing mail storage from mail_location >>> setting >>> failed: mbox: mbox root directory can't be a file: /home/cmcmanis/Mailbox >>> ( >>> http://wiki.dovecot.org/MailLocation/Mbox) >>> >> .. >> >> >> >>> Now it strikes me that this message indicates that Dovecot is confused >>> about >>> how mail is delivered on my system and is looking for a Maildir >>> implementation when I"m using single files. >>> >>> >> >> No, it's looking for a directory containing mbox files. See the wiki URL >> and "Only /var/mail/ mboxes" section in it. >> > > One wonders if Chuck's stated requirement may be reasonably served by > something like this: > > mail_location = mbox:~/mail:INBOX=~/Mailbox > > and create a directory "mail" in each user's home directory. > > This should then make Dovecot consider each user's INBOX to be an > mbox-format file at "~/Mailbox", and also allows Dovecot to keep indexes in > the directory "~/mail", thereby enabling Chuck's users to take advantage of > Dovecot's indexing functionality. > > Fascinating, that gets it further, it creates a bunch of stuff in mail/.imap (which is confusing because I really really don't want IMAP and have removed IMAP from the protocols served and the ports listened on etc) Then it complains that it can't do an fcntl on Mailbox. It said 'operation not supported.' --Chuck > Bill >
Re: [Dovecot] New admin, not much success
On Wed, Jun 16, 2010 at 8:31 AM, Timo Sirainen wrote: > On Wed, 2010-06-16 at 08:28 -0700, Chuck McManis wrote: > > > > Jun 16 08:22:07 eeebox dovecot: pop3(cmcmanis): Error: user cmcmanis: > > Initialization failed: Initializing mail storage from mail_location > setting > > failed: mbox: mbox root directory can't be a file: /home/cmcmanis/Mailbox > ( > > http://wiki.dovecot.org/MailLocation/Mbox) > .. > > > > > Now it strikes me that this message indicates that Dovecot is confused > about > > how mail is delivered on my system and is looking for a Maildir > > implementation when I"m using single files. > > No, it's looking for a directory containing mbox files. See the wiki URL > and "Only /var/mail/ mboxes" section in it. > > Thanks Timo, I've read that wiki page a few times, and adding INDEX=MEMORY hasn't changed things. (random 2.0 bug report, unless you set info_log_path in conf.d/10-logging the additonal information doesn't come out) I suspect its that I'm trying to do everything in a single file, from qmail delivering mail there, to dovecot pulling out messages for users. (I did that to manage storage controls). Reading the qmail/LDA page it seems like dovecot really wants me to have qmail deliver into an 'inbox' file and then to transfer email from that file into the local directory 'mbox' file while it works. --Chuck
Re: [Dovecot] New admin, not much success
On Wed, Jun 16, 2010 at 6:35 AM, Pascal Volk <
user+dove...@localhost.localdomain.org
> wrote:
> On 06/16/2010 07:26 AM Chuck McManis wrote:
> > …
> > I've got qmail delivering into a file named 'Mailbox' in user's home
> > directories.
>^^^
> > …
> > So, I can't get dovecot to work at all. In an unusual turn about I got
> the
> > SSL stuff working but not the mailbox handling. I'm running 2.0beta6
> >
> > Output from dovecot -n
> >
>
> > # 2.0.beta6: /usr/local/etc/dovecot/dovecot.conf
> > # OS: FreeBSD 8.0-RELEASE-p2 i386 nfs
> > auth_debug = yes
> > auth_verbose = yes
> > default_internal_user = nobody
> > default_login_user = nobody
> > listen = *
> > mail_full_filesystem_access = yes
> > mail_location = mbox:/home/%u/:INBOX=/home/%u/
> ^ ^^?
> > passdb {
> > driver = pam
> > }
> > protocols = pop3
> > service pop3-login {
> > inet_listener pop3s {
> > port = 995
> > ssl = yes
> > }
> > }
> > service pop3 {
> > process_limit = 1024
> > }
> > ssl_cert = > ssl_key = > userdb {
> > driver = passwd
> > }
> > ---
> >
> > A typical failure looks like this in maillog:
> > Jun 15 22:19:20 eeebox dovecot: master: Dovecot v2.0.beta6 starting up
> > Jun 15 22:20:29 eeebox dovecot: pop3-login: Login: user=,
> > method=PLAIN, rip=66.125.189.27, lip=66.125.189.30, mpid=78871, TLS
> > Jun 15 22:20:29 eeebox dovecot: pop3(cmcmanis): Error: Opening INBOX
> failed:
> > Mailbox isn't selectable
> > Jun 15 22:20:29 eeebox dovecot: pop3(cmcmanis): Error: Couldn't open
> INBOX:
> > Mailbox isn't selectable
> > Jun 15 22:20:29 eeebox dovecot: pop3(cmcmanis): Couldn't open INBOX
> top=0/0,
> > retr=0/0, del=0/0, size=0
> >
> > --
> >
> > Home directories are mounted via NFS and root doesn't have access, but if
> > dovecot accesses the Mailbox as the user it should work fine.
> >
> > I'm about ready to start hacking in additional logging into
> mail-storage.c
> > to figure out what "mailbox isn't selectable" means.
>
>
> what happens when you set:
>mail_location = mbox:/home/%u/Mailbox:INBOX=/home/%u/Mailbox
> or:
>mail_location = mbox:~/Mailbox:INBOX=~/Mailbox
>
If I set the mailbox location to point to the file, I get another error
about how the root directory can't be a file. The exact error is:
Jun 16 08:21:57 eeebox dovecot: master: Dovecot v2.0.beta6 starting up
Jun 16 08:22:07 eeebox dovecot: pop3-login: Login: user=,
method=PLAIN, rip=66.125.189.27, lip=66.125.189.30, mpid=80225, TLS
Jun 16 08:22:07 eeebox dovecot: pop3(cmcmanis): Error: user cmcmanis:
Initialization failed: Initializing mail storage from mail_location setting
failed: mbox: mbox root directory can't be a file: /home/cmcmanis/Mailbox (
http://wiki.dovecot.org/MailLocation/Mbox)
Jun 16 08:22:07 eeebox dovecot: pop3(cmcmanis): Error: Invalid user
settings. Refer to server log for more information.
Now it strikes me that this message indicates that Dovecot is confused about
how mail is delivered on my system and is looking for a Maildir
implementation when I"m using single files. And yet I can't find a variable
in any of the various configuration files which can set for sure the mbox
"mode".
Dovecot should have logged, where it is looking for mails. If you can't
> find such information in your logs, set also mail_debug = yes in your
> conf.d/10-logging.conf
>
I have logging-conf set to both
auth_debug = yes
auth_verbose = yes
But it doesn't say anything else than what you see above.
--Chuck
>
> Regards,
> Pascal
> --
> The trapper recommends today: deadbeef.1016...@localdomain.org
>
[Dovecot] New admin, not much success
Hello,
I'm trying to set up something fairly simple (famous last words) using
Dovecot.
I have a very small setup (just a dozen users)
I'm using qmail as my MTA.
I'm running FreeBSD 8.0
I've got qmail delivering into a file named 'Mailbox' in user's home
directories.
I prefer not to use Maildir delivery because from a shell its a PITA to get
a Maildir aware MUA (I use /bin/mail when I'm attached locally)
What I'm trying to do is configure an SSL only POP3 server so that folks can
retrieve their email on the road without divulging their passwords.
My backup scenario is to put VPN software on my user's clients and having
them VPN into the network and then do un-encrypted POP3 from the VPN. I
prefer not to do this as it means maintaining the VPN client as well.
Users have a mix of MacOS, Windows, and Linux.
So, I can't get dovecot to work at all. In an unusual turn about I got the
SSL stuff working but not the mailbox handling. I'm running 2.0beta6
Output from dovecot -n
# 2.0.beta6: /usr/local/etc/dovecot/dovecot.conf
# OS: FreeBSD 8.0-RELEASE-p2 i386 nfs
auth_debug = yes
auth_verbose = yes
default_internal_user = nobody
default_login_user = nobody
listen = *
mail_full_filesystem_access = yes
mail_location = mbox:/home/%u/:INBOX=/home/%u/
passdb {
driver = pam
}
protocols = pop3
service pop3-login {
inet_listener pop3s {
port = 995
ssl = yes
}
}
service pop3 {
process_limit = 1024
}
ssl_cert = ,
method=PLAIN, rip=66.125.189.27, lip=66.125.189.30, mpid=78871, TLS
Jun 15 22:20:29 eeebox dovecot: pop3(cmcmanis): Error: Opening INBOX failed:
Mailbox isn't selectable
Jun 15 22:20:29 eeebox dovecot: pop3(cmcmanis): Error: Couldn't open INBOX:
Mailbox isn't selectable
Jun 15 22:20:29 eeebox dovecot: pop3(cmcmanis): Couldn't open INBOX top=0/0,
retr=0/0, del=0/0, size=0
--
Home directories are mounted via NFS and root doesn't have access, but if
dovecot accesses the Mailbox as the user it should work fine.
I'm about ready to start hacking in additional logging into mail-storage.c
to figure out what "mailbox isn't selectable" means.
--Chuck
