E-mail relay ideas

  • Thread starter Deleted member 9563
  • Start date
D

Deleted member 9563

Guest
I'm not getting the info I want from searching the net, which suggests to me that I'm asking the wrong questions, or have some misconception. That's why I'm generalizing my problem/idea here. Hopefully somebody can give me a good suggestion or send me off in a better direction.

The reason I'm looking at a mail relay is that sending e-mail is not working with my commercial VPN provider. (Receiving works fine and is all set up for multiple accounts.) Since I keep experimenting with the VPN and changing servers, I thought I'd set up an e-mail relay for sending my mail which would always circumvent my VPN. In other words, one route from here to my VPN, and another route from here to my own SMTP relay on the net. A setup such as this:

my.computer -> (VPN/tunnel) -> internet
my.computer -> (SMTP/ssh) -> internet -> my.SMTP.relay -> internet

I have several VPS options which would have plenty of resources for this little use. They run Debian, but I think the programs and configuration for mail are almost the same across *nixes.

To sum up. I want my browsing and general web uses to go to/through the VPN. And I want another local route (presumably specified in my local e-mail client, and somewhere else on my box) to send mail to my new SMTP server which will send it out from there.

Since I'm not finding basic answers for this, I guess I'm either asking for something too odd, or it's just a bad idea. I realize there are probably other solutions, and I can certainly send e-mail from a web interface, so I'm not stuck.

All comments, suggestions, and solutions, gratefully accepted.
 
I am not getting where is the problem. You will have two VPN connections - one for everything with default route and one for email only, which will end on your mail server.

Then you can:
- set up your mail program to use remote VPN end as SMTP server;
- if SMTP server on the remote point is not listening on the tunnel address, add local route to listening address;
- redirect all outgoing traffic to 25/465/567 ports into the tunnel using firewall.

Those are only from top of my head, there would be definitely many other weird ways how to delivery "SMTP packets" to the right machine.
 
Thanks ondra_knezour. You've given me some idea of how to break down the setup. The problem is that I can't seem to find an easy how-to for this kind of setup. Apparently the idea of relaying mail is uncommon. Also, things like using direct addressing in Claws setup without having to register extra domains just to relay mail don't seem to be addressed anywhere. I'll experiment.

I was thinking SSH because the local mail client (Claws) would do that automatically, but a VPN tunnel does sound like it would be better. I'm using OpenVPN and it appears that it can handle multiple tunnels at once - which I didn't know. I'll work on that tomorrow and ask for help here if needed. That's the only real FreeBSD aspect of this.

I still can't find a how-to for Postfix on Debian that doesn't include Dovecot and things like setting up mail boxes. I'll install Postfix so I can look at it first, and then look for help on a Debian or other Linux forum.
 
OJ, if I got your question right you should break it down into separate blocks to solve. Solving them all at once leads into too many directions :)

So some simple bullet points:
  • mail/claws-mail:
    • Set up your SSH tunnel or SSH port-forwarding to get a connection to your smtp relay server
    • Configure your email client to use that server as SMTP (outgoing) server
      • connection will be established via IP-address or DNS lookup and plain IP routing
    • For troubleshooting you should probably use tcpdump() to see where your packets are going to.
  • mail/postfix:
    • It is not uncommon to set up postfix to relay mail from an internal SOHO network to an official ISP mail server. For some hints about that topic have a look at the postfix website under: http://www.postfix.org/SOHO_README.html#client_sasl_enable -> "relayhost"
    • As above: Set up your SSH tunnel or SSH port-forwarding to get a connection to your smtp relay server
      • connection will be established via IP-address or DNS lookup and plain IP routing
    • For trouleshooting you could use something like tail -f /var/log/maillog on your machine running postfix to see if it connects correctly to your relay server and the authentication is right.
Additional hints:
  • You may have to ensure that/check if your new relay mail server accepts your mails with a "foreign" sender/return address.
my.computer -> (SMTP/ssh) -> internet -> my.SMTP.relay -> internet
Click to expand...
If my.SMTP.relay is the postfix server you are talking about than you do not have to set that up as relay (as shown above, probably) but just as SMTP server. And your mail/claws-mail does not relay your email, it is just sending it.

But maybe I have just garbled what you wanted to say and I am completely wrong ;-)
Could you specify what particular part you are stuck at? Is it the SSH tunnel forwarding thing? Or something other?
 
gqgunhed said:
OJ, if I got your question right you should break it down into separate blocks to solve. Solving them all at once leads into too many directions:)
Click to expand...

