headers
Ken Keating | 25 Apr 18:38

imapd 2007a and Mac mailer

Our recently reported problems with mbx inbox and non-mbx folders 
causing deadlocks was fixed by upgrading from imapd 2006j to 2007a. 
Thanks Mark!  However, we are not problem free.

For testing purposes we built 2007a to accept secure connections on port 
994 rather than 993.  Outlook, Thunderbird, and Mac mail on Leopard (OS 
X 10.5) seem to work just fine, but Mac mail version 2.1.3 on Tiger (OS 
X 10.4) has problems.  We get error messages in our sendmail log:

Apr 18 09:45:31 <hostname> simapsd[10190]: [ID 960700 mail.info] 
Unexpected client disconnect, while reading line user=??? host=<fqhn> 
[<IP addr>]

This seems to be a problem with Mac mail, but does anyone have 
suggestions on how to get around it?

Ken Keating
_______________________________________________
Imap-uw mailing list
Imap-uw <at> u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
Permalink | Reply |
headers
Mark Crispin | 26 Apr 02:22

Re: imapd 2007a and Mac mailer

On Fri, 25 Apr 2008, Ken Keating wrote:
> For testing purposes we built 2007a to accept secure connections on port 994 
> rather than 993.

How did you do this?  Did you change IMAPSSLPORT in imap4r1.c from 993 to 
994 (the most straightforward way)?  Or did you use some other means?  If 
so, what?

> Outlook, Thunderbird, and Mac mail on Leopard (OS X 10.5) 
> seem to work just fine, but Mac mail version 2.1.3 on Tiger (OS X 10.4) has 
> problems.  We get error messages in our sendmail log:
> Apr 18 09:45:31 <hostname> simapsd[10190]: [ID 960700 mail.info] Unexpected client disconnect, while
reading line user=??? host=<fqhn> [<IP addr>]

This isn't an error message.  It simply means that a not-logged-in client 
disconnected the session without first issuing a LOGOUT command.  Some 
clients do this routinely in the notion that this is "more efficient".

So, all we really know here is that Mail.app on Tiger did not log in, and 
then disconnected the session.

I can think of two likely possibilities off the top of my head:

[1] You are mistaken, and your port 994 server is not really doing SSL. 
The client expects to do SSL, communications never start, and eventually 
it disconnects.

[2] Your port 994 server is doing SSL, but the client is not expecting 
SSL, communications never start, and eventually it disconnects.
(Continue reading)

Permalink | Reply |
headers
simon haywood | 27 Apr 22:25

Re: imapd 2007a and Mac mailer

I use the same email client - Apple Mail 2.3.1 running on OSX 10.4.11  
(though I use Postfix, not Sendmail), so I checked my logs for you.

Client "book" connects to host "Arthur" using SSL on port 993.

I see the following entry:
Apr 27 21:12:41 Arthur imapd[1507]: imaps SSL service init from  
192.168.178.29
Apr 27 21:12:42 Arthur imapd[1507]: Command stream end of file, while  
reading line user=??? host=book [192.168.178.29]

Rather similar - I'm guessing the differences are down to the  
differences between Postfix and Sendmail.

(I believe) I get the "error" because I'm using a self-signed  
certificate - that I have to manually accept at login stage (only  
once). It seems that Apple Mail behaves this way when it's waiting  
for that confirmation.

Could something similar be true for you?

Simon

On 26 Apr 2008, at 01:22, Mark Crispin wrote:

> On Fri, 25 Apr 2008, Ken Keating wrote:
>> For testing purposes we built 2007a to accept secure connections  
>> on port 994 rather than 993.
>
> How did you do this?  Did you change IMAPSSLPORT in imap4r1.c from
(Continue reading)

Permalink | Reply |
headers
Mark Crispin | 27 Apr 22:32

Re: imapd 2007a and Mac mailer

On Sun, 27 Apr 2008, simon haywood wrote:
> Apr 27 21:12:41 Arthur imapd[1507]: imaps SSL service init from 192.168.178.29
> Apr 27 21:12:42 Arthur imapd[1507]: Command stream end of file, while reading line user=??? host=book [192.168.178.29]

Please remember, this log message only means that that client disconnected 
without logging in, without even a login attempt that passed a user name 
(the "user=???"), and without sending a LOGOUT.

This doesn't indicate any problem on the server.  It may indicate a 
problem in the client.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
_______________________________________________
Imap-uw mailing list
Imap-uw <at> u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
Permalink | Reply |
headers
simon haywood | 27 Apr 22:40

Re: imapd 2007a and Mac mailer

On 27 Apr 2008, at 21:32, Mark Crispin wrote:

