idSMTP SASL fails under Android..?

[rlebeau]

This post is a copy of the one I just posted on the Embarcadero forum.
Just want to see how it works here.

I'll post the same answer here that I posted there.

Code:

SMTP.Username := AUsername;
SMTP.Password := APassword;

Those properties are only used when AuthType=satDefault.

Code:

IdSSLIOHandlerSocketOpenSSL1.Port := APort;
IdSSLIOHandlerSocketOpenSSL1.Host := AHost;

You do not need to set those properties manually, Connect() handles that for you.

Code:

IdSSLIOHandlerSocketOpenSSL1.ReadTimeout := 10000;

You should set the TIdSMTP.ReadTimeout instead of setting the IOHandler.ReadTimeout directly.

Code:

IdSSLIOHandlerSocketOpenSSL1.SSLOptions.Method := sslvTLSv1;
IdSSLIOHandlerSocketOpenSSL1.SSLOptions.SSLVersions := [sslvTLSv1];

You do not need to set both of those properties. They are mutually exclusive, setting one updates the other. So, set only one or the other, not both.

Code:

SMTP.ValidateAuthLoginCapability := true;

That property is only used when AuthType=satDefault.

But the Android system fails with a: "Doesn't support AUTH or the specified SASL handlers!!"

That error means the server's latest EHLO response does not specify any SASL mechanisms that match what you have configured in the TIdSMTP.SASLMechanisms collection.

I use the Android-type OpenSSL libraries, which are loaded correctly (and which are also used by the an IdTCPClient when connecting to an IdTCPServer)

This is not an SSL/TLS issue. You would be getting a completely different type of error if SSL/TLS were not working. The fact that you are getting any SMTP traffic logged at all after STARTTLS is finished means that SSL/TLS is working fine.

When I look at the debug output of the EXIM Server, it seems to me that the SASL authentication HAS in fact finished

No, it hasn't, because authentication hasn't been attempted yet when the error you are seeing occurs.

because the Server is already in TLS mode and is waiting for its first TLS packet

Encryption and Authentication are two completely different things.

Which it never gets.

Correct, because the error you are seeing is raised by TIdSMTP before it sends any AUTH command to the server.

SMTP<< EHLO localhost

An SMTP client should not be sending 'localhost' as its reported name. It should be sending its actual machine hostname. TIdSMTP has a HeloName property that you can set to any name you want. If HeloName is empty, GStack.HostName() is used, and if that is empty, then IndyComputerName() is used. None of those should be returning 'localhost'. If they are, that is a bug that needs to be fixed.

SMTP>> 250-apollo.bart.gen.nz Hello localhost [62.140.132.204]
250-SIZE 52428800
250-8BITMIME
250-PIPELINING
250-AUTH PLAIN
250-STARTTLS
250 HELP

That is the server's initial greeting. As you can see, when you first connect to the server, before SSL/TLS is activated, the only SASL available is PLAIN (as it doesn't require a secure connection).

SMTP<< STARTTLS

That is the client's request to initiate a SSL/TLS session.

SMTP>> 220 TLS go ahead

That is the server's response giving the OK to start an SSL/TLS handshake.

TLS active                              <<<<<<<<<<<<<<<<<<<<<<<<<
Calling gnutls_record_recv(0x7f323331eae0, 0x7f32336060a0, 4096)  <<<<<<<<<<<<<<< Its waiting here.

Which makes sense, since the SSL/TLS handshake is finished, and the server is waiting for the client's next (encrypted) SMTP command.

SMTP<< EHLO localhost           <<<<<<<<<<<<<<<<<<<<<< It seems the Client is trying again???

Yes, because it is supposed to. After an SSL/TLS session is established, the server's capabilities MAY change, so the client has to query the server again to get its updated capabilities. Most notably, SASLs that require a secure connection are not reported in the initial unencrypted EHLO but are reported in the subsequent encrypted EHLO.

However, as you can see in the log, the only change to the server's capabilities after a STARTTLS command is performed is that the STARTTLS capability disappears from the list, which makes sense as a new STARTTLS command is not allowed after a previous STARTTLS command is successful.

We can clearly see in the log that the AUTH capabilities are not changing after STARTTLS. In both unencrypted and encrypted modes, your server only supports PLAIN authentication.

You claim to have hooked up a TIdSASLPlain to TIdSMTP, but the ONLY way to get the error you are seeing is if TIdSMTP cannot find the TIdSASLPlain in the SASLMechanisms collection. Which means you HAVE NOT hooked it up correctly. It is not enough to just drop TIdSASLPlain onto your Form. You need to add an entry to the SASLMechanisms collection and set its SASL property to point at the TIdSASLPlain object. Double-check that is actually the case. And double-check that what you set at design-time is being loaded correctly at run-time.

Calling gnutls_record_recv(0x7f323331eae0, 0x7f32336060a0, 4096)      <<<<<<<<<<<< Waiting again. It stops here.

Again, because it is waiting for the client's next SMTP command.