On Mon, Oct 29, 2007 at 02:05:18AM +1100, Andrew McGlashan wrote: > Marc Haber wrote: > >> I want to be able to support the use of Incredimail against my mail > >> server without departing from my strict policy of using SMTP Auth > >> over port 465 with SSL security. > > > > Port 465 is an RFC violation anyway, it was never assigned for SMTP > > over SSL in the first place. Microsoft is the only instance who > > insists on using this non-standard. > > I have just re-configured my server to accept 25 / 265 and 587 for SSL/TLS > connections. > > 03_exim4-config_tlsoptions: > tls_on_connect_ports=465:587 > > AND in /etc/default/exim4 > SMTPLISTENEROPTIONS='-oX 587:465:25 -oP /var/run/exim4/exim.pid' > > Now.... I can send using port 25 or 465 both with SSL with OE, but 587 with > OE times out and eventually gives the same error on the server as does > IncrediMail -- although IM does it almost immediately.
The standardized usage of TCP/587 is STARTTLS, so technically, tls_on_connect_ports=587 is likely to confuse conforming clients. I do not have an idea how OE or Incredimail behave, but I wouldn't be surprised that they would choke when expecting a cleartext ESMTP handshake with STARTTLS and being presented with an on-connect TLS handshake. If you want to be sure, try finding out what IM and OE do when you have them connect to a netcat process on TCP/587 that immediately shows them a cleartext ESMTP greeting. If they respond with a cleartext EHLO, then you have your exim misconfigured and need to remove the 587 from tls_on_connect_ports. > GMAIL also breaks the RFC then as they only use port 465.... $ gnutls-cli -p 587 smtp.gmail.com -s Resolving 'smtp.gmail.com'... Connecting to '72.14.221.111:587'... - Simple Client Mode: 220 mx.google.com ESMTP 4sm12205522fge.8 EHLO test.client.example 250-mx.google.com at your service, [77.1.33.179] 250-SIZE 28311552 250-8BITMIME 250-STARTTLS 250 ENHANCEDSTATUSCODES STARTTLS 220 2.0.0 Ready to start TLS *** Starting TLS handshake - Certificate type: X.509 - Got a certificate list of 1 certificates. - Certificate[0] info: # The hostname in the certificate matches 'smtp.gmail.com'. # valid since: Mon Jul 30 18:58:07 CEST 2007 # expires at: Tue Jul 29 18:58:07 CEST 2008 # fingerprint: 32:66:6C:0A:DC:4F:2D:F9:83:2E:B4:AA:22:A7:E0:E7 # Subject's DN: C=US,ST=California,L=Mountain View,O=Google Inc,CN=smtp.gmail.com # Issuer's DN: C=ZA,ST=Western Cape,L=Cape Town,O=Thawte Consulting cc,OU=Certification Services Division,CN=Thawte Premium Server CA,[EMAIL PROTECTED] - Peer's certificate issuer is unknown - Peer's certificate is NOT trusted - Version: TLS 1.0 - Key Exchange: RSA - Cipher: 3DES 168 CBC - MAC: SHA - Compression: NULL 502 5.5.1 Unrecognized command 4sm12205522fge.8 EHLO test.client.example 250-mx.google.com at your service, [77.1.33.179] 250-SIZE 28311552 250-8BITMIME 250-AUTH LOGIN PLAIN 250 ENHANCEDSTATUSCODES quit 221 2.0.0 mx.google.com closing connection 4sm12205522fge.8 *** Fatal error: A TLS packet with unexpected length was received. *** Server has terminated the connection abnormally. $ This looks to me as they have a compliant submission agent on TCP/587 as well. > > The widely accepted standardized way to do secure SMTP is STARTTLS, > > which is kind of SMTP-over-SSL-over-SMTP and can be run on the > > standardized ports 25 (SMTP) and 587 (mail submission). > > > > But you are likely to fall into the same trap with your incredimail > > that way. > > IM will not work on port 25, 465 or 587. > > On my server, I can see the following: > > # netstat -an|grep -e 25 -e 465 -e 587|grep tcp > tcp 0 0 0.0.0.0:587 0.0.0.0:* LISTEN > tcp 0 0 0.0.0.0:465 0.0.0.0:* LISTEN > tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN > tcp 0 0 192.168.2.2:25 80.161.186.2:63657 > TIME_WAIT This indicates a TCP session that has already finished. > And when OE is 'waiting' on port 587 tests: > > # netstat -an|grep -e 25 -e 465 -e 587|grep tcp > tcp 0 0 0.0.0.0:587 0.0.0.0:* LISTEN > tcp 0 0 0.0.0.0:465 0.0.0.0:* LISTEN > tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN > tcp 0 0 192.168.2.2:587 192.168.0.158:2854 > ESTABLISHED That looks like the session is still up and either side is waiting. Might be possible that OE is waiting for a clear text SMTP banner while the exim (with smtp_on_connect_ports including 587) is waiting for a TLS handshake. Both sides will wait until timeout. > When I give up on the waiting, the following is sent to > /var/log/exim4/mainlog: > > 2007-10-29 02:06:07 TLS error on connection from [192.168.0.158] > (gnutls_handshake): A TLS packet with unexpected length was received This is also an indication of exim expecting the remote side to talk TLS while the remote side isn't. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]