[Oberon] SMTP/SSH tunnel
W B Hacker
wbh at conducive.org
Thu Mar 22 21:37:53 MET 2007
> I'm still trying to make the SMTP/SSH tunnel work.
> In SSH.Tool this is one of Guenter's examples.
> SSH.StartForwarding fld at relayhost 1025:mailhost:25 ~
> In this case, would Mail.Mod be recompiled with
> DefSMTPPort* = 25? If so, what is the point other
> than consistency with the tunnel port?
> Thanks, ... Peter E.
You may be trying to work to the wrong port on the MTA.
An MTA will normally accept on port 25 either an un-encrypted session or
'STARTTLS', wherein an SSL3/TLS session is advertised by the calle-ed server at
HELO/EHLO, selected by the caller, negotiated, and set up.
No public-facing MTA that I am aware of will accept an 'always on' SSL tunnel on
port 25. That would cut it off from receiving any but specially-configured
private network traffic as no 'call-ing' MTA otherwise makes contact in SSL.
An SSL session used to be accepted on the de-facto 'submission' port, 465. After
over a dozen years of controversy, port 465 was was reassigned by IETF/IANA to a
Cisco proprietary protocol WEF February 2006. The Coisco protocol has nothign to
do with smtp.
The'official' submission port is now 587, and it is *normally* configured for
TLS with the same HELO/EHLO and negotiation as port 25, Not all ISP insist on an
encrypted connection, but many do so.
The RFC applicable to port 587, however, does note that other security means
besides TLS might be wanted - 'tunnels' included - and permits these since 587
is regarded as a 'local' issue. IOW - if you run some other protocol on that
port, IPX/SPX or MAP/TOPS if it rocks your boat - you affect only your own user
community, not the world at large as you would do with forced-SSL on port 25.
So - unless the tool you are using can do 'proper' recognition of the call-ed
server's HELO/EHLO advertisement, make the STARTTLS selection, *then* exhange
keys and establish an ad-hoc TLS session, follow by tearing it down on receipt
of the smtp '250 OK ....', it should simply not work.
IF the MTA you are 'talking to' still supports port 465 SSL you can try that.
ELSE you would need to control the MTA AND it be one that can do as it is told
w/r port usage.
Exim is one such MTA that can be told to do the unusual.
All it needs is 'tls_on_connect_ports = 465 : 587' and port 587 no longer uses
the HELO/EHLO advertising or STARTTLS handshakes - is ready to go directly into
an SSL session (which, BTW has its OWN handshakes, as an scp or ssh with the -v
flag will illustrate).
Finally - 'aiming' at port 25 - plain or encrypted - from a dynamic IP in a
broadband pool is increasingly being firewalled by connectivity providers as an
Best to use 587.
fixed IP is being
More information about the Oberon