[Dovecot] Message UID Question

2008-04-18 Thread Joe Allesi -X (joallesi - Coyote Creek Consulting at Cisco)

I have referred to the wiki and the RFC, but I still can't find the
exact answer I'm looking for. From what I know, Dovecot uses the IMAP
standard of 32 bit integers to uniquely identify messages.

After a message is deleted from the mbox, can this UID ever be reissued
to a new message or is that UID retired? What about after the 2 billion
limit is reached?

Thanks!


[Dovecot] Duplicate Messages, Different X-UIDs?

2008-02-18 Thread Joe Allesi -X (joallesi - Coyote Creek Consulting at Cisco)

We're running into an issue where sendmail is only receiving one e-mail,
but after a client accesses the message via IMAP and moves it to another
IMAP folder, the message duplicates but each message has different X-UID
headers. Has anyone ever seen this type of anomaly before? Is it a bad
IMAP client, or a known bug?

Running 1.0.7

Thanks!


Re: [Dovecot] open files

2007-12-07 Thread Joe Allesi -X (joallesi - Coyote Creek Consulting at Cisco)

Most likely you hit this threshold:

[EMAIL PROTECTED] ~]# cat /proc/sys/fs/file-max
380081

Check the current usage here:

[EMAIL PROTECTED] ~]# cat /proc/sys/fs/file-nr
21450   380081

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Steve Heaven
Sent: Friday, December 07, 2007 6:24 AM
To: dovecot@dovecot.org
Subject: [Dovecot] open files

Is there a config value for the max open files ?


Re: [Dovecot] locking strategies?

2007-11-30 Thread Joe Allesi -X (joallesi - Coyote Creek Consulting at Cisco)

You had to ask that...we're still on 0.99, but we're testing other
options as well. We're pretty restricted to RHEL 4.x, but with the help
of others on the list we've made some progress with testing 1.0.7 on 4.x
as well. We have some clients using a java based IMAP application with
some major issues, so we're moving slow on changing our config for one
bad application. We've seen this issue and others, and Red Hat says
they're recommending dotlock to increase stability of the mboxes for the
short-term:

- fcntl() failed with mbox file /var/mail/XXX: Resource deadlock
avoided
- file istream.c: line 93 (i_stream_set_read_limit): assertion failed:
(stream-v_size == 0 || v_offset = stream-v_size)
- Corrupted modify log file
/users/XXX/mail/.imap/INBOX/.imap.index.log.2: Contains more data than
expected
- Error rewriting mbox file /users/XXX/mail/Folder Name: Unexpected end
of file



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Charles Marcus
Sent: Friday, November 30, 2007 6:34 PM
To: Dovecot Mailing List
Subject: Re: [Dovecot] locking strategies?

On 11/30/2007 Joe Allesi -X (joallesi - Coyote Creek Consulting at
Cisco) wrote:
 Any known issues with these locking strategies? (RHEL 4.x default)

Which version of dovecot?


[Dovecot] locking strategies?

2007-11-30 Thread Joe Allesi -X (joallesi - Coyote Creek Consulting at Cisco)

Any known issues with these locking strategies? (RHEL 4.x default)

Dovecot:
mbox_locks = fcntl

Procmail
Locking strategies: dotlocking, fcntl()

We're considering moving to all dotlocking after a recommendation from
RedHat, even though we're not using NFS at all.

Thanks!


[Dovecot] Embracing .99

2007-11-26 Thread Joe Allesi -X (joallesi - Coyote Creek Consulting at Cisco)

We're stuck on RHEL 4.x, so we're currently working on a plan to live in
harmony with .99 for another year or so. With that said, the plan is
below. Let me know if you have any other recommendations.

[ ]Convert to high-performance mode vice high-security to reduce overall
resource usage.
[ ]Implement iptables throttling for new connections to prevent denials
of service.
[ ]Covert from mbox to maildir to help reduce the likelihood of
corruption that lead to mailbox outages.

As our overall individual mailbox usage is low, maildir seems to be a
good option as mbox corruption has severely impacted a few of our
high-profile applications. However, does anyone know of a sane method to
use maildir on RHEL 4.x without switching over to Postfix?

Thanks!


[Dovecot] Throttle New Connections?

2007-11-19 Thread Joe Allesi -X (joallesi - Coyote Creek Consulting at Cisco)
All,

