[EMAIL PROTECTED] writes:
After discussing this with the Moto Email Client dev team, they've concluded that although RFC 2595 does describe in more detail the SASL AUTH PLAIN authentication mechanism, that RFC is specifc to IMAP, POP3 and ACAP. It's title is, after all "Using TLS with IMAP, POP3 and ACAP".
As far as they are concerned, RFC 2554 "SMTP Service Extension for Authentication" is the only RFC that is applicable in this situation because the problem is specific to SMTP, and does not involve IMAP, POP3 or ACAP protocols specifically.
The definition of any SASL mechanism is completely independent of the underlying protocol that's being authenticated.
Furthermore, if your âengineersâ would like to make an argument that the definition of a SASL method requires that the SASL method must be defined for a specific protocol, then I would like to point out that RFC 2554 does not define SASL PLAIN for SMTP at all. Therefore, SASL PLAIN for SMTP is undefined, and they should use SASL LOGIN instead.
Is there anything else I can do to convince either side of this discussion to make the changes that would allow the Motorola Email Client to interoperate with Courier mail servers that require authentication for SMTP?
Well, actually I did look. The implementation of SASL PLAIN in Courier was written four years ago (and I have to note that up until now nobody had a problem with it). As it turns out that code will actually issue an empty prompt if the initial message is not provided, so perhaps your original analysis was wrong, and your problem lies elsewhere. You can see for yourself that Courier will issue an empty prompt by telnetting in manually, and issuing an AUTH PLAIN by hand. It is not logged by courieresmtpd, but it will be issued.
pgp6IgpemaAfr.pgp
Description: PGP signature
