On Sat, 2005-08-27 at 17:57, Jonathan Berry wrote:
> > So you want a roaming client, like a laptop that might be
> > connected elsewhere or a client you configure on a different
> > network to be able to send to 'your' ISP's server? In the
>
> Basically, yes.
>
> > 'fixed client at another location' case you may be able to
> > send though a local smtp server. The roaming on is a
>
> That would be ideal, but I do not know if such a server is available.
Chances are pretty good that one is there. Or, you could use
a gmail.com account with its authenticated login as the forwarder
on port 465 even if your reply address is elsewhere.
> > use ssh and port-forward smtp (and a few other things)
> > though it with the setup controlled by the client request.
> > >From your client:
> > ssh -L25:isp_ipaddress:25 your_server
> > and be sure that is connected before you send from your
> > mail program which you configure to send to localhost:25.
>
> This is interesting. How exactly does it work? Is this for
> connecting to the ISP SMTP or to my own server that I setup?
Ssh can forward any tcp ports you want over its encrypted tunnel.
If you want it to listen for the connections on the local side
use -Llisten-port:remote-address:remote-port. Then when
any progam connects to the local port specified, it is passed
through to connect to the remote address/port specified. If
the remote address isn't the same as the remote ssh server, the
connection will appear to have originated at the remote ssh
server. On windows you can use cygwin ssh with the same
command line options or putty which has a dialog box for
tunnels.
> >
> > With iptables it is better to work on different interfaces for
> > port forwarding. Xinetd doesn't really care and you could arrange
> > for an odd high port to magically connect to your ISP's smtp port
> > with a 'redirect' entry but it would not be secure at all and
>
> I like this solution, nice and simple. I have it setup right now
> (confined to my local network by my hardware firewall for now). I
> certainly do not want to help spammers and/or viruses in spreading,
> but how much of a real security risk is this? Do spammers/viruses
> look for SMTP servers on strange ports? I know I see a lot of knocks
> on my firewall logs to all kinds of ports, but I have no idea what
> they are trying to do.
I'd say the risk is low, but I wouldn't just set it up and ignore
it.
> Is there a way to set this up with a lot of
> logging to where I could see what traffic was going through?
You should get an entry in /var/log/secure as xinetd starts a
connection. For more than that you would need something like
ntop that sniffs and summarizes everything.
> How does
> this look to the SMTP (is the connection seen from my IP or the
> originating IP)?
It appears to originate from the box running the xinetd redirect. It
acts as a generic proxy for whatever connection you configure.
> I want to get in trouble for helping spammers even
> less than I want to help spammers :). I could always lock down the
> from IP range, and tweak it if I need it from a different location via
> ssh. Any thoughts on this?
Yes, if you limit the originating IP address on your outside firewall
it is very unlikely that anyone would discover or exploit it.
> > I wouldn't recommend it. A better alternative would be to
> > use 'stunnel' to accept ssl connections with a client certificate
>
> This sounds interesting too. I like the idea of having some auth that
> would be simple to setup. I guess I'll do some reading up on stunnel
> and see if I can get that working. Anyone have any experience with
> stunnel?
Stunnel works very much like the xinetd proxy, but the connecting side
runs over ssl. The client side of this is built into many email
programs that know how to use port 465 for a secure connection. The
'back end' conection runs unencrypted so sending on port 25 to the
smtp server automatically works.
> > required and forward t o your isp, or run your own mail server
> > with ssl on port 465 or port 587 with TLS and require authenticated
> > logins for SMTP forwarding. Most current mail clients support
>
> Might as well use Gmail if I'm to go that far. Less to have to keep track of.
It does seem like the easiest solution.
--
Les Mikesell
lesmikesell@xxxxxxxxx
