General OS error while establishing a connection with iCloud SMTP

[Nexus-6]

I already investigated this issue in the past to no avail, until yesterday. The symptom is that attempting to connect to smtp.mail.me.com results in a connection error. More specifically, iCloud SMTP should be listening to port 587 (TLS). Either configuring in the Outgoing panel smtp.mail.me.com with SSL or smtp.mail.me.com:587 alway result in a cryptic General OS error showed by the mail daemon log windows. Digging in the SMTP outbound SMTP addon, the problem seems to be in the call to status_t SMTPProtocol::Open(const char *address, int port, bool esmtp) and more specifically in fSocket->Connect(addr).

I have reproduced the code above in an isolated simple console application and the result is the same, unless at some point by trying all sorts of combinations of ports, it connected and trying to send an email worked! Until I rebooted. This time I had to do some additional voodoo, after succesfully trying to connect with this small test app I had to restart the mail_demon. The voodoo, although I'm not certain of what the sequence exactly is and what triggers this behaviour, consists of a ping to the address of the smtp server and an attempt to connect via terminal with openssl s_client -connect smtp.mail.me.com:587 -crlf or openssl s_client -connect smtp.mail.me.com:587 -crlf

I should add that neither openssl consistently connects. No other SMTP server I have tried has this issue, but I have not tried a single one with the triple dot in the hostname. It maight sound silly but this is the only difference I can see, considering we barely are the transport layer.

Note: hrev 57257

[Nexus-6]

Old syslog for comparison

[Nexus-6]

simple code to test connection to iCloud SMTP server

[Nexus-6]

A quick update: today there was no way to connect to the smtp server neither with my test app nor with Mail Kit. Openssl is the only one that worked just with port 587.

Then I modified my test code to force a connection without ssl before attempting a secure connection, that means using BSocket instead of BSecureSocket. Doing this, BSocket failed but the secure connection on port 465 was established and Mail Kit began to work again!

This is very weird, indeed.

[nephele]

Please don't add random keywords :)

[waddlesplash]

Please record an strace (make sure to specify the flag to trace all threads) to see what's happening, and upload the log here.

[Nexus-6]

Replying to nephele:

Please don't add random keywords :)

You might not agree with my selection but rest assured they were all but random. And more importantly, this issue is not with the mail daemon but with the network stack as demonstrated by my tests. May I suggest reverting back to the previous one?

[Nexus-6]

new version of the code which strace is run against

[waddlesplash]

[  6334] connect(0x4, {AF_INET, 17.57.156.26/465}, 0x20) = 0x80007020 Connection refused (114654 us)

[Nexus-6]

This is not a surprise, maybe there’s a problem with the way BSecureSocket tries to establish a connection that iCloud doesn’t like most of the times. For the records, other clients (including Beam) connect without any issue.

[waddlesplash]

The socket options might provide a clue. A strace for comparison may help.

[nephele]

Tags are ment for developers to organize tickets a bit more, if you add keywords like "error" that is noise making this harder. Unless you know some developer wants a certain tag or you need those yourself for your tickets please refrain from adding them.

[Nexus-6]

Replying to waddlesplash:

The socket options might provide a clue. A strace for comparison may help.

I wasn’t able to set custom socket options via BSecureSocket unless I missed something obvious? I’ve tried instead to bypass it and establish the connection via socket(), setsockopts() and connect() but whatever option I set I can’t connect. socket() returns a bad file descriptor so I must be doing something wrong.

[waddlesplash]

If socket() returns a bad FD, you should be able to check errno (or just look at strace) to see what went wrong.

At this point you will likely need to use packet capture to determine why the remote server rejected the connection request.

[waddlesplash]

Also, error propagation in Mail should be fixed so it displays the proper "Connection refused" instead of "OS error".