Error "Operation now in progress" on Ubuntu about swift-smtp HOT 20 CLOSED

I suspect that error is coming from the underlying socket library Swift-SMTP is using. And since you're getting the same error regardless of port, the error may be happening when the client is trying to connect to the hostname. I have never used Postfix, but maybe instead of 127.0.0.1, you can try the FQDN.

That said, Swift-SMTP always tries to authenticate. If the ehlo command returns no supported auth methods (cramMD5, login, plain, xoauth2), an error is thrown. I can apply a fix to also try no authentication.

from swift-smtp.

Got the same error and code on OS X when trying to connect to invalid host (mistyped host name).

Fixed the hostname, but still getting the same error in different place:
It first tries to connect to port 587, sends 'starttls', then tries to reconnect to "Ports.ssl" (465) which my server is not listening on and fails...

func loginToServer() throws {
        var serverInfo = try getServerInfo()

        if doesStarttls(serverInfo) {
            try starttls(ssl)
            try connect(Ports.ssl.rawValue) // <- fails here
            serverInfo = try getServerInfo()
        }

Should it also use port 587 there?

from swift-smtp.

@zmeyc What you're saying sounds correct. I will test this.

from swift-smtp.

@zmeyc It probably shouldn't use port 587 there. Typically, 465 should be used there. But since it seems like your server (and thus potentially other servers) aren't listening on 465 for SSL, an option to specify which SSL port to listen should be added. I'll work on this.

from swift-smtp.

Is it possible for you to share what server this is so I can try to test locally?

from swift-smtp.

@Obbut sorry for the very late response. I have had other team commitments. I will also try to implement no auth as well. How did you run a local SMTP server that requires no auth? (so I can test my fixes locally)

from swift-smtp.

https://en.wikipedia.org/wiki/Opportunistic_TLS
https://tools.ietf.org/html/rfc3207

I've read up a bit about STARTTLS and it looks like the client shouldn't reopen connection at all and handshake should look like:

S: <waits for connection on TCP port 25>
   C: <opens connection>
   S: 220 mail.imc.org SMTP service ready
   C: EHLO mail.example.com
   S: 250-mail.imc.org offers a warm hug of welcome
   S: 250-8BITMIME
   S: 250-STARTTLS
   S: 250 DSN
   C: STARTTLS
   S: 220 Go ahead
   C: <starts TLS negotiation>
   C & S: <negotiate a TLS session>
   C & S: <check result of negotiation>
   C: EHLO mail.example.com
   S: 250-mail.imc.org touches your hand gently for a moment
   S: 250-8BITMIME
   S: 250 DSN

This article has a good overview: https://www.fastmail.com/help/technical/ssltlsstarttls.html

Currently, things seem relatively randomly split between people using SMTP SSL/TLS encrypted over port 465, and people using SMTP with STARTTLS upgrading over port 587.

It seems mine is using the latter. It's Mail-in-a-box installation, I can email it's address for testing if needed.

from swift-smtp.

I tried changing the port to 587, but it hangs up inside of second call to connect() indefinitely.

from swift-smtp.

Is there a way for you to look up the regular/SSL ports your server uses?

from swift-smtp.

It's using:

SMTP Submission (port 587). Mail users submit outbound mail through SMTP with STARTTLS on port 587.
IMAP/POP (ports 993, 995). Mail users check for incoming mail through IMAP or POP over TLS.

Additionally:

SMTP Submission (port 587) will not accept user credentials without STARTTLS (true also of SMTP on port 25 in case of client misconfiguration), and the submission port won't accept mail without encryption. The minimum cipher key length is 128 bits. (The box is of course configured not to be an open relay. User credentials are required to send outbound mail.) (source)

Incoming Mail

Encryption

As discussed above, there is no way to require on-the-wire encryption of mail. When the box receives an incoming email (SMTP on port 25), it offers encryption (STARTTLS) but cannot require that senders use it because some senders may not support STARTTLS at all and other senders may support STARTTLS but not with the latest protocols/ciphers. To give senders the best chance at making use of encryption, the box offers protocols back to TLSv1 and ciphers with key lengths as low as 112 bits. Modern clients (senders) will make use of the 256-bit ciphers and Diffie-Hellman ciphers with a 2048-bit key for perfect forward secrecy, however.

https://github.com/mail-in-a-box/mailinabox/blob/master/security.md

from swift-smtp.

Based on:

TLS certificates are generated with 2048-bit RSA keys and SHA-256 fingerprints. The box provides a self-signed certificate by default. The setup guide explains how to verify the certificate fingerprint on first login. Users are encouraged to replace the certificate with a proper CA-signed one. (source)

and

SMTP Submission (port 587) will not accept user credentials without STARTTLS (true also of SMTP on port 25 in case of client misconfiguration), and the submission port won't accept mail without encryption. The minimum cipher key length is 128 bits. (The box is of course configured not to be an open relay. User credentials are required to send outbound mail.) (source)

maybe one thing you can try is initializing your SMTP struct with a custom SSL passed in:

let ssl = SSL(withCipherSuite: "yourCipherSuiteString", clientAllowsSelfSignedCertificates: true)

And also force it to use 587 for both normal and TLS ports.

from swift-smtp.

Done. Same problem, stuck in sslReadCallback on:

		// Read the data from the socket...
		let bytesRead = read(socketfd, data, bytesRequested)

from swift-smtp.

If I try setting breakpoints while it's stuck it exits with:

MessageTracer: load_domain_whitelist_search_tree:73: Search tree file's format version number (0) is not supported
MessageTracer: Falling back to default whitelist
Error code: -36(0x-24), ERROR: SSLHandshake, code: -36, reason: errSecIO

from swift-smtp.

I think on reconnect it tries to use smtps which isn't supported on port 587, but it doesn't fail and hangs up.

from swift-smtp.

So this is at the BlueSSLService layer, though may not be the only problem. @billabt do you have any thoughts on this?

from swift-smtp.

To make sure it's not server problem, I tried Ruby's mail gem:

Gemfile

source "https://rubygems.org"

gem 'mail', '~> 2.7'

send_email.rb

#!/usr/bin/env ruby

require 'rubygems'
require 'bundler/setup'
Bundler.require(:default)

require 'mail'

MAIL_FROM = '[email protected]'
MAIL_TO = '[email protected]'

MAIL_REPORTING_ENABLED = false
MAIL_DELIVERY_METHOD = :smtp
MAIL_OPTIONS = {
    :address              => "mailserver.com",
    :port                 => 587,
    :user_name            => '[email protected]',
    :password             => 'mypassword',
    :authentication       => 'plain',
    :enable_starttls_auto => true
}
Mail.defaults do
  delivery_method MAIL_DELIVERY_METHOD, MAIL_OPTIONS
end
Mail.deliver do
  from     MAIL_FROM
  to       MAIL_TO
  subject  "Test subject"
  body     "Hello\n"
end

gem install bundler
bundle install
ruby send_email.rb

And curl:

curl -v --url 'smtp://mailserver.com:587' --ssl-reqd \
  --mail-from '[email protected]' --mail-rcpt '[email protected]' \
  --upload-file body.txt --user '[email protected]:password' --insecure

Both are working.

from swift-smtp.

I can’t right now. Dealing with a death in the family. Monday at the earliest.

from swift-smtp.

My deepest condolences Bill. Please take your time.

from swift-smtp.

@zmeyc 3.0.0 has been released that brings some API and internal changes. Do you want to give it a try and see if it solves your problem? See the migration guide here.

from swift-smtp.

@zmeyc I got this error a few times, and realized it was because I was setting the timeout too low (I was setting it to something like 10 milliseconds). The latest version should multiply the timeout parameter by 1000 (so a value of 10 should be 10 seconds). Maybe this will fix your issue. I'm going to close this for inactivity, please feel free to open if you still see issues.

from swift-smtp.