Is anyone using iptables (recent module), or any other alternatives, to
throttle the number of new imap or pop connections per minute? We have
some applications that like to login every second to pull mail using
imap, so we'd like to protect the entire dovecot server from these
applications. We've already made the change over to high-perf mode, but
we still need some type of denial of service protection. Any real-world
data would be appreciated.

Thanks!


Re: [Dovecot] dovecot-auth: Too many open files

2007-10-25 Thread Joe Allesi -X (joallesi - Coyote Creek Consulting at Cisco)

It's just a default RHEL4 RPM distribution and configuration. No changes
or optimizations have been done. No LDAP, just the local passwd.


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Tomas Janousek
Sent: Thursday, October 25, 2007 9:43 AM
To: dovecot@dovecot.org
Subject: Re: [Dovecot] dovecot-auth: Too many open files

Hello,

On Tue, Oct 23, 2007 at 01:16:35PM -0400, Joe Allesi -X (joallesi -
Coyote Creek Consulting at Cisco) wrote:
 We recently experienced an issue that prevented all new IMAP logins 
 from occurring. Although it appears that it was due to running out of 
 available system file descriptors, I'm still not sure what the true 
 root [...]
 
 Auth config:
 auth_userdb = passwd
 auth_passdb = pam
 [...]

Do you use LDAP or just local passwd?

--
Tomas Janousek, SW Engineer, Red Hat, Inc.


[Dovecot] dovecot-auth: Too many open files

2007-10-23 Thread Joe Allesi -X (joallesi - Coyote Creek Consulting at Cisco)
All,

[version: dovecot-0.99.11-4.EL4.src.rpm]

We recently experienced an issue that prevented all new IMAP logins from
occurring. Although it appears that it was due to running out of
available system file descriptors, I'm still not sure what the true root
cause was as I can't replicate the same error in our test environment.
The system file descriptor max was set at (per `cat
/proc/sys/fs/file-nr`) 380081 , and we're averaging around 7,000 in use.
It appears that the main issue was dovecot-auth, so does this appear to
fall in line with the known PAM bug in this version?

Auth config:
auth_userdb = passwd
auth_passdb = pam

Checked maillogs (cleansed):

Oct 16 11:48:05 host dovecot-auth: PAM: pipe() failed: Too many open
files
Oct 16 04:48:06 host imap-login: Disconnected [:::internal_IP]
Oct 16 11:48:11 host dovecot-auth: PAM: pipe() failed: Too many open
files
Oct 16 04:48:11 host imap-login: Aborted login [:::internal_IP]
Oct 16 04:48:11 host dovecot-auth: PAM unable to
dlopen(/lib/security/pam_nologin.so)
Oct 16 04:48:11 host dovecot-auth: PAM [dlerror:
/lib/security/pam_nologin.so: cannot open shared object file: Too many
open files]
Oct 16 04:48:11 host dovecot-auth: PAM adding faulty module:
/lib/security/pam_nologin.so
Oct 16 04:48:11 host dovecot-auth: PAM unable to
dlopen(/lib/security/pam_stack.so)
Oct 16 04:48:11 host dovecot-auth: PAM [dlerror:
/lib/security/pam_stack.so: cannot open shared object file: Too many
open files]

So, during the event I performed an strace against the dovecot-auth
process and noticed the following error as well:

accept(3, 0xbfe05a50, [2])  = -1 EMFILE (Too many open
files)
gettimeofday({1192538310, 41972}, NULL) = 0
poll([{fd=3, events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL,
revents=POLLIN}, {fd=0, events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL},
{fd=18, events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=10,
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=7,
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=23,
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=8,
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=11,
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=12,
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=13,
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=14,
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=19,
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=16,
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=17,
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=6,
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=15,
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=20,
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=21,
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=9,
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=22,
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=24,
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=25,
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=26,
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=27,
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=28,
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=34,
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=33,
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=29,
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=37,
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=30,
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=31,
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=41,
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, ...], 1020, 1585) = 1
gettimeofday({1192538310, 99354}, {480, 0}) = 0

Then I checked for the current network connections:

netstat | grep imap | wc -l
42

Then used lsof to check for open files:

while true ; do lsof | awk '{ print $3 }' | wc -l ; sleep 4 ; done
21728
21668
(restarted dovecot)
1838
1953
1864
2066
2018
2020
2036
2189
2661
2558
2490
(cont @2,000)

Thanks!

Joe Allesi