dovecot - May 2007 - Testing IMAP clients with Dovecot, problems with MacMail

I've been testing my user community's IMAP clients when I try to login 
and then transfer a big message from the inbox into a folder in an 
overquota folder directory.  I am using native filesystem quotaing in 
AIXV5.3 with UWIMAP and comparing my results with what I see with 
Dovecot 1.0.0. (My Dovecot built without any plugins or quota extensions)

Everything matches/works except for Mac Mail under SSL with Dovecot..

Mac Mail:
1) with UWIMAP, login and mailbox load goes OK, then the illegal 
overquota xfer fails (as it should) with a popup reading 'Message could 
not be moved', with (port 993) and without (port 143) SSL
2) with Dovecot,
1) login and mailbox load goes OK to port 10143, plain listen, and the 
illegal xfer correctly fails as it should with a popup messge under a 
plain connection, but
2) When the port number is set to the Dovecot ssl_listen port and the 
SSL box is checked, Mac Mail doesn't bring up the inbox and folders...it 
acts like it can't connect. 

Has anyone else seen this behavior, and is there a fix?  Mac Mail is 
also known as Mail.app.  I am testing it at 1.3.11 and 2.1.1.  In the 
July '05 archive, I found this:
> It looks like Mail.app treats "non-standard" ports differently. 
On the
> standard port (993), the "SSL" option seems to do pure SSL; but
with
> another
> port specified, it does clean-plus-starttls (and hence fails horribly, 
> because
> it's talking to a pure SSl service)
Is there anything I can do to get MacMail to behave correctly?  Or will 
it clear up when I shut down UWIMAP and give Dovecot the default ports.  
A Bronx cheer for Mac Mail........

My thanks in advance, S.


Everything else I tested behaves...for anyone that's interested.......
================ Over Quota Xfer results ===================
Insecure Pine from Unix login shell: refused by both UWIMAP (cannot 
exceed user or group quota) and Dovecot (there's not enough disk space.) 
server apps.  It is presumed that this will be used from within an SSH 
session to secure the transmission.

Webmail (horde, insecure and secure) : refused by both UWIMAP (cannot 
exceed user or group quota) and Dovecot (there's not enough disk space.) 
server apps.

PC:
TBird 1.5, 2.0, Sea Monkey and Netscape 7.2: get a popup with both 
UWIMAP (cannot exceed user or group quota) and Dovecot (there's not 
enough disk space.) server apps, both secure and insecure

Mac:
Seamonkey: ditto, same as PC Sea Monkey
Mac Mail or Mail.app only works insecure, as per above

Stewart Dean wrote:
>> It looks like Mail.app treats "non-standard" ports
differently.  On the
>> standard port (993), the "SSL" option seems to do pure SSL;
but with
>> another
>> port specified, it does clean-plus-starttls (and hence fails horribly, 
>> because
>> it's talking to a pure SSl service)
> Is there anything I can do to get MacMail to behave correctly?  Or will 
> it clear up when I shut down UWIMAP and give Dovecot the default ports.  
> A Bronx cheer for Mac Mail........
It's possible it *might* clear up when you move to the standard ports; 
the server advertises STARTTLS capability (well, at least my Dovecot 
build does :) ). so it's possible that the Mail app is sniffing the 
server CAPABILITY flags, seeing a non-default port and trying to do 
something smart. I found this blurb:

"Apple?s Mail application has checkboxes to enable TLS for incoming 
Internet Message Access Protocol (IMAP) or outgoing SMTP connections. 
STARTTLS or direct TLS is used automatically, depending on the target 
port." (http://sial.org/howto/openssl/tls-name/)

If you have tcpdump (or similar) on one of your OS X boxen, fire it up 
and trap the packets between the two servers and check out the net 
traffic and what ports it's trying to use. That'd be where I start...

Also, check out this blog post:
http://blog.scottlowe.org/2005/07/02/starttls-and-imap-in-mailapp/

"So, it appears that Mail.app does indeed support STARTTLS for IMAP, but 
only if you set the port number back to 143 after checking the ?Use SSL? 
checkbox."

-te

-- 
Troy Engel | Systems Engineer
Fluid, Inc | http://www.fluid.com

At 4:13 PM -0400 5/3/07, Stewart Dean wrote:
>I've been testing my user community's IMAP clients when I try to 
>login and then transfer a big message from the inbox into a folder 
>in an overquota folder directory.  I am using native filesystem 
>quotaing in AIXV5.3 with UWIMAP and comparing my results with what I 
>see with Dovecot 1.0.0. (My Dovecot built without any plugins or 
>quota extensions)
>
>Everything matches/works except for Mac Mail under SSL with Dovecot..
>
>Mac Mail:
>1) with UWIMAP, login and mailbox load goes OK, then the illegal 
>overquota xfer fails (as it should) with a popup reading 'Message 
>could not be moved', with (port 993) and without (port 143) SSL
>2) with Dovecot,
>1) login and mailbox load goes OK to port 10143, plain listen, and 
>the illegal xfer correctly fails as it should with a popup messge 
>under a plain connection, but
>2) When the port number is set to the Dovecot ssl_listen port and 
>the SSL box is checked, Mac Mail doesn't bring up the inbox and 
>folders...it acts like it can't connect.
>Has anyone else seen this behavior, and is there a fix?  Mac Mail is 
>also known as Mail.app.  I am testing it at 1.3.11 and 2.1.1.  In 
>the July '05 archive, I found this:
>>It looks like Mail.app treats "non-standard" ports
differently.  On the
>>standard port (993), the "SSL" option seems to do pure SSL;
but with another
>>port specified, it does clean-plus-starttls (and hence fails 
>>horribly, because
>>it's talking to a pure SSl service)
>Is there anything I can do to get MacMail to behave correctly?  Or 
>will it clear up when I shut down UWIMAP and give Dovecot the 
>default ports.  A Bronx cheer for Mac Mail........
I don't think there's any way to get Mail to talk  "imaps" on
any
port other than 993. I also can't see any compelling reason to to do 
that, since it looks like all of the clients you tested should be 
able to use STARTTLS anyway, so having a second port for direct SSL 
is not useful.

What am I missing?


-- 
Bill Cole                                  
bill at scconsult.com