On Tuesday 06 September 2011 13:59:20 Matthias Andree wrote:
> Am 06.09.2011 19:30, schrieb Wietse Venema:
> > Matthias Andree:
> >> Greetings,
> >>
> >> I am in a situation where I would like to achieve either of
> >> these solutions:
> >>
> >> Alternative A:
> >>
> >> - have Postfix's smtp client talk through a command via
> >> stdin/stdout (instead of a TCP stream).
> >
> > Can you describe the problem instead of the solution? There may
> > be other solutions than the ones you have in mind.
>
> The problem is this:
>
> - I cannot connect to the remote SMTP relayhost via plain TCP, it's
> firewalled on all ports.
>
> - The relayhost does not offer submission STARTTLS or SSL-wrapped
> legacy ports.
>
> - I *can* (and am permitted to) connect to a computer in the same
> LAN as the SMTP server by SSH.
If you have root on this internal machine, or if you can persuade the
administrator to allow it, you can set up a p2p-mode openvpn between
your host and the one you SSH to. This can punch through closed
firewalls, because each endpoint is trying to send packets to the same
UDP port on the other. A stateful firewall will typically assume that
the outside host is replying to the LAN host.
If either endpoint is on a dynamic IP address, you need some means of
notifying the other one what IP to send packets to. Dynamic DNS
(nsupdate) is one way, something scripted with ssh is another way.
Once your VPN is in place, simply use the VPN IP address as your
relayhost. Use NAT if necessary to get to the remote SMTP host, or
just set up routing such that reply packets are routed through the
tunnel.
This mail is being relayed through an openvpn tunnel, FWIW.
> - The authentication infrastructure only supports SSH-2
> public/private key authentication.
>
>
> The current solution is (options are: -f = background, -M = master,
> so as to keep the command alive, -N = no command, -L = port
> forward)
>
> ssh -f -M -N -L 9999:mailhub.example.org:25 sshgate.example.org
>
> This particular tunnel I'd like to get rid of. 1) It gets stuck
> across a computer's suspend (I suspect that's a misconfiguration
> of the firewall and it should die some 2:19 hours after an attempt
> to send mail because the Linux kernel I'm using would finally
> consider the TCP stream dead); 2) if for some reason it's not my
> own SSH process listening on port 9999, I'm in trouble.
>
>
> Arguably this should be fixed with authenticated submission (port
> 587), possibly with certificates; but it has not happened in a
> year although people promised to look into it.
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
