The command line you specified just establishes a connection and it's waiting for you to do something -- I think it's working as designed. Typically you'd pipe something from STDIN to create a message, or use it as a backend for another program. http://msmtp.sourceforge.net/doc/msmtp.html good luck :-)
Regards, Stephen J Alexander MPBX, LLC http://mpbx.com 832-713-6729 On Mon, May 14, 2012 at 2:38 PM, Scott Sjodin <scott.sjo...@gmail.com>wrote: > Ok, so I found the right certificate, but when I run a test with msmtp -a > default usern...@domain.com...it just hangs. Tried it with all three SSL > ports (465, 587, 25) with the same result....what happens now? I can't > troubleshoot without error messages... > > Thanks for everyone's assistance so far. > > > On Sun, May 13, 2012 at 10:00 PM, Ram <ram0...@gmail.com> wrote: > >> > From: Scott Sjodin <scott.sjo...@gmail.com> >> > Message-ID: >> > < >> caafaoiwep9zh3mceggtnq0kom4fzaa+yaj7qrkjgkycuolm...@mail.gmail.com> >> >> > So I've got my msmtp setup (almost). It's running. I can telnet in to >> > smtp.mydomain.com 587 and 25 and send over the creds (but not with 465) >> > successfully. I can run openssl, with 465 I get the following: >> > >> > >> > openssl s_client -CApath >> > /etc/ssl/certs/Equifax_Secure_Certificate_Authority.cer -connect >> > smtp.mydomain.com:465 >> > >> > Verify return code: 20 (unable to get local issuer certificate) >> > >> > When testing msmtp -a default usern...@domain.com I get the following >> > results (with port numbers corresponding to changes in the msmtprc file) >> > >> > >> > When I change up the port number to 587: >> > >> > msmtp: TLS certificate verification failed: the certificate is not >> trusted >> > When I change up the port number to 25: >> > msmtp: TLS certificate verification failed: the certificate is not >> trusted >> > When I change up the port number to 465: >> > msmtp: network read error: Connection reset by peer. >> > >> > My msmtprc file is listed below: >> > >> > defaults >> > tls on >> > tls_starttls on >> > tls_trust_file /etc/ssl/certs/Equifax_Secure_Certificate_Authority.cer >> > >> > #this was downloaded direct from GeoTrust's website - >> > #http://www.geotrust.com/resources/root-certificates/index.html >> >> I suspect the server does not have it's certificate installed properly >> - specifically the intermediate or chain certificate is probably not >> installed/configured. Ideally this would be fixed on the server side >> but you can work around it by adding the correct chain certificate(s) >> to the client trusted certificate list. >> >> As a test try going to that same port and dump the certificates it >> offers up like so: >> # openssl s_client -connect example.com.:443 >> >> You should see a section in the output like so: >> --- >> Certificate chain >> 0 s:/serialNumber=1234/C=US/O=example.com/OU=NoAuthFromUs/OU=See >> someurl/cps >> <http://example.com/OU=NoAuthFromUs/OU=Seesomeurl/cps>(c)11/OU=Domain >> Control Validated - >> RapidSSL(R)/CN=example.com >> i:/C=US/O=GeoTrust, Inc./CN=RapidSSL CA >> 1 s:/C=US/O=GeoTrust, Inc./CN=RapidSSL CA >> i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA >> 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA >> i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority >> >> >> You should see three entries (0, 1, 2) though the names will be >> different than above. If you only see two then the the chain >> certificate is missing from the server. >> >> cheers >> > >