Quoting Thomas Schmitt (scdbac...@gmx.net): > Hi, > > i wrote: > > > I get a connection to the SMTP server directly by this line > > > in ~/.pinerc: > > > smtp-server=mail.gmx.net/ssl/user=my_user...@gmx.net > > David Wright wrote: > > I assume that you're telling me that this does not work, right? > > Yes. It connects, alpine asks for the SMTP password, and then > it reports the error text which i assume is from SMTP error 503 > issued by the server. > > > > The stunnel port works fine with my own SMTP client > > > I'm not certain what you mean by your own "SMTP client". > > A while ago i had to make a program which uses TCP/IP to > connect to a server and performs an SMTP dialog to > hand over mail headers and a mail body. During the years > it learned some ESMTP because gmx.net more and more drifted > away from plain RFC 821. > > So i know one working sequence of SMTP commands and use > it to send this mail. > > > > How do I know what's doing > > any encryption that *might* be done in this case. You don't > > appear to have told alpine to do any. > > My own SMTP client uses the program stunnel for the encryption. > Config file: > > client=yes > foreground=yes > debug=5 > pid= > sslVersion=all > [gmx_smtp] > accept=30029 > connect=mail.gmx.net:465 > > My client connects to port 30029 and stunnel connects to gmx.net. > > I can direct alpine unencrypted to port 30029 and see the same > effect as with alpine's own encryption via "/ssl/" or "/tls/".
I'm sorry if I appear to be thick but I get very little sense from "see the same effect as with alpine's own encryption". I can't be certain what works and what fails when you express it like that. > So alpine's encryption seems ok, because there happens an SMTP > dialog between alpine and gmx.de. Again, I have no idea what you actualy observe when you write those words. > > I don't see anything on this website about alpine, only pine. > > alpine is pine's official rewrite. > http://www.washington.edu/alpine/overview/story.html I ran the washington webpages http://www.washington.edu/pine/tech-notes/config-notes.html and http://www.washington.edu/alpine/tech-notes/config-notes.html through diff and the only significant difference appeared to be the addition of s/mime to alpine. I cannot find the string "starttls" anywhere on the washington website, inclusing a search at http://www.washington.edu/alpine/search.html viz: Alpine Information Center Search Results Note: this searchable index does not include the Alpine-Info archives.master.com starttls [Search][Options] No documents match the query. Try using different or fewer search terms. > GMX published: > > 'Wenn Ihr Programm die Verschlüsselungsprotokolle SSL und StartTLS > > nicht ausdrücklich anbietet, genügt es oft auch, einfach eine > > "verschlüsselte" Verbindung zu aktivieren. Das Protokoll wird in > > diesem Fall automatisch ausgewählt.' > > Translation: > If your your program does not explicitly offer the encryption > protocols SSL and StartTLS, it often suffices to simply activate > an "encrypted" connection. The protocol will be chosen > automatically in this case. > > > It seems to suggest some sort of fallback, but how it works I don't know. > > They obviously refer to any mail client which offers > encryption in some of its menus. Well, I tried it out and didn't get very far. Of course, I don't know how to "not explicitly offer the encryption protocols SSL and StartTLS" when I try to connect with an encryption-handling program (openssl). Anyway, mail.gmx.net appeared to work perfectly normally on 587: $ openssl s_client -starttls smtp -crlf -connect mail.gmx.net:587 CONNECTED(00000003) depth=2 C = DE, O = Deutsche Telekom AG, OU = T-TeleSec Trust Center, CN = Deutsche Telekom Root CA 2 verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 0 s:/C=DE/O=1&1 Mail & Media GmbH/ST=Rhineland-Palatinate/L=Montabaur/emailAddress=server-ce...@1und1.de/CN=mail.gmx.net ... PSK identity: None PSK identity hint: None SRP username: None Start Time: 1437965426 Timeout : 300 (sec) Verify return code: 19 (self signed certificate in certificate chain) --- 250 STARTTLS ehlo junk 250-gmx.com Hello junk [000.000.000.000] 250-SIZE 69920427 250 AUTH LOGIN PLAIN ^C as I have nothing more to say. I can't start 587 as an encrypted connection: $ openssl s_client -connect mail.gmx.net:587 CONNECTED(00000003) 3073545916:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:795: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 295 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE --- $ which appears normal. However, 465 seems to behave oddly: $ openssl s_client -connect mail.gmx.net:465 CONNECTED(00000003) depth=2 C = DE, O = Deutsche Telekom AG, OU = T-TeleSec Trust Center, CN = Deutsche Telekom Root CA 2 verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 0 s:/C=DE/O=1&1 Mail & Media GmbH/ST=Rhineland-Palatinate/L=Montabaur/emailAddress=server-ce...@1und1.de/CN=mail.gmx.net ... PSK identity: None PSK identity hint: None SRP username: None Start Time: 1437965342 Timeout : 300 (sec) Verify return code: 19 (self signed certificate in certificate chain) --- 220 gmx.com (mrgmx001) Nemesis ESMTP Service ready ehlo junk ^C as it hung. I would have expected a reply here, or to be thrown off. > > You probably know a lot more about alpine > > Rather not. I always used pine but never dived into its entrails. > > > http://www.washington.edu/alpine/tech-notes/config-notes.html > > "If the attempt to use TLS fails then this parameter > > will cause the connection to fail instead of falling back to an > > unsecure connection." > > Doesn't the last sentence explain what is happening to your > > connection? > > It does not predict SMTP error 503 which is about protocol > problems, not connection or encryption. > Further the experiment with alpine and stunnel shows no > difference in behavior. stunnel itself works fine with gmx.de. > > > Have you tried using mail.gmx.net:465/tls/user=th.schm...@gmx.net > > 465 would be the wrong port, i assume. > Well, i now tried. alpine waits a while and then reports: > [Error sending: Connection failed to mail.gmx.net,465: Connection timed out] > This happens before i get asked by alpine for the password, > which it probably does when the server replies to an early > SMTP command by error 530 "Authentication required". AIUI 465 was once used for ssmtp and is widely supported but non-standard. I could use it myself but prefer starttls on a weird high port. > > Mind you, I'm not convinced you'll have any joy but I'd be interested > > to know. It looked to me as if it wants to see a certificate to let > > you connect, and I see no provision in alpine for that either. (Only > > for signing emails etc.) > > Certificate problems look different. > I can tell from running an 8 year old system in today's internet. If you say so. I don't know how to interpret verify error:num=19:self signed certificate in certificate chain above. > > So I still think you need to turn on the logging. > > If i only could find some option for that in alpine or stunnel. > Packet sniffers won't help because of encryption. I just looked back at some 18-year old emails and rediscovered why I stopped using Debian pine. It wouldn't play well when the university upgraded its IMAP server from a beta to a production version. I couldn't log the conversation because pine had been compiled without the debug option. At the time, I held the view that the debug option needed to be set in the production version of pine so that the conversations could be logged. The Debian maintainer at the time held the view that because compiling without the debug flag was the only way he could prevent the creation of those "ugly" (his word), that was the way Debian's pine would be distributed. My view was that both parties were wrong; pine for requiring a compiler's debug flag (surely for debugging the pine code) to be set before logging could be turned on by the runtime -d flag, and Debian for not accepting pine's problem and compiling with the debug flag so that users could use the full functionality of the program. My solution was to run pine on the university's unix service through ssh. It didn't take long to discover I could build mutt there easily! So check if alpine has the same problem. BTW I assume the same problem as yours is reported at http://www.linuxforums.org/forum/networking/203061-alpine-setup-ok-unable-send-email.html Cheers, David. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150727153736.GA7765@alum