That is indeed what I'm unable to do - some kind of a breakdown of what is all needed. Since I didn't know enough details of what was involved, I also hadn't yet figured out that SSH is probably a better choice than VPN for me here.

If my.SMTP.relay is the postfix server you are talking about then you do not have to set that up as relay (as shown above, probably) but just as SMTP server. And your mail/claws-mail does not relay your email, it is just sending it.
Click to expand...

That's very clarifying for me. Thanks. Now after playing with it, setting up a test account, reading stuff, etc., I'm moving forward.

But maybe I have just garbled what you wanted to say and I am completely wrong ;-)
Could you specify what particular part you are stuck at? Is it the SSH tunnel forwarding thing? Or something other?
Click to expand...

You have certainly not garbled. I'm on track now, but have a ways to go.

I didn't answer sooner because I wanted to see what I could do and be able to ask about something more specific. So, you got me figured out. Yes, I'm now stuck on the SSH tunnel thing. :)

What's done:
- installed postfix on server and had a good look at the configuration options.
- set up test account in Claws (not clear on config there, but will probably see the light after missing step)

Which is:
Setting up an SSH tunnel to the server.
 
SSH tunnel for your setup should not be too hard. As ondra_knezour postet above:
ondra_knezour said:
SSH reminds me about ssh tunneling/port forwarding. See http://www.revsys.com/writings/quicktips/ssh-tunnel.html for example.
Click to expand...
From there:
Code: 
ssh -f user@personal-server.com -L 2000:personal-server.com:25 -N
where:
  • personal-server.com is your "my.SMTP.relay" postfix server
  • user is your SSH username on your postfix server
  • if your postfix is listening on a port different from 25 you have to change the command accordingly
After that you set up mail/claws-mail on your client to:
  • SMTP server: "localhost" port "2000", as this connects to your local end of the SSH tunnel. On the other end the tunnel is connected to the postfix running there on port 25
  • set SSL or STARTTLS as configured on your postfix server
  • username and password as set for your user in postfix.
  • Add: You can pre-check if the connection works if you connect via telnet or nc to localhost:2000 and see if you are actually talking to your postfix mail server on the other side (https://duckduckgo.com/?q=send+email+using+telnet&ia=qa).
There are some more hints about that in the referenced post, so have a look at it. Or search the internet for "SSH tunnel" ;-)
Does this help you?
 
Little addition to what gqgunhed said:

You don't have to struggle with authentication, encryption, certificates etc. if your Postfix will listen only on localhost - in such way only local applications and tunneled connections will be able to relay messages through your mail server and remote encryption and authentication is already handled by the SSH tunnel. This setup is not possible, if you want not only relay your messages to outside world, but also accept incoming messages for your domain(s). There may be way how to set up Postfix to accept everything for your domain from whatever server in the world and relay only messages originating locally, but I am not familiar with Postfix enough to say if it is possible and how to do that. But you definitely don't want to relay from anybody without authentication, because such machine will act as open relay, get quickly found by spammers, abused and banned by most servers using blacklists.

If you would like to setup SSL or TLS, try the connection with telnet before, because after that, you will be able to issue only the STARTTLS command after which you will get human unreadable encrypted data not useful for testing at all.
 
ondra_knezour said:
Little addition to what gqgunhed said:

You don't have to struggle with authentication, encryption, certificates etc. if your Postfix will listen only on localhost
Click to expand...
Thanks for that. Now I'm getting it. As for an open relay, I'm aware of the concept and will look for it. In fact, I've just set it up that way (I think) and am able to send mail from my mail client. At least I know it works. Now I just need to add SSH.
 
gqgunhed said:
SSH tunnel for your setup should not be too hard. As ondra_knezour postet above:

From there:
Code: 
ssh -f user@personal-server.com -L 2000:personal-server.com:25 -N
where:
  • personal-server.com is your "my.SMTP.relay" postfix server
  • user is your SSH username on your postfix server
  • if your postfix is listening on a port different from 25 you have to change the command accordingly
Click to expand...
I've done that and the connection appears to be in place. I've verified that Postfix is listening on port 25, and the above command does indeed set up an SSH connection. However, it doesn't work. The connection shows on the server as being to port 22.

