Hi Andreas,
Thanks for the quick response!
To respond to your question, I get:
XX CAPABILITY
* CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT
THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION STARTTLS LOGINDISABLED
XX OK CAPABILITY completed
However, sorry to be dense here: what does this mean in terms of what I
should do? Do I need to configure my IMAP to not expect SSL, or use a
different mechanism then? I can't find anywhere to "tell" courier not
to expect SSL.
Thank you for your help Andreas--
Best,
Dave
Andreas Winkelmann wrote:
Am Montag 02 Februar 2009 17:49:32 schrieb Dave Della Costa:
> I've been using this tutorial:
> http://www.gentoo.org/doc/en/virt-mail-howto.xml
>
> It's a bit sparse on some details. Everything is working, except:
>
> I cannot get authentication to work when I try to connect from my client
> to send email via postfix. I can login to my courier imap server (on
> port 993, although I just opened 143 too to make sure that wasn't a
> problem) as well--I know I'm using valid credentials. I'll let the logs
> speak for themselves:
>
> Feb 2 15:54:27 host saslauthd[15778]: do_auth : auth failure:
> [user=postmaster] [service=smtp] [realm=] [mech=rimap] [reason=remote
> server rejected your credentials]
>
> I don't believe postfix is the problem here (at this point at least).
> If I run testsaslauthd I get:
>
> host ~ # testsaslauthd -u postmaster -p thepassword
> 0: NO "authentication failed"
>
> and in the logs, again:
>
> Feb 2 16:14:35 host saslauthd[15778]: do_auth : auth failure:
> [user=postmaster] [service=imap] [realm=] [mech=rimap] [reason=remote
> server rejected your credentials]
>
> I've noted that the "service" field is different, but even if I run
>
> host ~ # testsaslauthd -u postmaster -p thepassword -s smtp
> 0: NO "authentication failed"
>
> ...same thing:
>
> Feb 2 16:16:09 host saslauthd[15774]: do_auth : auth failure:
> [user=postmaster] [service=smtp] [realm=] [mech=rimap] [reason=remote
> server rejected your credentials]
>
> I'm just trying to wrap my head around the process now. I don't feel
> like I even quite know how to debug this fully, but there are a few
> other things I've determined:
>
> 1) postfix appears to be working completely in every other way. So I
> think it is not an issue, and it would seem that, as I can't even get
> testsaslauthd to authenticate, my problems are unrelated to my postfix
> configuration.
>
> 2) As I said, I can login to IMAP successfully. I originally had only
> 993 open (imaps), but it seemed like saslauthd wouldn't connect that
> way, and I couldn't figure out how to configure this; but I figured I'd
> leave that alone for now and figure it out later.
>
> One thing I did notice was that when I logged in to IMAP directly from
> my mail client, I'd see this sort of behavior in the logs:
>
> Feb 2 16:20:37 host imapd-ssl: LOGIN, user=postmaster@host,
> ip=[::ffff:x.x.x.x], protocol=IMAP
> Feb 2 16:20:38 host imapd-ssl: Connection, ip=[::ffff:x.x.x.x]
> Feb 2 16:20:38 host authdaemond: received auth request, service=imap,
> authtype=login
> Feb 2 16:20:38 host authdaemond: authmysql: trying this module
> Feb 2 16:20:38 host authdaemond: SQL query: SELECT email ...(etc.)
>
> So, IMAP login seems to successfully pass off authentication to
> courier-auth. However, when I try using testsaslauthd, or connect to
> send mail through postfix via my client, I only see this as far as IMAP
> in the logs:
>
> Feb 2 16:23:32 host imapd: Connection, ip=[::ffff:127.0.0.1]
> Feb 2 16:23:32 host imapd: Disconnected, ip=[::ffff:127.0.0.1], time=0
I would guess your imapd does not support the LOGIN-Command without an
established SSL Connection. And "rimap" is not able to setup a SSL Layer.
Show:
$ telnet your.imap.server 143
...
XX CAPABILITY
...
Show the response to the CAPABILITY Command.
> That's it. Obviously, it's not passing off to courier-auth. If I
> understand what the rimap authentication mechanism is doing, it should
> in fact look pretty much the same as the successful IMAP login, right?
> So it seems like I must have misconfigured something for sasl so that it
> is not speaking to the imap server in a way it expects; I noticed I
> don't see the "LOGIN" message in the logs, for example.
>
> However, I can't for the life of me figure out how I can get more
> debugging data for this, or configure saslauthd differently. I've
> enabled SQL logging in MySQL (where I am storing authentication info, as
> you can see from the first IMAP log example) and it is clear that the
> database is *not* being hit at all when I run testsaslauthd. And
> courier auth debugging is set to 2 so that's coming out full force. Is
> there any place I can specify higher levels of debugging for saslauthd?
> Adding the '-d' flag to saslauthd wasn't helpful, unfortunately.
>
> /etc/sasl2/smtpd.conf:
>
> host ~ # cat /etc/sasl2/smtpd.conf
> mech_list: PLAIN LOGIN
> pwcheck_method: saslauthd
> host ~ #
>
> /etc/conf.d/saslauthd
>
> host ~ # cat /etc/conf.d/saslauthd
> # Config file for /etc/init.d/saslauthd
>
> # Initial (empty) options.
> SASLAUTHD_OPTS=""
>
> # Specify the authentications mechanism.
> # **NOTE** For a list see: saslauthd -v
> # Since 2.1.19, add "-r" to options for old behavior,
> # ie. reassemble user and realm to user@realm form.
> #SASLAUTHD_OPTS="${SASLAUTHD_OPTS} -a pam -r"
> #SASLAUTHD_OPTS="${SASLAUTHD_OPTS} -a pam"
>
> # Specify the hostname for remote IMAP server.
> # **NOTE** Only needed if rimap auth mechanism is used.
> #SASLAUTHD_OPTS="${SASLAUTHD_OPTS} -O localhost"
>
> # Specify the number of worker processes to create.
> #SASLAUTHD_OPTS="${SASLAUTHD_OPTS} -n 5"
>
> # Enable credential cache, set cache size and timeout.
> # **NOTE** Size is measured in kilobytes.
> # Timeout is measured in seconds.
> #SASLAUTHD_OPTS="${SASLAUTHD_OPTS} -c -s 128 -t 30"
>
> # per http://www.gentoo.org/doc/en/virt-mail-howto.xml
> SASLAUTHD_OPTS="${SASLAUTH_MECH} -a rimap -r"
> SASLAUTHD_OPTS="${SASLAUTHD_OPTS} -O localhost"
> host ~ #
>
> Any help--even just pointers as to where to look--would be greatly
> appreciated...if you need more info for diagnosis let me know. And if
> I'm barking up the wrong tree and need to investigate my IMAP config (or
> something else entirely) instead, my apologies.
--
Andreas
