| Thread Previous • Date Previous • Date Next • Thread Next |
Question #108267 on VM changed: https://answers.launchpad.net/vm/+question/108267 Alan Wehmann posted a new comment: I only became aware of this discussion as of the last two entries, since I didn't subscribe to the mailing list until after the July 19, 2011 announcement that use of gnu.emacs.vm.info was deprecated. And it is only now that I read the earlier entries. Unaware of this discussion I attempted to use "gnutls" (http://www.gnu.org/software/gnutls/download.html and http://homes.esat.kuleuven.be/~nikos/gnutls-win32/) and the Emacs SMTP Library code (GNU Emacs 23.3.1 (i386-mingw-nt5.1.2600) of 2011-03-10 on 3249CTO) to send some test emails via smtp.gmail.com. After changing line "(set-buffer-process-coding-system 'raw-text-unix 'raw-text-unix)" to read "(set-buffer-process-coding-system 'raw-text-dos 'raw-text-dos)" in function "smtpmail-via-smtp" in file "smtpmail.el", and changing line "(smtpmail-send-command process (format "STARTTLS"))" to read "(smtpmail-send-command process (format "STARTTLS\n"))", I got to line "(starttls-negotiate process)" and learned about the inability of MS Windows to send alarm 'SIGALRM to begin the TLS negotiation. Had I read the discussion here, I would have saved myself some time. Along the way I tried using "gnutls-cli-debug" in a shell buffer (using bash) as "gnutls-cli-debug -V -p 587 smtp.gmail.com" and got output that said that TLS wasn't supported. But use of "gnutls-cli -s smtp.gmail.com -p 587 -V" got me the following trace: Resolving 'smtp.gmail.com'... Connecting to '209.85.225.109:587'... - Simple Client Mode: - Received[45]: 220 mx.google.com ESMTP mk10sm12619292igc.4 EHLO DELLLAPTOP - Sent: 16 bytes - Received[125]: 250-mx.google.com at your service, [108.89.145.141] 250-SIZE 35882577 250-8BITMIME 250-STARTTLS 250 ENHANCEDSTATUSCODES STARTTLS - Sent: 9 bytes - Received[30]: 220 2.0.0 Ready to start TLS Upon entering an EOF character I got more output, indicating the TLS negotiation was underway. I eventually gave up on using TLS and gnutls (with Emacs). I considered using "starttls" at "http://www.opaopa.org/pub/elisp/"; or Cygwin's "msmtp", but decided instead to use "stunnel" from Cygwin in the same manner that VM uses it to connect to e.g. a POP server. I modified function "smtpmail-via-smtp" in "smtpmail.el" so that it used "stunnel" in this manner and was successful in sending test mails via "smtp.gmail.com:465". I am still curious as to the meaning of INTERNAL ERROR: Bad magic at /home/ASchulma/dev/cygwin/stunnel/stunnel-4.49-1/s 6 [sig] stunnel 3920 open_stackdumpfile: Dumping stack trace to stunnel.exe.stackdump that appears in the trace buffer after the QUIT is issued and accepted (to end the server session). I checked that and this same error message also occurs with VM reading email with pop.gmail.com:995--via stunnel. -- You received this question notification because you are a member of VM development team, which is an answer contact for VM.
| Thread Previous • Date Previous • Date Next • Thread Next |
