> > They require authenticating smtp with ssl, > > There's multiple ways of doing that. Are they any more specific?
No, unfortunately. > Before we get into this, let me explain the basic options here. There > are three different protocol-level variations on basic SMTP service: > SMTP, SMTPS, and Submission. The first, plain old SMTP on port 25, is > unencrypted. Some (many, these days) servers support the STARTTLS > command, which allows the connection to be encrypted AFTER it has been > established. The second, SMTPS, is encrypted from the very first > packet. As SMTP is supposed to be on port 25, SMTPS is supposed to be > on port 465. There is no unencrypted version of SMTPS; it's *always* > encrypted. The third, Submission, is virtually identical to SMTP, > except that you must authenticate yourself (in a manner identical to > SMTP-AUTH) before you can submit email. It is ALSO unencrypted, and > ALSO usually supports the STARTTLS command to begin encrypting the > connection after it has been established. Because it is so similar, > this is almost always handled by telling the sending application to > use SMTP on an alternate port (namely, the Submission port, 587). > > Generally speaking, SMTP clients detect the availability of the > STARTTLS command and opportunistically use it; that applies to both > SMTP and Submission, since they're so similar. Thanks, this is helpful. [snip] > Your alternative is to use the Submission protocol? I don't know what my alternatives are (or, didn't until you just explained the three flavors of SMTP-ing). > ... let me guess, you told mutt to use SMTPS on the Submission > port, rather than telling mutt to use SMTP on the Submission > port. Indeed I did tell mutt to do that (unknowingly). > > SSL failed: error:140770FC:SSL > > routines:SSL23_GET_SERVER_HELLO:unknown protocol > > Connected to new.domain.com:587 on fd=-1 mutt_socket_close: > > Attempt to close closed connection. > > Looks like I guessed right. Your mistake was to use this: > > set smtp_url=smtps://new.domain.com:587 > > That tells mutt to use SMTPS on port 587. Since that means mutt > expects the very first packet to be encrypted, and the very first > packet WASN'T encrypted, the "connection" failed. If you had done > this: > > set smtp_url=smtp://new.domain:587 > > ...it probably would have worked. Your mistake is assuming that > "smtps://" means encryption and that "smtp://" means no encryption. In > reality, "smtps://" means the SMTPS protocol and "smtp://" means the > SMTP (or Submission) protocol. > > Does that make sense? Yes, it does, thanks. I did in fact assume that "smtps" means "secure" and "smtp" means "non-secure". (Being brought up with GUI apps that have just one checkbox for "authenticate" or "secure" or "SSL" one can easily think this is an either-or scenario). [snip] > > I even tried reverting to msmtp, but couldn't get that to work at > > all. Msmtp would tell me that the server doesn't understand TLS, > > Interesting. Am I correct in assuming that msmtp is connecting to port > 25? I got that with both port 587 and whichever port msmtp uses by default. > > I cannot tell if this is a bug in the new system, in mutt, or with > > my setup. > > It's most likely a problem with your setup. To recap, try this: As expected :) > > set smtp_url=smtp://new.domain.com:587 This seems to work so far. Many, many, many thanks. > I'm assuming that you're handling the smtp username and password > elsewhere (e.g. via smtp_user); otherwise, you'll need to set that up > as well. smtp_user is not in the manual for 1.5.19hg, and mutt tells me "unknown variable" when I start mutt if I have an smtp_user in my muttrc. I had put it in the muttrc, before I even read your email, because something in the back of my mind was telling me that such a setting existed (probably it did but has been removed). I'd been doing stmp_url=u...@blah.blah to get the user in there. -gmn
