Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
idSMTP SASL fails under Android..?
#1
Question 
This post is a copy of the one I just posted on the Embarcadero forum.
Just want to see how it works here.

----
I am stumped by this.

I have my Windows client using IdSMTP to connect to my Linux EXIM4 server.
This always works perfectly.

I copied the entire unit over to my new Android App, that is, I copied the .pas file, and I made a new FMX Form for it on which I copied the exact same selection of SMTP, SSL and SASL etc. components.
I have set these up on the Form in exactly the same way.
Added the same 3 SASL Mechanisms in the IdSMTP and in the same order.
As far as I can see it is all exactly the same.

{code}
   SMTP: TIdSMTP;
    IdSSLIOHandlerSocketOpenSSL1: TIdSSLIOHandlerSocketOpenSSL;
    IdUserPassProvider1: TIdUserPassProvider;
    IdSASLPlain1: TIdSASLPlain;
    IdSASLSKey1: TIdSASLSKey;
    IdSASLCRAMMD51: TIdSASLCRAMMD5;
    IdSASLCRAMSHA11: TIdSASLCRAMSHA1;
    IdSASLLogin1: TIdSASLLogin;

  procedure:
 (Note this works perfectly under Windows)
            if UsePLAINSASL then
            begin
              if Superuser then LocalLog('UsePLAINSASL: Logging in with Username='+AUsername);
              SMTP.Username := AUsername;
              SMTP.Password := APassword;
              IdUserPassProvider1.Username := AUsername;
              IdUserPassProvider1.Password := APassword;
              IdSASLPlain1.LoginAs := AUsername;

              SMTP.AuthType := satSASL;
              SMTP.UseEhlo := true;

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

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

              SMTP.UseTLS := utUseExplicitTLS; // utNoTLSSupport; //
              SMTP.ValidateAuthLoginCapability := true;
            end else
{code}

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

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)

When I look at the debug output of the EXIM Server, it seems to me that the SASL authentication HAS in fact finished, because the Server is already in TLS mode and is waiting for its first TLS packet. Which it never gets.

The Server shows this:
{code}
17925 Listening...
17925 Connection request from 62.140.132.204 port 18027

17927 SMTP>> 220 apollo.bart.gen.nz ESMTP Exim 4.80 Wed, 18 Apr 2018 13:24:42 +0200
17927 Process 17927 is ready for new message
17927 smtp_setup_msg entered
17927 SMTP<< EHLO localhost
17927 localhost in helo_lookup_domains? no (end of list)
17927 sender_fullhost = (localhost) [62.140.132.204]
17927 sender_rcvhost = [62.140.132.204] (helo=localhost)
17927 set_process_info: 17927 handling incoming connection from (localhost) [62.140.132.204]
17927 host in pipelining_advertise_hosts? yes (matched "*")
17927 host in auth_advertise_hosts? yes (matched "*")
17927 host in tls_advertise_hosts? yes (matched "*")
17927 SMTP>> 250-apollo.bart.gen.nz Hello localhost [62.140.132.204]
17927 250-SIZE 52428800
17927 250-8BITMIME
17927 250-PIPELINING
17927 250-AUTH PLAIN
17927 250-STARTTLS
17927 250 HELP
17927 SMTP<< STARTTLS                  <<<<<<<<<<<<<<<<<
17927 initialising GnuTLS as a server
17927 GnuTLS global init required.
17927 initialising GnuTLS server session
17927 Expanding various TLS configuration options for session credentials.
17927 certificate file = /etc/exim4/exim.crt
17927 key file = /etc/exim4/exim.key
17927 TLS: cert/key registered
17927 verify certificates = /etc/ssl/certs/ca-certificates.crt size=272519
17927 Added 172 certificate authorities.
17927 Initialising GnuTLS server params.
17927 Loading default hard-coded DH params
17927 Loaded fixed standard D-H parameters
17927 GnuTLS using default session cipher/priority "NORMAL"
17927 host in tls_verify_hosts? no (option unset)
17927 host in tls_try_verify_hosts? no (option unset)
17927 TLS: a client certificate will not be requested.   <<<<<<<<<<<<<<<<<<<<<
17927 SMTP>> 220 TLS go ahead                            <<<<<<<<<<<<<<<<<<<<<
17927 Received TLS SNI "sartrack.nl" (unused for certificate selection)
17927 gnutls_handshake was successful                   <<<<<<<<<<<<<<<<<<<<
17927 TLS: no certificate from peer ((nil) & 0)
17927 cipher: TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256
17927 Have channel bindings cached for possible auth usage.
17927 sender_fullhost = [62.140.132.204]
17927 sender_rcvhost = [62.140.132.204]
17927 set_process_info: 17927 handling incoming TLS connection from [62.140.132.204]
17927 TLS active                              <<<<<<<<<<<<<<<<<<<<<<<<<
17927 Calling gnutls_record_recv(0x7f323331eae0, 0x7f32336060a0, 4096)  <<<<<<<<<<<<<<< Its waiting here.

