[Oberon] SMTP/SSH tunnel

[W B Hacker]

Easthope wrote:
> Folk,
> 
> 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 
anti-WInZombie measure.

Best to use 587.

HTH,

Bill Hacker


fixed IP is being