> On Sun, 27 Apr 2008, simon haywood wrote:
>> Apr 27 21:12:41 Arthur imapd[1507]: imaps SSL service init from  
>> 192.168.178.29
>> Apr 27 21:12:42 Arthur imapd[1507]: Command stream end of file,  
>> while reading line user=??? host=book [192.168.178.29]
>
> Please remember, this log message only means that that client  
> disconnected without logging in, without even a login attempt that  
> passed a user name (the "user=???"), and without sending a LOGOUT.
>
> This doesn't indicate any problem on the server.  It may indicate a  
> problem in the client.
>
Of course - and I realise that.

I should have added another line or two perhaps:

Noting that Ken was in test-mode, there is a fair chance that he's  
also using self-signed certificates. If that's the case, I'm  
suggesting that's probably his "problem" - ie. no problem at all - it  
seems that's just the way Apple Mail does things (like it or otherwise).

simon

> -- Mark --
>
> http://staff.washington.edu/mrc
> Science does not emerge from voting, party politics, or public debate.
(Continue reading)

Permalink | Reply |
headers
Ken Keating | 1 May 23:53

Re: imapd 2007a and Mac mailer

> How did you do this?  Did you change IMAPSSLPORT in imap4r1.c from 993
> to 994 (the most straightforward way)?  Or did you use some other
> means?  If so, what?

We didn't change IMAPSSLPORT.  We're running Solaris 10 and controlling
this through inetd:

myuser <at> myserver> svcs -a | grep imap
online         Feb_27   svc:/network/imaps/tcp:default
online         Mar_14   svc:/network/imap/tcp:default
online         Apr_17   svc:/network/imapstest/tcp:default

imapstest is version 2007a

> To dismiss [1], do
>     telnet imapserversystem 994
> You should be rewarded by dead silence after the connection is
> established.  If you see an IMAP greeting banner, then [1] is the problem.

We do, in fact, get dead silence.

> To verify that [1] is not the problem, run openssl and do
>     s_client -connect imapserversystem:994
> You should see a bunch of SSL diagnostic crud, and eventually an IMAP
> greeting banner.

As you say, we get a bunch of SSL stuff, then only

* OK [CAPABILITY IMAP4REV1 LITERAL+ SASL-IR LOGIN-REFERRALS AUTH=PLAIN
AUTH=LOGIN] myserver.mathcs.emory.edu IMAP4rev1 2007a.403 at Tue, 29 Apr
(Continue reading)

Permalink | Reply |
headers
Mark Crispin | 2 May 00:07

Re: imapd 2007a and Mac mailer

On Thu, 1 May 2008, Ken Keating wrote:
>> How did you do this?  Did you change IMAPSSLPORT in imap4r1.c from 993
>> to 994 (the most straightforward way)?  Or did you use some other
>> means?  If so, what?
> We didn't change IMAPSSLPORT.  We're running Solaris 10 and controlling
> this through inetd:

Hmm.  I still don't understand how imapd knows on your system that it is 
to run in SSL mode on port 994 as opposed to plaintext mode.  It chooses 
SSL if (and only if):
  . it is on the imaps port (port 993)
or
  . the port is not the imap port (port 143) or imaps port (port 993) AND
    the name of its binary starts with "s"

I guess that you must be doing the latter, since your message definitely 
describes an imapd in SSL mode.  OK by me... ;-)

>> To test for [2], run a packet sniffer and try a connection.  If both
>> sessions are quiet after connecting, that suggests [2], since a
>> plaintext IMAP client expects to be spoken to before it speaks, and in
>> SSL the client starts speaking first.
> I think this describes what I'm seeing, but I'm going to run it by one
> of my much more experienced colleagues to see if his interpretation is
> the same.

Another test you can do is to get a non-SSL server running on port 994 and 
seeing if it works.  If so, that would be pretty strong indication that 
the client is not in SSL mode.
(Continue reading)

Permalink | Reply |
headers
simon haywood | 2 May 09:52

Re: imapd 2007a and Mac mailer


On 1 May 2008, at 23:07, Mark Crispin wrote:

>
>
>> Simon indicated in another response that there may be a problem if  
>> we use a self-signed certificate.  We may have a self-signed  
>> certificate in our chain, but we definitely have an externally- 
>> signed certificate as well.
>
> Bizarre if that is the cause.
>

I don't think you have a problem. As far as I can tell, it goes like  
this:

Apple Mail starts SSL login.
Apple Mail finds that it can't verify the certificate (because it's  
self signed).
Apple Mail presents a dialogue asking the user to accept or otherwise  
the certificate.
The user accepts.
Apple Mail cancels the login it previously started.
Apple Mail starts a new SSL login.
Login succeeds (because certificate has been verified).

That's why you get the spurious log entries (at least, that's why I  
get the exact same log entries) - but as Mark has indicated, there's  
no issue.
(Continue reading)

Permalink | Reply |

Gmane