I think my problem is regarding usernames for SSH and Postfix. I have no idea about those. There is no username associated with my Postfix that I can research. I added a user for the purpose and changed the above command line, but that in itself makes no difference. The very many articles I've searched through don't reference it in those terms.
After that you set up mail/claws-mail on your client to:
  • SMTP server: "localhost" port "2000", as this connects to your local end of the SSH tunnel. On the other end the tunnel is connected to the postfix running there on port 25
  • set SSL or STARTTLS as configured on your postfix server
  • username and password as set for your user in postfix.
  • Add: You can pre-check if the connection works if you connect via telnet or nc to localhost:2000 and see if you are actually talking to your postfix mail server on the other side (https://duckduckgo.com/?q=send+email+using+telnet&ia=qa).
Click to expand...
That all looks good to go here now. I've connected with STARTTLS and a certificate was accepted in that fashion. It was still not possible to send mail with SSL. What is a postfix username? Trying both "root" and the new username of "post" with their respective passwords does not do the trick. The error looks like this:

Code: 
** error occurred on SMTP session
*** Error occurred while sending the message:
554 5.7.1 <ole@xxxxxxx.net>: Relay access denied

I'm close. :) I think the problem is with "username". From what I can tell using netstat and lsof, The above command to bind port 2000 to port 25 is resulting in binding to port 22 instead.

PS: I'm familiar with Telnet for e-mail as I use it on my DOS machine that way sometimes. I didn't install telnetd on the server since I managed to send mail from Claws without it.
 
Some thoughts ... as I am not that uber-postfix-troubleshooter :)
1.) The postfix-username is just a system user on your smtp machine. So if you are sending as "ole@xxxxxxx.net" the problem could be:
  • there is no user "ole" on the machine
  • "xxxxxxx.net" is not the domain name of your my.STMP.relay
2.) But the error could also be triggered by one of the following options in your /usr/local/etc/postfix/main.cf:
  • smtpd_recipient_restrictions = permit_mynetworks ...
  • smtpd_client_restrictions = permit_mynetworks ...
  • smtpd_relay_restrictions = permit_mynetworks ...
where "mynetworks" should be somewhere in main.cf too like:
Code: 
mynetworks = 127.0.0.0/8 192.168.0.0/24
But as the SSH tunnel ends on your my.SMTP.relay machine the claws-mail connect should appear to originate from localhost (seen from postfix perspective).

I think the solution is buried somewhere in here http://www.postfix.org/SMTPD_ACCESS_README.html
Hmm, just some wild guessing here o_O (sorry, but my postfix config has not changed in years, so I cannot remember which options led to success for me back then)
 
gqgunhed said:
Some thoughts ... as I am not that uber-postfix-troubleshooter :)
1.) The postfix-username is just a system user on your smtp machine. So if you are sending as "ole@xxxxxxx.net" the problem could be:
  • there is no user "ole" on the machine
  • "xxxxxxx.net" is not the domain name of your my.STMP.relay
Click to expand...
Yes, both of those are true, but as it turns out it is irrelevant because you've shown me the solution. :)
2.) But the error could also be triggered by one of the following options in your /usr/local/etc/postfix/main.cf:
  • smtpd_recipient_restrictions = permit_mynetworks ...
  • smtpd_client_restrictions = permit_mynetworks ...
  • smtpd_relay_restrictions = permit_mynetworks ...
where "mynetworks" should be somewhere in main.cf too like:
Code: 
mynetworks = 127.0.0.0/8

192.168.0.0/24
But as the SSH tunnel ends on your my.SMTP.relay machine the claws-mail connect should appear to originate from localhost (seen from postfix perspective).
Click to expand...

