Once again thank you Brian,

I've got tcpdump running now, I'll give it a few hours then check the file for 
problems as you suggested.

I'll let you know what I find out.

I have used telnet to connect to IMAP prior to mailing and got similar results 
as with Thunderbird, Telnet however just said unable to connect rather than 
connection refused which I took to mean it wasn't even getting as far as 
authenticating.

I will take a look at the file limit as I imagine that this would prevent 
connections being made as well. Although I am able to ssh into the server 
even when IMAP connections are refused so I think that might be a kipper ( 
sorry red herring ).

I've just been told by one of the directors that she had problems last night 
around 10 pm, obviously it's unlikely we'd have many other connections at 
that time so this might point towards MAXPERIP since I know she has virtually 
every mailbox in the place set up in Thunderbird.

Once again watch this space and thank you.

On Thursday 28 June 2007 11:06, Brian Candler wrote:
> On Thu, Jun 28, 2007 at 10:47:43AM +0100, Adrian wrote:
> > I figured that the new machine being about 10 times faster
> > and with 4 times the RAM and a gigabit NIC instead of 100mb maybe it was
> > just showing the problem faster ( maybe flawed logic there! ).
>
> That's flawed logic I'd say. TCP and IP are designed to run over flakey
> networks, and a 33.6kbps dial-up modem will happily carry multiple IMAP
> sessions, albeit slowly.
>
> Even if your 100Mbps switched network were totally saturated with traffic,
> this would manifest itself as slowness or timeouts. What you're observing,
> according to your report, is getting "connection was refused". That is,
> either the kernel or the application is actively rejecting an inbound
> connection. This may take the form of:
>
>   TCP  SYN -->
>   TCP  RST <--
>
> Use tcpdump or wireshark (on client and/or server) if you wish to confirm
> or disprove this at the IP layer (*). Note that your switches will never
> generated TCP RST packets; only the end hosts participate in TCP. And hence
> if this is happening, it's nothing to do with your network infrastructure,
> and throwing money at your LAN won't help.
>
> Use netstat to monitor the concurrent network sockets on the server. It's
> also conceivable that you've reached your system-wide file descriptor
> limit, which under Linux I think is 'sysctl fs.file-max', although
> generally that limit is very high. I'm afraid I don't know how to monitor
> the actual FD usage, other than
>
>   ls /proc/*/fd
>
> Of course, it's worth checking under exactly what conditions your client
> generates the message you're seeing, e.g. by looking at the source code.
> Perhaps you're getting occasional authentication failures, but these are
> displayed to the client confusingly as "connection was refused". In that
> case, you need to look at your authentication daemon setup.
>
> The most unambiguous client to use is:
>
>   telnet x.x.x.x 143
>   a login username password
>   a logout
>
> If you can capture the problem with that, and copy-paste the full
> transcript with the *exact* responses returned by the server, that would
> most likely be able to pinpoint the problem.
>
> Regards,
>
> Brian.
>
> (*)
>     tcpdump -i eth0 -n -s0 -w imap.pcap tcp port 143 or icmp
>
> will record all the relevant packets into a file, which you can later
> analyse using
>
>    tcpdump -r imap.pcap -nX | less
>
> Make sure the clock is accurate on your systems, e.g. using ntp. Then if
> someone reports they saw this problem at a particular time, then you can
> look into the problem.
>
> As long as the IMAP connection is not encrypted using SSL, this file will
> also show all the commands sent to and responses from the server. Hence if
> the server itself is sending an IMAP response for authentication failure,
> say, then this will be recorded too. Beware that your users' passwords will
> be captured in this file though.

-- 
Regards,

Adrian

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Courier-imap mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap

Reply via email to