17927 SMTP<< EHLO localhost           <<<<<<<<<<<<<<<<<<<<<< It seems the Client is trying again???
17927 localhost in helo_lookup_domains? no (end of list)
17927 sender_fullhost = (localhost) [62.140.132.204]
17927 sender_rcvhost = [62.140.132.204] (helo=localhost)
17927 set_process_info: 17927 handling TLS incoming connection from (localhost) [62.140.132.204]
17927 host in pipelining_advertise_hosts? yes (matched "*")
17927 host in auth_advertise_hosts? yes (matched "*")
17927 tls_do_write(0x7f32333012b8, 132)
17927 gnutls_record_send(SSL, 0x7f32333012b8, 132)
17927 outbytes=132
17927 SMTP>> 250-apollo.bart.gen.nz Hello localhost [62.140.132.204]
17927 250-SIZE 52428800
17927 250-8BITMIME
17927 250-PIPELINING
17927 250-AUTH PLAIN
17927 250 HELP
17927 Calling gnutls_record_recv(0x7f323331eae0, 0x7f32336060a0, 4096)      <<<<<<<<<<<< Waiting again. It stops here.

{code}
 

---
Bart Kindt
CEO & Developer
SARTrack Limited New Zealand
http://www.sartrack.nz
---
Bart Kindt
CEO and Developer
SARTrack Limited
New Zealand
www.sartrack.nz
Reply
#2
(04-18-2018, 02:44 PM)BartKindt Wrote: 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.

(04-18-2018, 02:44 PM)BartKindt Wrote:
Code:
SMTP.Username := AUsername;
SMTP.Password := APassword;

Those properties are only used when AuthType=satDefault.

(04-18-2018, 02:44 PM)BartKindt Wrote:
Code:
IdSSLIOHandlerSocketOpenSSL1.Port := APort;
IdSSLIOHandlerSocketOpenSSL1.Host := AHost;

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

(04-18-2018, 02:44 PM)BartKindt Wrote:
Code:
IdSSLIOHandlerSocketOpenSSL1.ReadTimeout := 10000;

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

(04-18-2018, 02:44 PM)BartKindt Wrote:
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.

(04-18-2018, 02:44 PM)BartKindt Wrote:
Code:
SMTP.ValidateAuthLoginCapability := true;

That property is only used when AuthType=satDefault.

(04-18-2018, 02:44 PM)BartKindt Wrote: 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.

(04-18-2018, 02:44 PM)BartKindt Wrote: 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.

(04-18-2018, 02:44 PM)BartKindt Wrote: 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.

(04-18-2018, 02:44 PM)BartKindt Wrote: because the Server is already in TLS mode and is waiting for its first TLS packet

Encryption and Authentication are two completely different things.

(04-18-2018, 02:44 PM)BartKindt Wrote: Which it never gets.

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

(04-18-2018, 02:44 PM)BartKindt Wrote: 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.

(04-18-2018, 02:44 PM)BartKindt Wrote: 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).

(04-18-2018, 02:44 PM)BartKindt Wrote: SMTP<< STARTTLS

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

(04-18-2018, 02:44 PM)BartKindt Wrote: SMTP>> 220 TLS go ahead

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

(04-18-2018, 02:44 PM)BartKindt Wrote: 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.

(04-18-2018, 02:44 PM)BartKindt Wrote: 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.

(04-18-2018, 02:44 PM)BartKindt Wrote: Calling gnutls_record_recv(0x7f323331eae0, 0x7f32336060a0, 4096)      <<<<<<<<<<<< Waiting again. It stops here.

Again, because it is waiting for the client's next SMTP command.
Reply
#3
Note:
There is a bug in the IDE in Delphi 10.2.3 (could also be in other versions), FMX only, where the design time adding of IdSMTP.SASLMechanisms is corrupted, the final component names in the .FMX file are incorrect, and as a result the SASL components are added as un-initialized items, which then cause an internal AV which is NOT reported, and the final result is that the SMTP SASL connection fails without reason.

By adding the SASL components at runtime, the problem can be overcome.

See the final discussion on this in the Embarcadero Winsock forum:

https://forums.embarcadero.com/thread.js...dID=397784

Bart
---
Bart Kindt
CEO and Developer
SARTrack Limited
New Zealand
www.sartrack.nz
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)