← Back to team overview

vm team mailing list archive

Re: [Question #108267]: stunnel on Windows

 

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.