Patch info for smtp_martin

Author Comments

The problem:
  To: stunnel-users@mirt.net
  Date: Mon, 23 Apr 2001 19:28:05 +0200
  From: Martin Germann <martin.germann@gmx.net>
  Subject: SMTP over TLS

  I have some problems using stunnel as a TLS-Wrapper for SMTP.
  Everything works fine until stunnel sends "250 STARTTLS" to the client.
  Stunnel seems to ignore the response of the client and waits for the
  handshake even if the clients response is not "STARTTLS" (see log
  below).
  
  [...]
  Remote host connected
  Negotiations for smtp(server side) started
  RFC 2487 detected
   <- 220 SMTP-Server  Vr. 1.3 (Build 1.3.22.55) is ready.
   -> 220 SMTP-Server  Vr. 1.3 (Build 1.3.22.55) is ready. + stunnel
   <- EHLO mycomputer
   -> 250-mycomputer Welcome
   -> 250 STARTTLS
   <- no i won't
   -> 220 Go ahead
  before/accept initialization
  [...]
  There is another problem in client mode with SMTP-over-TLS (patch from
  Oliver Mandischer): The first command in the SMTP session should be
  EHLO (RFC 1869), but instead stunnel will send just STARTTLS.
  
  As I am a very bad programmer, I hope to get some comments or
  suggestions. Thanks in advance,
  
  Martin Germann

The Patch:

  To: stunnel-users@mirt.net
  Date: Wed, 25 Apr 2001 18:55:50 +0200
  From: Martin Germann <martin.germann@gmx.net>
  Subject: Re: SMTP over TLS

  Here is a revised Version of the client_smtp_om.patch. Of course,
  "localhost" isn't the real domain name. The real domain name will be
  transmitted encrypted.
 

This website makes patches available for use by the Internet community. However it does not endorse any of the patches contained herein. They could be work perfectly, or totally foul up everything. We don't know. Contact the authors if you have any questions. Use at your own risk.

The Stunnel software package does not contain any cryptography itself, however please remember that import and/or export of cryptographic software, code providing hooks to cryptographic algorithms, and discussion about cryptography is illegal in some countries. It is imperative for you to know your local laws governing cryptography. We're not liable for anything you do that violates your local laws.