I've been testing some development releases of the IMAP4/SMTP mail
client application that will be shipping on upcoming Motorola cell
phones (yes, I work for motorola). I run a courier 0.45.5 server at home
(mail.buberel.org), which I have been using for testing.
Happily, I can verify that IMAP4 access over SSL/TLS works wonderfully from
the phone. However, I'm having problems with sending mail message from
the phone using authentication SMTP. My server is configured to allow
PLAIN and LOGIN authentication for SMTP when SSL or TLS are used.
In my server logs, I see the following client dialog when trying to send
mail from the phone:
Jun 4 09:52:56 taylor courieresmtpd: started,ip=[::ffff:66.102.167.246]
Jun 4 09:52:57 taylor courieresmtpd: EHLO 10.200.150.91
Jun 4 09:52:58 taylor courieresmtpd: STARTTLS
Jun 4 09:53:06 taylor courieresmtpd: EHLO 10.200.150.91
Jun 4 09:53:07 taylor courieresmtpd: AUTH PLAIN
Jun 4 09:53:07 taylor courieresmtpd: error,relay=::ffff:66.102.167.246,msg="535
Authentication failed.",cmd: AUTH PLAIN
When using a different mail client, such as Evolution, I see the
authentication information being sent with the AUTH PLAIN command:
Jun 4 10:04:31 taylor courieresmtpd: started,ip=[::ffff:127.0.0.1]
Jun 4 10:04:31 taylor courieresmtpd: EHLO localhost
Jun 4 10:04:32 taylor courieresmtpd: STARTTLS
Jun 4 10:04:32 taylor courieresmtpd: EHLO localhost
Jun 4 10:04:32 taylor courieresmtpd: AUTH PLAIN xxxxxxxxxxxxxxxxxxxxxxxxxx==
Jun 4 10:04:32 taylor courieresmtpd: EHLO localhost
I sent this transcript off to one of the SMTP developers, and he sent me
this excerpt from the RFC (emphasis his):
4. The AUTH command
AUTH mechanism [initial-response]
Arguments:
a string identifying a SASL authentication mechanism.
an _optional_ base64-encoded response
So the Motorola SMTP client is treating the AUTH initial-response as
optional, and not sending it as part of the AUTH PLAIN command. Instead,
the client is waiting for a '334' response from the server, after which
it will send the actual authentication credentials.
So according to the engineer, this would be a valid example
conversation (using CRAM-MD5 as an example):
S: 220 smtp.example.com ESMTP server ready
C: EHLO jgm.example.com
S: 250-smtp.example.com
S: 250 AUTH CRAM-MD5 DIGEST-MD5
C: AUTH CRAM-MD5
S: 334 PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4=
C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ==
S: 235 Authentication successful.
Instead of seeing the '334' command, courier-esmtpd is replying with ERROR,
causing the mail send operation to fail (obviously).
So is this really a server non-compliance issue, or is this a client
that doesn't fully implement the RFC?
Thanks for any insight,
jason
-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
_______________________________________________
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
