Re: [Dovecot] auth attempts errors
please don't bottom post On 11/14/2012 02:26 PM, Charles Marcus wrote: > Please don't top-post... > > On 2012-11-14 1:59 PM, burak gürer wrote: >>> Date: Wed, 14 Nov 2012 06:34:39 -0500 >>> From: cmar...@media-brokers.com >>> To: dovecot@dovecot.org >>> Subject: Re: [Dovecot] auth attempts errors >>> >>> On 2012-11-14 5:03 AM, burak gürer wrote: in dovecot log this error is coming every 20 seconds: dovecot: imap-login: Disconnected (no auth attempts in 0 secs): rip=**, lip=**, TLS handshaking: SSL_accept() syscall failed: Connection reset by peer >>> Looks like your SSL is broken... > >> "broken!" >> >> what do you mean > > Look at the error message: > > "TLS handshaking: SSL_accept() syscall failed:" > > I'm not an expert, but thats what it looks like to me. > >
Re: [Dovecot] Prevent Download messages from server
do you mean to leave a copy of the email on the server so it can be read in multiple email clients? IMAP can do this and i think modern POP3 can. look for an account config option in your mail client to "leave mail on server". i think there is a setting in dovecot to prevent expunging of email but it has been years since i was researching this. -david On 09/20/2012 02:21 AM, Selcuk Yazar wrote: Hi, can we prevent download messages from server user by user ? sme common used mail's message must be remain at the server, but sometimes we download them ? thanks in advance
Re: [Dovecot] replication howto
in ~privilgeduser/.ssh/authorized keys: from= cmd=dsync.sh pubkey... On 03/15/2012 05:05 PM, Timo Sirainen wrote: Then again it's safer to use system user accounts than a single vmail account that has access to everyone's emails. 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.
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On 01/05/2012 01:37 PM, Charles Marcus wrote: > On 2012-01-05 11:31 AM, Michael Orlitzky wrote: >> Ugh, sorry. I went to the link that someone else quoted: >> >>https://www.grc.com/haystack.htm > >> Gibson*is* a renowned crackpot. > > Don't know about that, but I do know from long experience Spinrite rocks! > > Maybe he often piggybacks on common sense but makes it into an elaborate grandiose presentation. a lot of his topics tend to wander out to left field come half-time. -d
Re: [Dovecot] Storing passwords encrypted... bcrypt?
> Because with multiple servers, we store them all in (replicated) mysql > :) (the same with postfix/dovecot). and as I'm sure you are aware, > Apache does not understand standard crypted MD5, hence why there is > the second option of apache_md5_crypt() with multiple servers, we use pam & nss, with a replicated ldap backed. this serves all auth requests for all services and no services cares if it is sha, md5, or a crypt method. -d
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On 01/03/2012 08:25 PM, Charles Marcus wrote: > > I think ya'll are missing the point... not sure, because I'm still not > completely sure that this is saying what I think it is saying (that's > why I asked)... > > I'm not worried about *active* brute force attacks against my server > using the standard smtp or imap protocols - fail2ban takes care of > those in a hurry. > > What I'm worried about is the worst case scenario of someone getting > ahold of the entire user database of *stored* passwords, where they > can then take their time and brute force them at their leisure, on > *their* *own* systems, without having to hammer my server over > smtp/imap and without the automated limit of *my* fail2ban getting in > their way. > > As for people writing their passwords down... our policy is that it is > a potentially *firable* *offense* (never even encountered one case of > anyone posting their password, and I'm on these systems off and on all > the time) if they do post these anywhere that is not under lock and > key. Also, I always set up their email clients for them (on their > workstations and on their phones - and of course tell it to remember > the password, so they basically never have to enter it. perhaps. part of my point along that of brute force resistance, is that when security becomes onerous to the typical user such as requiring non-repeat passwords of "10 characters including punctuation and mixed case", even stalwart policy followers start tending toward avoiding it. if anyone has a stressful job, spends a lot of time working, missing sleep, is thereby prone to memory lapse, it's almost a sure guarantee they *will* write it down/store it somewhere -- usually not in a password safe. or, they'll export their saved passwords to make a backup plain text copy, and leave it on their Desktop folder but coyly named and prefixed with a few random emails to grandma, so mr. sysadmin doesn't notice it. on a tangent, you should worry about active brute force attacks. fail2ban and iptables heuristics become meaningless when the brute forcing is done by bot nets which is more and more common than single-host attacks these days. one IP per attempt in a 10-20 minute window will probably never trigger any of these methods.
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On 01/03/2012 05:30 PM, Charles Marcus wrote: > On 2012-01-03 5:10 PM, WJCarpenter wrote: >> In his description, he uses the example of passwords which are >> "lowercase, alphanumeric, and 6 characters long" (and in another place >> the example is "lowercase, alphabetic passwords which are ≤7 >> characters", I guess to illustrate that things have gotten faster). If >> you are allowing your users to create such weak passwords, using bcrypt >> will not save you/them. Attackers will just be wasting more of your CPU >> time making attempts. If they get a copy of your hashed passwords, >> they'll likely be wasting their own CPU time, but they have plenty of >> that, too. > > I require strong passwords of 15 characters in length. Whats more, > they are assigned (by me), and the user cannot change it. But, he > isn't talking about brute force attacks against the server. He is > talking about if someone gained access to the SQL database where the > passwords are stored (as has happened countless times in the last few > years), and then had the luxury of brute forcing an attack locally (on > their own systems) against your password database. when it comes to brute force, passwords like "51k$jh#21hiaj2" are significantly weaker than "wePut85umbrellasIn2shoes". considerably difficult for humans which makes them far more likely to write it on a sticky and make it handily available.
Re: [Dovecot] Storing passwords encrypted... bcrypt?
md5 is deprecated, *nix has used sha1 for a while now
Re: [Dovecot] submission_host problem
this and several other features are tools i use with tremendous success at battling spam. every MTA connection that violates protocol by making an assumption or posts invalid data for the SMTP phase, gets kicked off with a 421. -david On 11/16/2011 09:11 AM, Marc Haber wrote: > I have always interpreted the standard in the way that a client MUST > NOT assume that the server supports pipelining before it has > advertised PIPELINING. Since PIPELINING is only advertised after the > client has identified itself as being ESMTP compliant by saying EHLO > instead of HELO, I believe that the client MUST wait with his EHLO > until the server has shown its banner. Forcing synchronization is a > very effective means of spam protection since most spam bots just > blast away with EHLO, MAIL FROM without bothering to wait for the > server's banner. Greetings Marc
Re: [Dovecot] file permissions
On 03/28/11 15:49, Charles Marcus wrote: > On 2011-03-28 3:36 PM, Walt Shekrota wrote: >> I'm thinking the later may be a procmail issue unless it is related >> to initial incorrect permissions? > Timo - I'm curious... some programs have the ability to check > permissions on their respective directories they work with/on, and fix > them if necessary... any chance dovecot could do that? please make sure this is optional. dovecot always tries to set the wrong ownership on our servers. -david
Re: [Dovecot] SSL Compatibility? SNI vs SAN (Subject Alternative Names) and multiple domains
if you want cheap, startssl.com. $0 certs available and they work fine w/ dovecot. -david
Re: [Dovecot] Separate access to different "folders" of the same mailbox?
~user/.procmailrc-backup or /etc/procmailrc-backup
MDIR="${HOME}/.maildir"
TODAY_YEAR=`date +%Y`
TODAY_MONTH=`date +%m`
TODAY_DAY=`date +%d`
# prepare the archive
:0
{
dummy=`(p="${MDIR}/.archive.$TODAY_YEAR.$TODAY_MONTH.$TODAY_DAY"; if [ !
-d $p ]; then mkdir -p $p; fi;) 2>/dev/null`
dummy=`if [ ! $(grep $(date '+archive.%Y.%m.%d')
$HOME/.maildir/subscriptions) ]; then echo $(date '+archive.%Y.%m.%d')
>> $HOME/.maildir/subscriptions; fi`
:0c
${MDIR}/.archive.$TODAY_YEAR.$TODAY_MONTH.$TODAY_DAY/
}
On 02/10/2011 02:41 AM, Oli Schacher wrote:
> On Thu, 10 Feb 2011 09:15:18 +0200
> Alexander Chekalin wrote:
>
>> in my company we have a mailbox that holds a copy of every message
>> that our SMTP processed. While it eats a lot of space, it saved us
>> several times when, you may imaging, user "suddenly" deleted the most
>> important message in his life and call our IT guys for help. The
>> mailbox contains "folders" for each day (like 2011-02-10), which
>> keeps mailings for that day only.
> [...]
>
> What you are describing is basically a standard mail
> archiving service. Instead of building this yourself you
> could look at existing software tools that include the features you
> describe and offer additional functionality like attachment indexing,
> signed archives etc. For example Mailarchiva (mailarchiva.com) -
> There is an open source version as well
> ( http://sourceforge.net/projects/openmailarchiva/ )
> Google lists various other alternatives.
>
> HTH
>
> Regards,
> Oli
>
Re: [Dovecot] How do folk . . . Aggregate system mail from LAN machines?
i use the standard sendmail everywhere, which uses central databases to route mail to final delivery machines, after all filtering is done, it's handed off to procmail for user side filtering and mailbox delivery. the concept of an MTA is after all, a mail transport agent :) -david On 01/12/2011 02:02 PM, Ron Leach wrote: > List, good evening, > > Running Dovecot for external email, but not yet worked out how (best) > to aggregate 'system' mail from other machines on the LAN. By system > mail, I mean mails generated by the OS or by applications, and > addressed to root, or 'some admin user', etc. Ideally, these would be > seen by 'root' or 'some admin user' or whoever on our existing > Dovecot/IMAP system. Our scale is not large, we only have 5 servers > on the LAN doing various things. > > I wondered how other Dovecot users do this. I've thought of 3 > possibilities: > > 1. Install Dovecot on each LAN machine, and use Fetchmail to retrieve > the messages using POP so that local mail stores were emptied. > > 2. Perhaps, use a 'forwarding' mechanism of some sort on each LAN > machine, but that would require an MTA on each LAN machine, would it not? > > 3. I wondered whether /etc/alias, mentioned in a recent post by > Simone Caruso, might help though again, presumably, requiring an MTA > on each LAN machine. > > What do you do? > > regards, Ron >
Re: [Dovecot] 'Doveadm user' could use better error codes
dovecot, the whole point of his original email is to return a useful error code for the purpose of scripting. :) always returning 0 for both valid and invalid usernames isn't helpful -d
Re: [Dovecot] load increase after upgrade to 2.0.8
what's your task switch HZ compiled at? CONFIG_HZ_1000? you would probably be better at 300 or 250. have you tried tickless? is your kernel compiled for precisely your cpu type and smp/hyper options set correctly? what about CONFIG_PREEMPT? definitely don't use realtime, server is appropriate. -d On 12/08/10 11:05, Ralf Hildebrandt wrote: Timo and I found excessive numbers of context switches, factor 20-30. But it's unclear why the IMAP process would do/cause this.
Re: [Dovecot] load increase after upgrade to 2.0.8
gprof for detail, and even with simple strace timing. i.e. strace -c. if load is going up significantly, there should be one or more functions significantly fatter than the rest. you can pick either to run it on the whole group, or just attach to certain processes. (master, imap, lda, etc) when you run 'ps aux|grep dovecot', what seems to collect the most cpu time? -d On 12/08/10 10:54, Ralf Hildebrandt wrote: * David Ford: Ralf, did you do the profiling yet? With gprof or what exactly is on your mind?
Re: [Dovecot] load increase after upgrade to 2.0.8
Ralf, did you do the profiling yet? On 12/08/10 09:50, Ralf Hildebrandt wrote: [...] Yes, this looks like my graphs. Same increase. Factor 5.
Re: [Dovecot] Dovecot 1.2.16 compiling error
openssl < 0.9.8o and <1.0.0b are vulnerable to exploits. -david On 12/03/10 10:55, Mart Pirita wrote: [...] The last good OpenSSL is openssl-0.9.8l.tar.gz , 1.2.15 compiles and runs fine, however 1.2.16 compiling still fails:
Re: [Dovecot] Dovecot 2.0.7 (8793036f6de8) seems to miss some defaults for vsz_limit
I believe Timo is already patching these. On 11/16/10 16:09, Thomas Leuxner wrote: > Latest Mercurial seems to miss defaults for some services e.g. 'managesieve' > and 'lmtp'. Example error message upon start: > > dovecotdoveconf: Fatal: Error in configuration file > /etc/dovecot/dovecot.conf: service(managesieve-login): vsz_limit is too low > failed! > > Regards > Thomas
Re: [Dovecot] (no subject)
thanks for playing "paley wiener" spammer. GTFO On 11/15/2010 02:24 PM, Radio Tron wrote: > http://aigipe.it/here.php > > >
[Dovecot] \Noselect eliciting bug?
Timo, examine these two simplified sets if you will. This, is a properly working $inbox folder: d /home/david/.maildir /home/david/.maildir/dovecot.* d /home/david/.maildir/cur d /home/david/.maildir/new d /home/david/.maildir/tmp /home/david/.maildir/subscriptions This one is not, $inbox becomes \Noselect: d /home/david/.maildir /home/david/.any-file /home/david/.maildir/dovecot.* d /home/david/.maildir/cur d /home/david/.maildir/new d /home/david/.maildir/tmp /home/david/.maildir/subscriptions i can make directories willy nilly starting with a dot, but a -file- starting with a dot breaks my mailbox. it doesn't affect any other folder, just $inbox 2.0.6
Re: [Dovecot] Occasional fchown errors?
yes, my mind has been churning on path dereference resolution and efficiency since i made this version of the patch. thank you. -david On 11/10/2010 02:13 PM, Timo Sirainen wrote: > On Wed, 2010-11-10 at 14:01 -0500, David Ford wrote: >> Timo, >> >> i'm stuck with no time for studying code at the moment. is there a >> quick/easy way to check if this is a personal or shared mailbox we are >> working under? i can then update my patch so it works for both cases. > Well, you could check if list->ns->type is NAMESPACE_PRIVATE or > something else. But then again, some people have created shared > mailboxes by symlinking them into private namespace, and then it's > pretty much impossible to know if it's shared or not.
Re: [Dovecot] Occasional fchown errors?
Timo, i'm stuck with no time for studying code at the moment. is there a quick/easy way to check if this is a personal or shared mailbox we are working under? i can then update my patch so it works for both cases. -david On 11/10/2010 01:58 PM, David Ford wrote: > hmm. yes, that might be sensible of me :} i haven't touched 1.x in so > long, i have no idea if it's applicable. my understanding from Timo is > that it's been this way for quite some time so it would likely be easy > to massage into place. > > it's linked at > http://stuph.org/dovecot-2.0.5-bad-permissions-inheritance.patch and > attached. > > -d > > On 11/10/2010 01:54 PM, Marcus Rueckert wrote: >> On 2010-11-10 13:48:13 -0500, David Ford wrote: >>> Use this patch, it fixes dovecot's ownership inheritance assumptions. >> [snip] >> >> 1. he is using 1.2.9 and your patch is for 2.0, would your patch work >>for 1.2.9 aswell. >> >> 2. you want to attach the patch and not paste it inline. >>your mail client mangled the lines. >> >> darix >>
Re: [Dovecot] Occasional fchown errors?
hmm. yes, that might be sensible of me :} i haven't touched 1.x in so
long, i have no idea if it's applicable. my understanding from Timo is
that it's been this way for quite some time so it would likely be easy
to massage into place.
it's linked at
http://stuph.org/dovecot-2.0.5-bad-permissions-inheritance.patch and
attached.
-d
On 11/10/2010 01:54 PM, Marcus Rueckert wrote:
> On 2010-11-10 13:48:13 -0500, David Ford wrote:
>> Use this patch, it fixes dovecot's ownership inheritance assumptions.
> [snip]
>
> 1. he is using 1.2.9 and your patch is for 2.0, would your patch work
>for 1.2.9 aswell.
>
> 2. you want to attach the patch and not paste it inline.
>your mail client mangled the lines.
>
> darix
>
--- src/lib-storage/mailbox-list.c.orig 2010-09-14 11:03:18.0 -0400
+++ src/lib-storage/mailbox-list.c 2010-10-14 15:20:15.0 -0400
@@ -25,6 +25,9 @@
#include
#include
#include
+#include
+#include
+#include
/* 20 * (200+1) < 4096 which is the standard PATH_MAX. Having these settings
prevents malicious user from creating eg. "a/a/a/.../a" mailbox name and
@@ -450,7 +453,7 @@
}
if (S_ISDIR(st.st_mode) && (st.st_mode & S_ISGID) != 0) {
- /* directory's GID is used automatically for new
+ /* directory is sgid, so GID is used automatically for
new
files */
*gid_r = (gid_t)-1;
} else if ((st.st_mode & 0070) >> 3 == (st.st_mode & 0007)) {
@@ -460,8 +463,39 @@
} else if (getegid() == st.st_gid) {
/* using our own gid, no need to change it */
*gid_r = (gid_t)-1;
- } else {
- *gid_r = st.st_gid;
+ }
+
+ else {
+ /* test for unusable inheritance. logic sets fgid_me to
st.gid
+ for unlikely case of lookup failure and we just fall
through */
+ int j, ngroups = 999;
+ gid_t *groups;
+ gid_t fgid_me = st.st_gid;
+
+ groups = malloc(ngroups * sizeof (gid_t));
+ if (groups != NULL) {
+ uid_t egid = getegid();
+ struct passwd *pw = getpwuid(geteuid());
+ if (pw != NULL) {
+ /* get pw entry for test using my
current effective uid */
+ if (getgrouplist(pw->pw_name, egid,
groups, &ngroups) != -1) {
+ /* get list of group IDs my
euid belongs to, ngroups
+ will be set to the number of
groups I belong to */
+ fgid_me = egid;
+ for (j = 0; j < ngroups; j++) {
+ /* enumerate list, test
to see if i belong
+ to gid of parent
directory */
+ if (st.st_gid ==
groups[j]) {
+ /* if so,
switch to parent gid */
+ fgid_me =
st.st_gid;
+ }
+ }
+ }
+ }
+ free(groups);
+ }
+
+ *gid_r = fgid_me;
}
}
Re: [Dovecot] Occasional fchown errors?
as a reminder if you didn't follow the thread. this only avoids
inheritance assumption. if you have shared folders, they should be g+s
to delegate (group) ownership. also, this is for 2.x
-david
On 11/10/2010 01:48 PM, David Ford wrote:
> Use this patch, it fixes dovecot's ownership inheritance assumptions.
>
> Colt ~ # cat
> /usr/local/portage/net-mail/dovecot/files/dovecot-2.0.5-bad-permissions-inheritance.patch
>
> --- src/lib-storage/mailbox-list.c.orig 2010-09-14 11:03:18.0 -0400
> +++ src/lib-storage/mailbox-list.c 2010-10-14 15:20:15.0 -0400
> @@ -25,6 +25,9 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
>
> /* 20 * (200+1) < 4096 which is the standard PATH_MAX. Having these
> settings
> prevents malicious user from creating eg. "a/a/a/.../a" mailbox name and
> @@ -450,7 +453,7 @@
> }
>
> if (S_ISDIR(st.st_mode) && (st.st_mode & S_ISGID) != 0) {
> - /* directory's GID is used automatically for new
> + /* directory is sgid, so GID is used
> automatically for new
>files */
> *gid_r = (gid_t)-1;
> } else if ((st.st_mode & 0070) >> 3 == (st.st_mode &
> 0007)) {
> @@ -460,8 +463,39 @@
> } else if (getegid() == st.st_gid) {
> /* using our own gid, no need to change it */
> *gid_r = (gid_t)-1;
> - } else {
> - *gid_r = st.st_gid;
> + }
> +
> + else {
> + /* test for unusable inheritance. logic sets
> fgid_me to st.gid
> + for unlikely case of lookup failure and we
> just fall through */
> + int j, ngroups = 999;
> + gid_t *groups;
> + gid_t fgid_me = st.st_gid;
> +
> + groups = malloc(ngroups * sizeof (gid_t));
> + if (groups != NULL) {
> + uid_t egid = getegid();
> + struct passwd *pw = getpwuid(geteuid());
> + if (pw != NULL) {
> + /* get pw entry for test using
> my current effective uid */
> + if (getgrouplist(pw->pw_name,
> egid, groups, &ngroups) != -1) {
> + /* get list of group IDs
> my euid belongs to, ngroups
> + will be set to the
> number of groups I belong to */
> + fgid_me = egid;
> + for (j = 0; j < ngroups;
> j++) {
> + /* enumerate
> list, test to see if i belong
> + to gid of
> parent directory */
> + if (st.st_gid ==
> groups[j]) {
> + /* if
> so, switch to parent gid */
> + fgid_me
> = st.st_gid;
> + }
> + }
> + }
> + }
> + free(groups);
> + }
> +
> + *gid_r = fgid_me;
> }
> }
>
>
>
> On 11/10/2010 01:34 PM, Knute Johnson wrote:
>> Hi:
>>
>> I get the occasional error below. Is there something I don't have
>> configured correctly? Or should I just ignore this? It is not always
>> this file, sometimes it is the cache.lock file or the log.newlock
>> file. I have a mail client running on my computer and my phone at the
>> same time, could that have something to do with it?
>>
>> Nov 10 08:32:59 rabbitbrush dovecot: IMAP(bob):
>> fchown(/home/bob/mail/.imap/INBOX/dovecot.index.tmp, -1, 8(mail))
>> failed: Operation not permitted (egid=1000(bob), group based on
>> /var/mail/bob)
>>
>> From dovecot -n
>>
>> # 1.2.9: /etc/dovecot/dovecot.conf
>> # OS: Linux 2.6.32-25-generic i686 Ubuntu 10.04.1 LTS
>> log_timestamp: %Y-%m-%d %H:%M:%S
>> protocols: imaps
>> ssl_cert_file: /etc/ssl/certs/ssl-cert-snakeoil.pem
>> ssl_key_file: /etc/ssl/private/ssl-cert-snakeoil.key
>> login_dir: /var/run/dovecot/login
>> login_executable: /usr/lib/dovecot/imap-login
>> mail_privileged_group: mail
>> mail_location: mbox:~/mail:INBOX=/var/mail/%u
>> mbox_write_locks: fcntl dotlock
>> auth default:
>> passdb:
>> driver: pam
>> userdb:
>> driver: passwd
>>
>> Thanks very much,
>>
Re: [Dovecot] Occasional fchown errors?
Use this patch, it fixes dovecot's ownership inheritance assumptions.
Colt ~ # cat
/usr/local/portage/net-mail/dovecot/files/dovecot-2.0.5-bad-permissions-inheritance.patch
--- src/lib-storage/mailbox-list.c.orig 2010-09-14 11:03:18.0 -0400
+++ src/lib-storage/mailbox-list.c 2010-10-14 15:20:15.0 -0400
@@ -25,6 +25,9 @@
#include
#include
#include
+#include
+#include
+#include
/* 20 * (200+1) < 4096 which is the standard PATH_MAX. Having these
settings
prevents malicious user from creating eg. "a/a/a/.../a" mailbox name and
@@ -450,7 +453,7 @@
}
if (S_ISDIR(st.st_mode) && (st.st_mode & S_ISGID) != 0) {
- /* directory's GID is used automatically for new
+ /* directory is sgid, so GID is used
automatically for new
files */
*gid_r = (gid_t)-1;
} else if ((st.st_mode & 0070) >> 3 == (st.st_mode &
0007)) {
@@ -460,8 +463,39 @@
} else if (getegid() == st.st_gid) {
/* using our own gid, no need to change it */
*gid_r = (gid_t)-1;
- } else {
- *gid_r = st.st_gid;
+ }
+
+ else {
+ /* test for unusable inheritance. logic sets
fgid_me to st.gid
+ for unlikely case of lookup failure and we
just fall through */
+ int j, ngroups = 999;
+ gid_t *groups;
+ gid_t fgid_me = st.st_gid;
+
+ groups = malloc(ngroups * sizeof (gid_t));
+ if (groups != NULL) {
+ uid_t egid = getegid();
+ struct passwd *pw = getpwuid(geteuid());
+ if (pw != NULL) {
+ /* get pw entry for test using
my current effective uid */
+ if (getgrouplist(pw->pw_name,
egid, groups, &ngroups) != -1) {
+ /* get list of group IDs
my euid belongs to, ngroups
+ will be set to the
number of groups I belong to */
+ fgid_me = egid;
+ for (j = 0; j < ngroups;
j++) {
+ /* enumerate
list, test to see if i belong
+ to gid of
parent directory */
+ if (st.st_gid ==
groups[j]) {
+ /* if
so, switch to parent gid */
+ fgid_me
= st.st_gid;
+ }
+ }
+ }
+ }
+ free(groups);
+ }
+
+ *gid_r = fgid_me;
}
}
On 11/10/2010 01:34 PM, Knute Johnson wrote:
> Hi:
>
> I get the occasional error below. Is there something I don't have
> configured correctly? Or should I just ignore this? It is not always
> this file, sometimes it is the cache.lock file or the log.newlock
> file. I have a mail client running on my computer and my phone at the
> same time, could that have something to do with it?
>
> Nov 10 08:32:59 rabbitbrush dovecot: IMAP(bob):
> fchown(/home/bob/mail/.imap/INBOX/dovecot.index.tmp, -1, 8(mail))
> failed: Operation not permitted (egid=1000(bob), group based on
> /var/mail/bob)
>
> From dovecot -n
>
> # 1.2.9: /etc/dovecot/dovecot.conf
> # OS: Linux 2.6.32-25-generic i686 Ubuntu 10.04.1 LTS
> log_timestamp: %Y-%m-%d %H:%M:%S
> protocols: imaps
> ssl_cert_file: /etc/ssl/certs/ssl-cert-snakeoil.pem
> ssl_key_file: /etc/ssl/private/ssl-cert-snakeoil.key
> login_dir: /var/run/dovecot/login
> login_executable: /usr/lib/dovecot/imap-login
> mail_privileged_group: mail
> mail_location: mbox:~/mail:INBOX=/var/mail/%u
> mbox_write_locks: fcntl dotlock
> auth default:
> passdb:
> driver: pam
> userdb:
> driver: passwd
>
> Thanks very much,
>
Re: [Dovecot] need to block user by IP address (tried denyhosts, xinetd, iptables etc)
On 11/09/2010 10:59 PM, Eric Rostetter wrote: > Quoting David Ford : > >> I'm not a proponent of fail2ban as I think going straight to the horse's >> mouth is wiser (keep it all in iptables in the first place). > > I'm not a fan of fail2ban (tail/grep a log file, really?) but there > are other options which do this kind of thing "better" and still > allow iptables/routing to handle the issue. if i establish a rate limit in iptables, then accounting and reaction never makes it to userspace. horribly more expensive, especially at the occurance of a DoS attack. unfortunately not an option in Tom's case. >> I agree >> with Stan that your VPS provider is on the wal-mart list. If no other >> solution avails, code up a quick little ditty that does the actual >> socket listen. If the incoming IP matches an allow list, hand it off to >> dovecot as an exec(), if not, deal with it as you see fit - normally, >> dropping the packet on the floor. > > That is a fine solution, if it meets their "package" requirements. > If not, then something like pam_shield or a similar package may due. > But even then, those types of packages may not meet the site's packaging > requirements. > > I can't believe a company with a packaging requirement run a Fedora > though. > That seems incongruous to me... Seems like they only have half a clue... > agreed. a VPS should be fully functional. that's what 'VPS' implies. not almost-but-not-quite-VPS.
Re: [Dovecot] need to block user by IP address (tried denyhosts, xinetd, iptables etc)
I'm not a proponent of fail2ban as I think going straight to the horse's mouth is wiser (keep it all in iptables in the first place). I agree with Stan that your VPS provider is on the wal-mart list. If no other solution avails, code up a quick little ditty that does the actual socket listen. If the incoming IP matches an allow list, hand it off to dovecot as an exec(), if not, deal with it as you see fit - normally, dropping the packet on the floor. -david
Re: [Dovecot] Ongoing performance issues with 2.0.x
On 11/05/10 08:56, Ralf Hildebrandt wrote: > I'm only scanning directories that haven't been scanned for a long time > (I cannot scan all the boxes in one night). Main purpose is to remove > freshly detected viruses/spam that wasn't in the patterns at delivery > time. > > The benefit is somewhat limited; one might argue it doesn't make much > sense. I'm curious what would show up new in mailboxes other than drafts and sent items. on my networks, AV and anti-spam hooks are via sendmail/milter and get called for all smtp regardless of direction which means an infected desktop won't be able to transmit spam. thus, running a nightly scan on mailboxes after delivery means the above - save the draft/sent mailboxes, the benefit is zero and it's only going to drive up the load. -d -- Linux - freedom to build is good Please top-post and trim when replying to my messages. I most often read mail on a small device. PGP signature 91ED 44F8 108B E981 DB67 49AC F450 EFD5 6A99 94A2 VERY NOT-IMPORTANT NOT-LEGAL NOTICES: Recalling a message does in no way delete it from my computer. Rather, it brings attention to your original email and recalling it causes me to search for a reason to find embarrassment. Please don't send message recall messages. It's silly and obnoxious and wastes even more bandwidth and patience. Regardless of what legal message you append to your email message, I am not obligated or constrained in any way shape or form and -every- court backs this up. If I feel like printing it out and taping it up at the local gym, or mass mailing it to 15,000 people, I will. I feel especially inclined to do so the longer your "legal" advisory is. Such notices are unenforceable and do not protect you or your company from things you say, or things others do with the email. "Millions of innocent men, women and children, since the introduction of Christianity, have been burnt, tortured, fined, imprisoned; yet we have not advanced one inch towards uniformity. What has been the effect of coercion? To make half the world fools, and the other half hypocrites." --Thomas Jefferson This message is confidential to the Internet at large, unless otherwise indicated or apparent from its nature. It may not be reproduced on Mars unless it has previously been printed on Uranus. This message is directed to the intended recipient only (usually everyone, but sometimes nobody and once in a blue moon, just somebody), who may be readily determined by the sender of this message and its contents. This email message (including any attachments) is not for the sole use of the intended recipient(s) and may or may not contain confidential, proprietary and privileged information. It may include sarcastic holier than tho content. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient: (a) any dissemination or copying of this message is strictly prohibited unless you feel otherwise; and (b) immediately notify the sender by return message (but only if the sun has gone black) and destroy any copies of this message in any form (electronic, paper or carved in stone) that you have. Please destroy by smashing your computer with a 21lb sledge hammer approximately 17 times to ensure destruction of your system. Any unauthorized review, use, disclosure or distribution is most assuredly not prohibited and you will not IMMEDIATELY be PROSECUTED to the fullest ... or emptiest ... extent of the law. If you are not the intended recipient, please immediately notify some random person of how old you are, if you're male, female, TV, TG, alien, and if you live on planet earth or the primordial plane and your undying desire to fornicate with them by email and destroy all copies of the original message if you sent it to an underage person. Oh, and definitely don't tell me about it. The delivery of this message and its information is neither intended to be nor constitutes a disclosure or waiver of any trade secrets, intellectual property, attorney work product, or attorney-client communications. If you happen to be a corporation that uses lawyer-think-speak-asinine-thoughts well then please sit your ass back down and we will promptly ignore the hell out of you and your disclaimers. Wait, no we won't. We have this urgent primal need to publicly make fun of you, and then we'll re-post your message in blazing full frontal nudity across the internet. The authority of the individual sending this message to legally bind any entity is neither apparent nor implied, and must be independently verified - uh ... duh? Isn't that obvious? Of course not. Only people with intelligence recognize such simple facts. Thank you for standing in the back yard and whining your ass off holding up tiny little posters forbidding mosquitoes from biting you. Does a whole hell of a lot of good. Right? Yeah, you keep up with the delusions. Keeping
Re: [Dovecot] Ongoing performance issues with 2.0.x
why don't you run clamdscan on delivery? that way you only scan each email once, not repeatedly every night until it's deleted. -david On 11/05/10 05:58, Ralf Hildebrandt wrote: > During the night we're using clamdscan to scan mailboxes for viruses, > this results in the big block of system & user from 0:00 until about > 08:00 > -- Linux - freedom to build is good Please top-post and trim when replying to my messages. I most often read mail on a small device. PGP signature 91ED 44F8 108B E981 DB67 49AC F450 EFD5 6A99 94A2 VERY NOT-IMPORTANT NOT-LEGAL NOTICES: Recalling a message does in no way delete it from my computer. Rather, it brings attention to your original email and recalling it causes me to search for a reason to find embarrassment. Please don't send message recall messages. It's silly and obnoxious and wastes even more bandwidth and patience. Regardless of what legal message you append to your email message, I am not obligated or constrained in any way shape or form and -every- court backs this up. If I feel like printing it out and taping it up at the local gym, or mass mailing it to 15,000 people, I will. I feel especially inclined to do so the longer your "legal" advisory is. Such notices are unenforceable and do not protect you or your company from things you say, or things others do with the email. "Millions of innocent men, women and children, since the introduction of Christianity, have been burnt, tortured, fined, imprisoned; yet we have not advanced one inch towards uniformity. What has been the effect of coercion? To make half the world fools, and the other half hypocrites." --Thomas Jefferson This message is confidential to the Internet at large, unless otherwise indicated or apparent from its nature. It may not be reproduced on Mars unless it has previously been printed on Uranus. This message is directed to the intended recipient only (usually everyone, but sometimes nobody and once in a blue moon, just somebody), who may be readily determined by the sender of this message and its contents. This email message (including any attachments) is not for the sole use of the intended recipient(s) and may or may not contain confidential, proprietary and privileged information. It may include sarcastic holier than tho content. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient: (a) any dissemination or copying of this message is strictly prohibited unless you feel otherwise; and (b) immediately notify the sender by return message (but only if the sun has gone black) and destroy any copies of this message in any form (electronic, paper or carved in stone) that you have. Please destroy by smashing your computer with a 21lb sledge hammer approximately 17 times to ensure destruction of your system. Any unauthorized review, use, disclosure or distribution is most assuredly not prohibited and you will not IMMEDIATELY be PROSECUTED to the fullest ... or emptiest ... extent of the law. If you are not the intended recipient, please immediately notify some random person of how old you are, if you're male, female, TV, TG, alien, and if you live on planet earth or the primordial plane and your undying desire to fornicate with them by email and destroy all copies of the original message if you sent it to an underage person. Oh, and definitely don't tell me about it. The delivery of this message and its information is neither intended to be nor constitutes a disclosure or waiver of any trade secrets, intellectual property, attorney work product, or attorney-client communications. If you happen to be a corporation that uses lawyer-think-speak-asinine-thoughts well then please sit your ass back down and we will promptly ignore the hell out of you and your disclaimers. Wait, no we won't. We have this urgent primal need to publicly make fun of you, and then we'll re-post your message in blazing full frontal nudity across the internet. The authority of the individual sending this message to legally bind any entity is neither apparent nor implied, and must be independently verified - uh ... duh? Isn't that obvious? Of course not. Only people with intelligence recognize such simple facts. Thank you for standing in the back yard and whining your ass off holding up tiny little posters forbidding mosquitoes from biting you. Does a whole hell of a lot of good. Right? Yeah, you keep up with the delusions. Keeping up with the Jones is good after all. Holy hell Batman sleeps with Robin -- This disclaimer is short!
[Dovecot] Dovecot chgrp actions on new files/folders
Timo,
I did further study of the user/group permissions. Applying the below
patch will make no difference to virtually everyone out there. Those
that have default uid/gid ownership won't see any change as the gid
already matches so the fchown() action won't be attempted. Those that
have sgid will still see the normal expected fchown() enforced by the
kernel which becomes a duplicated action by dovecot. In the last case,
those with an unknown 3rd party gid were used to seeing fchown()
failures and those will now go away. It is only this third group that
will see anything change as all other cases are already handled. Anyone
who wishes to create new files with another group ID should make their
directories sgid or stgid as per normal filesystem ACL semantics. The
original net effect of this only turns on an fchown() that will fail and
emit numerous error messages. This patch fixes that. Technically the
fchown is unneccessary extra code already since any directory that is
sgid or stgid will have ownership enforced by the kernel already.
I simply made it #if 0 below, the correct patch would be to delete the
extraneous block.
--- src/lib-storage/mailbox-list.c.orig 2010-09-14 11:03:18.0 -0400
+++ src/lib-storage/mailbox-list.c 2010-10-08 13:02:54.0 -0400
@@ -450,7 +450,7 @@
}
if (S_ISDIR(st.st_mode) && (st.st_mode & S_ISGID) != 0) {
- /* directory's GID is used automatically for new
+ /* directory is sgid, so GID is used
automatically for new
files */
*gid_r = (gid_t)-1;
} else if ((st.st_mode & 0070) >> 3 == (st.st_mode &
0007)) {
@@ -460,9 +460,13 @@
} else if (getegid() == st.st_gid) {
/* using our own gid, no need to change it */
*gid_r = (gid_t)-1;
- } else {
+ }
+#if 0
+#warning this code makes dovecot attempt to chgrp files to wrong
ownership
+ else {
*gid_r = st.st_gid;
}
+#endif
}
if (name == NULL) {
Re: [Dovecot] Limit access to dovecot by domains?
use the connect-acl script at http://www.linux.org.py/wiki/howto/dovecot_connect_acl or, the post-login script at http://wiki.dovecot.org/PostLoginScripting (side note, http://spameatingmonkey.com/ Geo blacklist, for similar reasons but blocking outsider countries like oh say, china users that like to brute force) On 10/13/2010 03:08 AM, Jobst Schmalenbach wrote: > Hi. > > Is there any way to limit access to dovecot by domains. > > I only need to give access to a well known set of domains, all from > Australia and all networks are known and used either from people > at home or mobile access (phones, laptops etc). > > iptables is not possible as e.g. OPTUS does not give away all of the > networks mobile phones are connected to. I know some, but not all. > > It would be much nicer and easier to allow > > optusnet.com.au > bigpond.com.au > tpg.com.au > > and I have given 100% of our users access. > > > I know there is an extra field called "allow_nets", I tried this > and failed. I did a search and found that this only works with SQL? > > > Maybe I could include a script that would check the reverse DNS record > of a connected IP and then I could filter? > > > Jobst > > > > >
Re: [Dovecot] Feature request for maildir style boxes
On 10/05/2010 07:35 PM, Timo Sirainen wrote: > On 6.10.2010, at 0.26, David Ford wrote: >> it's a bug in dovecot to assume a) the user wants this gid change even >> without setgid, and b) that it can change the gid to an arbitrary value >> of a parent directory. >> >> other software runs as :net-mail, and it's use and operation >> is not applicable to this discussion. mode 0700 is not functional for >> this group of software and mode 0770 is too lax. > Your situation seems like a very special case that probably doesn't exist > just about anywhere else. Unless someone can give me a specific use case for > this that can't be solved nicely some other way, I'm not changing Dovecot's > behavior. > what is the purpose in dovecot assuming that it should set a gid other than the userid:gid it's operating under? security minded folks make explicit permissions on directories to prevent software from errantly setting loose ownership which might lead to unintended information leakage or unauthorized access by other software. the directory is not setgid, programs should not attempt to give away ownership unless directed to. consider /tmp. it would be onerous to write files in /tmp and attempt to set the group ownership to root. currently, about 40% of the files and directories under /var are set to : where /var is owned by root:root. it's simply bad practice to give away ownership unless there is a reason for it, and a common vector for exploitation.
Re: [Dovecot] Feature request for maildir style boxes
On 10/05/2010 07:17 PM, Timo Sirainen wrote: > It can't do delivery as net-mail group if they're 0700. dovecot runs as my userid; david:david so it has permissions for accessing anything in .maildir/ and below. this is why it gets EPERM errors when it tries to set the group id of net-mail. it's a bug in dovecot to assume a) the user wants this gid change even without setgid, and b) that it can change the gid to an arbitrary value of a parent directory. other software runs as :net-mail, and it's use and operation is not applicable to this discussion. mode 0700 is not functional for this group of software and mode 0770 is too lax.
Re: [Dovecot] Feature request for maildir style boxes
On 10/05/2010 06:44 PM, Timo Sirainen wrote: > On 5.10.2010, at 23.38, David Ford wrote: > >> net-mail group is used by sendmail, procmail, dovecot, and additional >> programs that read/write in the users mail directory. > Can you give some specific examples? > i did. sendmail accesses .forward or aliasing files, procmail does delivery, dovecot does read/write for imap, pine reads and writes and webmail cgi reads and writes or uses imap. >>drwxr-x--- david net-mail /home/david/.maildir >>drwx-- david david /home/david/.maildir/cur > Does new/ and tmp/ directories then have netmail-rx so mails can be > delivered? What about non-INBOX mailboxes? Or what exactly is the point of > not just making .maildir/ 0700? Or if new/ dir is g+rw, is it important that > cur/ directory isn't? > new/ and tmp/ are set to david:david 0700 as cur/ is, as well as all non-INBOX. .maildir cannot be 0700 because programs that don't run as the same userid but only as the group id cannot then access the .maildir directory. it's not important that they have access to files below the top level mail store. procmail issues an error when writing in tmp/ as well. ~/.maildir/ is not setgid because i don't want files forced to the net-mail group. dovecot is taking it upon itself to do so anyway. that's nice and all, but not desired and the directory permissions aren't set for this policy. to be technical, it's unexpected. i want my email files to be set to david:david, not david:other-group. dovecot should not assume that the gid should be set differently from my user's gid. the group permissions are set for read/exec in this directory for this group, the minimum needed for all the daemons to play nicely with each other, and with the user.
Re: [Dovecot] Feature request for maildir style boxes
net-mail group is used by sendmail, procmail, dovecot, and additional programs that read/write in the users mail directory. without permissions such as below and using typical permissions, other users can cd into a users .maildir and identify all folders a user is subscribed to (personal information leakage), watch for new emails (timing attacks). the same goes for the web directories. the source of web scripts can be revealed as well as other information. our users tend to be picky about security and privacy amongst themselves, and it's not always possible to make each daemon set their id or group id to the user or not be noisy about unexpected lack of permissions when doing file operations for the user. each service has their own idea about how file permissions should be set. daemons not in the net-all group simply don't have access to the user's home directory regardless. the "other way" is having dovecot not attempt to emulate the setgid bit of a directory and fchown() children in that directory, . dovecot would then simply set the uid/gid of the file as the user it's currently running as. if users want to force files created in that directory to a given gid, they could set the gid and chmod g+s on that directory. On 10/05/2010 06:17 PM, Timo Sirainen wrote: > On 5.10.2010, at 20.13, David Ford wrote: > >>drwxr-x--- david net-mail /home/david/.maildir >>drwx-- david david /home/david/.maildir/cur > Can you give me some use case for what the net-mail is used for? > >> to something like: ( "new_files_inherit_parent_gid = true" ) > I hate settings that are going to be used only by about one installation. > Maybe there's another way. > >
Re: [Dovecot] Startup error dovecot-2.0.5
what does strace -s 1024 ... yield?
-david
On 10/05/2010 04:19 PM, Ralf Hildebrandt wrote:
> [...]
> strace yields
>
> ...
> execve("/usr/dovecot-2/sbin/dovecot", ["/usr/dovecot-2/sbin/dovecot", "-c",
> "/usr/dovecot-2/etc/dovecot/dovec"...], [/* 244 vars */]) = -1 E2BIG
> (Argument list too long)
> write(2, "doveconf: Fatal: execvp(/usr/dov"..., 84doveconf: Fatal:
> execvp(/usr/dovecot-2/sbin/dovecot) failed: Argument list too long) = 84
> exit_group(89) = ?
>
[Dovecot] Feature request for maildir style boxes
greetings,
i'd like to ask for a certain feature request.
dovecot:maildir_uidlist_recreate() to set the gid of new files based on
the parent directory group ownership and normally that's desired, an
appropriate security method. on our server, we use directory
permissions to more stringently isolate access between users and
services. we have three group ids used for this, and i'll use my name
as example.
Oct 05 13:44:30 imap(david): Error:
fchown(/home/david/.maildir/dovecot-uidlist.tmp, -1, 497(net-mail))
failed: Operation not permitted (egid=1234(david), group based on
/home/david/.maildir)
Colt log # ls -ld /home/ /home/david /home/david/public_html/
/home/david/.maildir /home/david/.maildir/cur|awk '{printf "%s %5s %9s
%s\n", $1,$3,$4,$9}'
drwxr-xr-x root root /home/
drwx--x--- david net-all /home/david
drwxr-x--- david net-mail /home/david/.maildir
drwx-- david david /home/david/.maildir/cur
drwxr-x--- david net-web /home/david/public_html/
the purpose of this is to prevent undesired access to personal files.
users cannot 'cd' or 'ls' in other user's home directories, mail stores,
or web files.
apache, procmail, dovecot et cetera, are in the appropriate groups and
therefore have access needed to do file ops. however, they're limited to
their appropriate stores.
as mentioned at the beginning, dovecot tries to match the gid of the
parent directory for new files and normally, that's desired and expected
behavior, but in our case. dovecot creates the file as uid/gid of the
user, so the knob can either ignore the failure to set gid per the
parent and not log it, or not attempt to set the gid per parent in the
first place.
src/lib-storage/index/maildir/maildir-uidlist.c
1412: if (box->file_create_gid != (gid_t)-1 &&
fchown(fd, (uid_t)-1, box->file_create_gid) < 0) {
if (errno == EPERM) {
mail_storage_set_critical(box->storage, "%s",
eperm_error_get_chgrp("fchown", temp_path,
box->file_create_gid,
box->file_create_gid_origin));
} else {
mail_storage_set_critical(box->storage,
"fchown(%s) failed: %m", temp_path);
}
}
to something like: ( "new_files_inherit_parent_gid = true" )
if (box->file_create_gid != -1 &&
--> box->new_files_inherit_parent_gid)
{
fchown(fd, -1, box->file_create_gid)
...
}
bool new_files_inherit_parent_gid [default true] could be added the
following for example:
src/lib-storage/mailbox-list-private.h:struct mailbox_list
src/lib-storage/mail-storage-private.h:struct mailbox
this block of code appears in similar instances for a number of other
occasions (and could be made a more global function), but not all files
in ~/.maildir/* appear to use a function like this. the uidvalidity
functions are a little different for example.
==
for a busy mail server, that's a lot of excess logging and pollution
when trying to review nightly logs for issues :)
thank you for the consideration,
-david