As it turns out the "local" address that was required is the server address. I seem to have the rest of it set up OK and all it needed was this line:
Code: 
mynetworks = 127.0.0.0/8 107.xxx.xxx.236
I think the solution is buried somewhere in here http://www.postfix.org/SMTPD_ACCESS_README.html
Hmm, just some wild guessing here o_O (sorry, but my postfix config has not changed in years, so I cannot remember which options led to success for me back then)
Click to expand...
You're right. So far I have a dozen tabs open to Postfix info. Boy, there's a lot of things that can go wrong with this. :) However, with your (and ondra_knezour's) help it looks like I've achieved my goal. Thanks guys!

I've tested with telnet and some internet testing sites, and it doesn't look like there is any public access, which was a major concern of mine. Testing with various accounts locally from Claws mail shows successful mail sends. I'll read more about anything that I can do to harden the server, but it looks good so far.
 
I'd definitely look carefully at master.cf and only bind to localhost:<port> rather than the implicit wildcard of just using a service name. You probably only need to be bound to submission and not a full-blown smtp running on the machine if all you are doing is sending mail through the relay.

Look carefully at smtpd_client_restrictions in both master.cf and main.cf, as well as reading and understanding http://www.postfix.org/SMTPD_ACCESS_README.html -- Things have changed a lot over the last several years, both in the world as well as how Postfix deals with it.
 
jef said:
I'd definitely look carefully at master.cf and only bind to localhost:<port> rather than the implicit wildcard of just using a service name. You probably only need to be bound to submission and not a full-blown smtp running on the machine if all you are doing is sending mail through the relay.
Click to expand...
Thanks. I'm using ssh over port 22, so I'm not sure if changing to port 587 is appropriate or any improvement.

Look carefully at smtpd_client_restrictions in both master.cf and main.cf, as well as reading and understanding http://www.postfix.org/SMTPD_ACCESS_README.html -- Things have changed a lot over the last several years, both in the world as well as how Postfix deals with it.
Click to expand...
Yes, reading and understanding are two different levels, and it's the understanding part that is causing me some trouble. :) I've been looking at that page since I started this project, but am not sure about the implications. I added smtpd_client_restrictions = permit_mynetworks, reject to my main.cf and it works but can't be sure that it makes any difference to security. The other two relevant lines are:
Code: 
relayhost =
mynetworks = 127.0.0.0/8 107.xxx.xxx.xxx
What I can't seem to figure out is how to restrict relaying to just the traffic over the tunnel. When mynetworks = is restricted to 127.0.0.0 no mail gets through. It only works when I add the interface address. I'm pretty sure that one would have to be logged in in order to send mail. I made it so one cannot log in as root so it would probably be difficult for a spammer to get any control here.

I'm completely green at this, so atleast any legacy understanding won't get in the way. :) Luckily this is just for personal use and the server is a throwaway VPS, so I don't have a lot to lose by getting anything wrong. Neverless, when I look at the logs, the amount of login attempts for "root", as well as non existing accounts like "admin", started to look pretty scary even after just a few hours of being on line!

BTW: Slowing down SSH login attempts is easy, but is there a way to limit the rate of sending?
 
OK, it sounds to me like you've got three things to consider here
  1. How can I secure postfix so that it doesn't unexpectedly relay?
  2. How can I create a secure and robust ssh tunnel to my mail-relay machine?
  3. How can I secure my mail-relay machine?
I think that if you take those one at a time, in the right order, things may come into better focus. All at once can be quite a jumble...

First, I'd suggest that you use key-based authentication for the tunnel. That key should be authorized to only allow port forwarding -- no command, no ptty, no X-forwarding, no... Take a look at some of the Internet mentions of how to do this, then consult sshd(8) and sshd_config(5) to figure out what you feel is best to disable. My personal opinion is about everything under the sun should be off for a tunnel-only key. While some might suggest not having a password on the key, I'm not a big fan of that unless it's absolutely needed.

Be careful with ssh multiplexing as there may be unexpected results depending on how the maser connection was established!

You'll have to figure out how you want to monitor the tunnel and (automatically) bring it up when it's down and you need it. That should get you a good start at (2) from the list.


Now, what about securing that machine. That's a topic unto itself, and depends on your level of paranoia (a good thing, in this context), and the value of the machine to you if you need to wipe it clean and rebuild it, or have it out of service when you're 5,000 miles away. Crank down the firewall as hard as you can, turn off every service you don't need, only run services in a jail, never use an insecure connection, keep it up to date with security patches, crank up the kern.securelevel, run an IDS, keep lots of backups,... -- All the usual recommendations apply.

You're right, the ssh port gets hammered with login requests. Years ago I used to monitor them and try to block them at the firewall. It got to be more of a pain than anything, so I gave up. Here's a suggestion though -- disable ChallengeResponseAuthentication and only allow keys (and potentially Kerberos/GSSAPI). At least the username/password scripters will go away sooner and you probably won't have as much log clutter.

Moving ssh off port 22 is only a little obscurity, no real security. My suggestion was to use postfix running on the submission port, still a standard port, and not running on the smtp port. Like disabling ChallengeResponseAuthentication, this should cut down on bottom-tier, brute-force scans and attacks on the smtp port.

Item (3) up there is your real challenge. Closing down the relay, item (1), is a "solvable" problem once you have the machine secured.

I'm guessing that if you look at your machine, postfix will have bound to *:25 (or *:587) rather than 127.0.0.1:25 meaning that it has both the loopback address, as well as the physical/virtual interfaces. I've got a configuration on one of my servers where I'm bound to localhost:[I]nn[/I] and have -o mynetworks=127.0.0.0/8 as one of the options for that in master.cf.
 
You must log in or register to reply here.
Back
Top