forum.excito.org

I probably understand incorrectly, but it seems you try to hide an open smtp by changing the port. If so thats security through obscurity. Why not turn on smtp auth that is available ith he machine?

nobody wrote:I probably understand incorrectly, but it seems you try to hide an open smtp by changing the port. If so thats security through obscurity. Why not turn on smtp auth that is available ith he machine?

That is possible, however this is advanced tweaking that requires altering the Postfix settings outside the regular interface. Also, there is the additional reason that the ISP is blocking port 25. The port needs to be different therefore to allow public access, but you still also need port 25 to be able to receive regular internet email. Of course if you do enable SASL then the obvious choice would be to use port 465 (the same one that Gmail uses) rather than try to obscure it and possibly be blocked by an intermediate firewall.

OK, I will try to send you a more useful answer
I will assume that you are familiar with the linux command prompt, know how to install software from the Debian repositories etc. If you are not, I'm afraid that this is going to take too much of my time...

--- DISCLAIMER ---
I started writing this as a simple how-to, but having to rethink steps I took years ago, I instead started from scratch on my spare B2 unit. It turned out to be a bit of a project. I was also unable to complete the project as intended due to problems registering the domain I intended to use as an example, so there might be vital bits missing. In the original text there were several references to the domain name I had chosen. I have simply replaced them all with "mydomain.com"
The contents in this post might be incorrect, or outright dangerous. I will take no responsibility for this!
I know there are other people out there with more experience in general (and probably more recent experience regarding the concerned topics). If any of you have any corrections or comments, please don't feel shy to correct me.
--- END DISCLAIMER ---

dutt wrote: One of the steps is e-mail. I bought a domain and am now wondering how to set up the included e-mail server to handle incoming and outgoing e-mails for that domain. I've been looking around on the forums and the wiki but haven't found any guides from the ground up. Is dovecot the mailserver or is postfix the mailserver?

Postfix is an SMTP server, or "Mail Transfer Agent" (MTA). It will receive all your emails, and also send all outgoing emails.
It's default behaviour is to send/receive email from anyone to anyone.
As the concept of MTA's are old, pre-dating illicit use of email, security is often a bit of an afterthought...

Dovecot is an IMAP server (even if it supports the old POP3 protocol). It allows you to interact with your email on your server from your favourite email client or web interface.. POP3 had some serious limitations. You basically downloaded the mail to your computer, and that was it. You had a choice to leave them on the server instead of deleting them when downloaded, but not much more.
IMAP allows you to create folders, compose new emails and saving them as drafts etc. And when you connect from the next client, it is all there as you left it on the server. This is a vast improvement over the old POP3 way of accessing your email.

As Dovecot is a bit newer, security is not as “pasted on” as with postfix. We can take advantage of this. More on this later.

The traditional way to secure postfix from sending illicit emails is to only allow outgoing emails originating from within your corporate network. This works for companies but it is no use for me (or you, I guess), I want to send emails from my email client no matter where I am, without having to establish a VPN connection to my home network. We will get around to this later.

dutt wrote: I talked to my ISP and they block port 25(SMTP, sending e-mail) but if I only go with encrypted e-mails it goes over another port and that should work fine, does the included e-mailserver support that?

If it is true that they only block outgoing traffic on port 25 you are in luck. My ISP blocks it in both directions.

Here is a little howto:

1. Get your domain registered.
I choose mydomain.com at http://freedns.afraid.org for this demonstration - for no other reason than the domain name popped up in my head and was available. The company I chose just happened to appear in my google search and offered a free service. Please take care here. I use this for this demo only. (And it still hasn't registered! Be doubly warned!) Do some proper research on what different companies will offer you, and what you need. They often rely on you - the customer- being ignorant. This is probably irrelevant as you seem to already have made your choice.

2. If you can't afford a static IP address, set up a mechanism that automatically updates your DNS when your IP address changes.
ddclient is an excellent software for this.
Configure it as instructed by your registrar. The config file is /etc/ddclient.conf or /etc/ddclient/ddclient.conf depending on version.. Here is a slightly modified example from freedns.afraid.com: The syntax can vary. This looks totally different from the one I use for my real domain...
Check that they use "ssl=yes", or it will send your credentials in clear text, and anyone who snoops them can change your domain to point to whatever they want. You might need to install this for it to work: Some seem to require single quotes around the password to work...
This one also happens to use a protocol not supported in the version of ddclient available in the debian repositories, so you would have to download the latest version and install it manually. This is only relevant to the registrar I chose for my little demo. You might use another solution, or even better have a static IP address.

3. Set up your DNS records
Most registrars have web based tools for this. The ddclient configuration above will only update the main “A” records. It would be neater to have one “A” record for mydomain.com and then a bunch of “CNAME” records for all the other variants (they are basically aliases), but this operator did not offer that option. I guess you get what you pay for . The important bit here is that they set my MX record to mail.mydomain.com, so that one must be kept up-to-date.

4. Set up your B3 to receive emails for your domain. This is done in the web interface.
If you are lucky and you can receive traffic on port 25, that is pretty much done for incoming emails. If, like me, you cannot receive anything on port 25, you will have to investigate other solutions as I mentioned in my earlier post. Try it out. Reboot your server and check the logs. Pay attention to anything from ddclient in syslog, and have a look at the mail.log too... There will most likely be problems that needs fixing, but hey - now we are playing!

5. Prevent your server from being an “open relay”"
Having an “open relay” means having an SMTP server that accepts and sends emails from anyone to everyone. It is a BAD thing. It will make you a persona non grata in the internet community in a very short time, and it can be very hard to recover your credibility. Now as you can receive emails on port 25, but not send them, you should be safe. But you will make it able to send emails, and then all those spam emails coming in on port 25 will cause trouble unless you fix it...

Make sure you have something like this in our /etc/postfix/main.cf: The most important bit here is "reject_unauth_destination".
You must however make sure that your authorized destinations are set up correctly. Here is the documentation on the directive:

reject_unauth_destination
Reject the request unless one of the following is true:

- Postfix is mail forwarder: the resolved RCPT TO domain matches $relay_domains or a subdomain thereof, and contains no sender-specified routing (user@elsewhere@domain),
- Postfix is the final destination: the resolved RCPT TO domain matches $mydestination, $inet_interfaces, $proxy_interfaces, $virtual_alias_domains, or $virtual_mailbox_domains, and contains no sender-specified routing (user@elsewhere@domain).

Better check that all is safe: (Please note that this was done on my real B3 setup for my real domain (which I have changed to mydomain.com in the text above). The one I created for the demo is not available yet...)

If you get results pointing to other variables, check them too to be sure: Looks safe, but I'm no expert

6. Enabling remote access to your postfix server with SASL
You want to send emails from wherever you are, not just when you are at home at your “corporate network”. The trick is to tell postfix to not send emails from just anyone as it is it's default behaviour.
You can set several such directives in the config file /etc/postfix/main.cf.

Be aware that this config file is somewhat confusing as it contains instructions for both receiving and sending emails. The trick is to look for the config option names. An example:

smtp_sasl_security_options = noanonymous
smtpd_sasl_security_options = noanonymous, noplaintext

(I'm sorry I hade to use the "quote " option here. The "code" tag didn't like the syntax and removed the underscores).

The point is that directives beginning with smtp_ is for configuring how the server behaves when it sends emails to other SMTP servers. The directives beginning with smtpd_ is for how the smtp daemon (postfix) itself should behave with incoming emails.
So the two examples above might look similar, but they are completely unrelated.
You often see these directives mixed up in examples, and it can be really confusing.
Luckily there is this, which has many answers:http://www.postfix.org/documentation.html

OK, so now we have to secure your server.
SASL is a good option. It uses authentication (and thus encryption to protect the credentials when they are sent over the wire) for users who want to send emails through your server. Like many such solutions, it requires a certificate based on public key cryptography. The purpose of such things is both to assure the identity of the server, and to encrypt the traffic. I don't really care about the identity, because I know it's my server. Anyway, I would recommend that you acquire a proper certificate. You can get them for free (cacert.org for example). Or you can use the dummy ones already installed as examples (perhaps not very secure, but all we are protecting here is your credentials which can be changed). Even if you get your own certificate, your email client or browser will say it is untrusted, unless you install the CA root certificate on every computer, or have the cash to pay for a proper one from Verisign or it's ilk...

SASL offers a multitude of options to actually authenticating the user. This is overkill for my purposes (and probably yours).
You can probably spend hours reading here:
http://www.postfix.org/SASL_README.html

I chose the option to use dovecot authentication. It basically means that postfix delegates the authentication to dovecot. Dovecot also has a number of methods of authentication itself – just look at the example files in /etc/dovecot. I decided to stick with the default Excito one though, except I replaced the certificate, public and private key in my original setup. I'm not going to do that for this guide though – I have started from scratch with a freshly installed B2...

So – certificates and keys: look in /etc/dovecot/dovecot.conf and you will see this:
ssl_cert_file = /etc/ssl/certs/dovecot.pem
ssl_key_file = /etc/ssl/private/dovecot.pem

They are pre-installed and you do not know anything about them really. It is probably safe, but if you are paranoid, get your own. You can use the same certificates and keys you generated for HTTPS traffic on your web server (if you are like me )

To set up postfix to use dovecot authentication, add this to /etc/postfix/main.cf: If you check your /etc/postfix/master.cf you will see it already has an entry for smtps. Just needs uncommenting: If you look in /etc/services, you will see that smtps will translate to 465, so all you have to do now is open that port in your B2/B3 firewall. IMAP ports 143 and 993 should already be open by default.

Now try to set up an account against your server in an email client:
Receiving options: Your mailserver name, requires authentication, either STARTTLS on port 143 or SSL on port 993 (I find STARTTLS much quicker).
Sending options: Your mailserver name, requires authentication, SSL on port 465.
Use usernames you have created on your B3 in the web interface and try to send emails between them.
Outgoing mail shouldn't work yet...

7. Setting up a relay host, and a way to connect to it over SMTPS
Note: This is the only way I could get this to work with my relayhost. They do NOT accept anything but SMTPS. I have seen other tutorials using port 587 and TLS, but it has never worked for me...

Now you could just add something like this in /etc/postfix/main.cf: The problem is that it won't work as your relay server also does not want to be an open relay, and has some security measures implemented. These may vary. I describe what has worked for me...

First install stunnel4: Now edit /etc/stunnel/stunnel.conf.
I've removed all the settings but these: I've changed the accept port to 10465 as 465 is already busy on my server.
This should only be available internally. Don't expose your "accept port" to the internet in your firewall...
The connect option is your relay server. So it accepts connections on 10465 and forwards them to outbound.mailhop.org on port 465.

So my relayhost entry in main.cf actually looks like this: EDIT:
You will have to enable stunnnel4 once it is configured correctly in /etc/default/stunnel4: So now we need to make it authenticate to the relay server.
Create a file called /etc/postfix/sasl_passwd.
Add your relay server name and your credentials for it: Note that I specified the localhost port as the remote server as this is what postfix will actually connect to... Better set the permissions to 600 on this file.

Now make it a postfix DB: Now add some directives in main.cf to make it authenticate against the relay server: Hopefully now everything should be up and working!
It never works on the first try though, so keep an eye on those logs...

8. Some practical things
Edit your alias database /etc/aliases. It might be good to enter aliases for postmaster, root etc, so their messages gets delivered to the admin user instead: After changing this, you must run: If you have loads of software that installs users and user directories, or if you have unused user accounts, it might be a good idea to put a file called .forward in each such home directory with the contents: Then any local delivered emails from cron jobs or whathaveyou will find their way to you...

Well, hope you did not find it too daunting and that I didn't miss too much, and good luck!

Cheeseboy

I never did that Dovecot SASL implementation, so I thought I'd give it a try with Cheeseboy's instructions. I skipped steps 1 to 4 as I already got these nailed and proceeded with step 5

5. Essentially this is already implemented stuff. Maybe not on other systems, but on the B3 it is. Only element that needs your attention here is that you need to add the permit_sasl_authenticated rule:

smtpd_recipient_restrictions =

• permit_mynetworks
  permit_sasl_authenticated
  reject_unauth_destination
  reject_unauth_pipelining
  ...

Sorry about using quote here, but I wanted to color-highlight the change you'll need to make.

Also, don't worry about virtual_maps and other virtual_something definitions. That's high level advanced configuration, most of which (if not all) can be accomplished through the aliases file.

6. Something is amiss here. The tricky part in the added rules are the last three: Obviously you want these in your final implementation, but with those in it gets harder to test your configuration because it will only offer the authentication protocol if you're already secure/encrypted. While big steps take you quicker to the end result, small steps are often better to identify errors and mistakes. I suggest you leave these rules out to start with and add them later when you've verified that authentication is working.

Now take special attention to this line: That file (it's actually a socket), private/auth, does not exist and needs to be offered by Dovecot. For this you'll need to make changes in /etc/dovecot/dovecot.conf

auth default {

• mechanisms = plain login
  passdb pam {
  }
  userdb passwd {
  }
  socket listen {
  
  • client {
    • path = /var/spool/postfix/private/auth
      mode = 0660
      user = postfix
      group = postfix
    }
  }[/color]

}

You'll have to plough your way through all the commented sections for this I'm afraid...

6a. Testing your configuration
Let's insert this step. After making the changes to dovecot.conf, main.cf and master.cf restart both Dovecot and Postfix. From a client start telnet

telnet server.example.com 25
...
220 server.example.com ESMTP Postfix (Debian/GNU)
EHLO client.example.com
250-server.example.com
250-PIPELINING
250-SIZE 10240000
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250 8BITMIME
250 DSN
AUTH PLAIN AHVzZXJuYW1lAHBhc3N3b3Jk
235 2.7.0 Authentication successful

The green lines here are what you need to type. If you're not seeing the red lines than SASL is either not working or hidden (did you leave out those three lines I mentioned?). To successfully login you'll need to alter the key value AHVzZXJuYW1lAHBhc3N3b3Jk, or setup a useraccount named 'username' and password 'password'. Find your key by typing: Success? Now try the same with openssl

openssl s_client -connect server.example.com:465
CONNECTED(00000003)
loads of certificate stuff...
---
220 server.example.com ESMTP Postfix (Debian/GNU)
EHLO client.example.com
250-server.example.com
250-PIPELINING
250-SIZE 10240000
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250 8BITMIME
250 DSN
AUTH PLAIN AHVzZXJuYW1lAHBhc3N3b3Jk
235 2.7.0 Authentication successful

Again success? Get those three lines in main.cf and reload Postfix to try again. Note the different responses you'll get to connecting with the following three commands and doing an EHLO: Next verify that your rules are functioning properly by connecting to your server from the WAN side (remember that $mynetworks is permitted before SASL) and issue the following commands after EHLO:

MAIL FROM:you@somedomein.com
250 2.1.0 Ok
RCPT TO:you@otherdomain.com
554 5.7.1 <localhost.localdomain[127.0.0.1]>: Client host rejected: Access denied

Now run the AUTH PLAIN command and try the RCPT TO command again. If it says "250 2.1.5 Ok" now then you're up and running.

7. That's a neat trick with stunnel4. I can't think of any ISP though that does not have any provision for port 25 within their serviced network. First step here should be to investigate the email settings that your ISP gives you for username@yourISP.com. If they give you a regular SMTP server and port (25) with no authentication, then all you need to do is tell Postfix to use that server for relaying.

8. Take a note of your email client's capabilities. The above guideline is for enabling SMTPS - email over SSH. If your client (your phone?) can only do TLS you should skip the smtps port configuration in master.cf and open up submission (port 587) instead.

Some clients can trip over the fact that your certificate boasts the wrong server name or that it is selfsigned. Just last week I was at my parent's house attempting to access my email from their computer (running the latest Thunderbird) and it quietly refused to give me access over IMAPS. It took me about an hour to figure out what was making it loop indefinitely and how to fix it.

And make sure your passwords are not easy to guess (including root's password!). You could also think about limiting who can access your email server. A nice trick to do this is to install the geoipdb target for iptables, which allows filtering by country.

Thank you Gordon for taking the time to read my post and to try it out!

I will re-examine my setup and probably make changes according to your suggestions.
This stuff has been implemented and running for so long, I've forgotten most of the reasons it was made as it was in the first place. Of course, I reused as much as possible of what was already there in the bubba config files (it was probably a B1...)

I will take special attention to the dovecot files...

Cheers,

Cheeseboy

Actually, I found something unexpected. If you're either on TLS or SSL then 'permit_mynetworks' is ignored, so testing the SASL configuration should also work from the LAN side even with that line left in place.

I actually don't rely on Postfix relay blocking myself. I do get incoming email on port 25 (be it through a relay server) and I have ASSP Anti-Spam SMTP Proxy server guarding this port for unauthorized use, which includes relaying. Since ASSP uses different ports and/or IP addresses for incoming and outgoing emails it is impossible to circumvent the relay block, e.g. by spoofing. Although my ISP's relay server prevents me to use any of the advanced features (such as blacklisting spammers or tarpitting them) it's also still one of the best solutions as it stops spam while it is being delivered; it does *not* try to bounce emails to the address that is specified as the from address inside the email (which is normally faked and thus makes YOU the spammer!).

Another thing about ASSP that might be useful is that it doesn't have to run on the same machine is your MTA. So if you know someone else who is not running his own email server but can have port 25 open, you could run ASSP on his site as a proxy to your MTA on a non-standard port (or better still: through a VPN).

While my ISP's relay server prevents me to use any of the advanced features (such as blacklisting spammers or tarpitting them) it's also still one of the best solutions as it stops spam while it is being delivered; it does *not* try to bounce emails to the address that is specified as the from address inside the email (which is normally faked and thus makes YOU the spammer!).

The service I'm paying for actually has a good spam filter, and even lets me control how it is used ("*SPAM*" as prefix in the subject or setting various header fields, or ignore).
And of course a friendly web interface where you can add your exceptions....

They've made a point of breaking whatever RFC standard saying it has to return replies to messages to unknown recipients, so that trick doesn't work there either....

There's always more than one solution...

The problem with spam is that with trying to let software detect it you can have both false positives as false negatives. Obviously the false negatives are annoying to the person receiving them, but how do you handle false positives? I think this last type is why the decision was made that the sender should be notified that his email was rejected, but if that's an RFC standard?

The next issue is that most of these protocols date back to the sixties, when everybody was still behaving honourable. So the server receives an email and checks the envelope who it is for. It then rips off the envelope and places the message in the user's inbox. Now with people being less "gentlemen-ish" where do you start checking for spam and should you send notification? If I check in my email client, then all I can see is the from address in the email header and with actual spam that is most likely faked. If I check in the email server I can see both the from address and the envelope sender address, but the envelope sender can be fake as well; in fact I found out not so long ago that if you send an email to a Microsoft Exchange server and the envelope sender address is empty it will bounce the message to the from email header address - that's without even having a spam filter installed!

Essentially, if you do spamfiltering at any place *after* having received the email, you should not send notifications for the simple reason that you cannot trust the sender addresses. However that does impose the problem that any legit sender also will not know that you did not receive his message. The fun thing about the SMTP proxy is that you can in fact notify the sender that you are blocking his message without ever sending anything back and letting yourself being confused by whomever the sender claims to be.

The proposed before-queue filtering (i.e. Proxy filtering) is indeed the best way to handle spam, simply because you can reject the mail while still having a connection the actual sender. However, running spamassassin or amavisd in a before-queue setup is officially not recomended unless ou have a very fast server. This is because the full analysis of the mail, including spam heuristics and virus scanner, can sometimes take a long time if multiple mails come in at the same time. If processing takes longer than the timeout of the client, the message is considered undeliverable and the human sender gets an error message.

Gordon wrote: Now take special attention to this line:

Code: Select all

smtpd_sasl_path = private/auth

That file (it's actually a socket), private/auth, does not exist and needs to be offered by Dovecot. For this you'll need to make changes in /etc/dovecot/dovecot.conf.

Well, that's exactly what my /etc/dovecot/dovecot.conf looks like, so either I made the changes and forgot about it, or they where there by default in whatever version of the bubba I originally set it up on

Gordon wrote: First step here should be to investigate the email settings that your ISP gives you for username@yourISP.com. If they give you a regular SMTP server and port (25) with no authentication, then all you need to do is tell Postfix to use that server for relaying.

Well if I remember correctly, they would not let me use my own domain name...

Thanks again for testing!

Cheeseboy wrote: Well, that's exactly what my /etc/dovecot/dovecot.conf looks like, so either I made the changes and forgot about it, or they where there by default in whatever version of the bubba I originally set it up on

Figures... When I got my B3, somewhere inbetween one and a half year and two years ago, Dovecot turned out to be completely disfunctional. I had to manually add imap and imaps to the protocols line before I could connect to my mail account (webmail didn't work as well because of this same reason). In any case it doesn't hurt to verify as the message that Postfix gives you when Dovecot is not configured accordingly is rather cryptic (I think it was something like "No authentication protocols available").

Cheeseboy wrote:

Gordon wrote: First step here should be to investigate the email settings that your ISP gives you for username@yourISP.com. If they give you a regular SMTP server and port (25) with no authentication, then all you need to do is tell Postfix to use that server for relaying.

Well if I remember correctly, they would not let me use my own domain name...

Yes, that happens. The dead giveaway for this is that you need to supply a username and password to the SMTP server, but I guess that if they use something like Exchange they could also do a username validation on the proclaimed sender address. I haven't found any (local) ISP yet that actually does these kind of things. My current ISP is in fact the first one giving me issues on the fact that they block TCP 25 also on incoming traffic.

I feel this thread should be made into a wiki article.
I might start one later if I get enough coffee in me, but it would properly need as many corrections/clarifications as the posts I wrote. Should you feel inclined to start one, feel free to re-use whatever I have written...

It would be interesting to hear if the OP ever got it working

Cheeseboy wrote:I feel this thread should be made into a wiki article.
I might start one later if I get enough coffee in me, but it would properly need as many corrections/clarifications as the posts I wrote. Should you feel inclined to start one, feel free to re-use whatever I have written...

It would be interesting to hear if the OP ever got it working

I almost forgot there was a question that started this

Probably not, as I fear all we may have accomplished is to confuse him. So to bring it back to bare metal:

1. In terms of being able to send and receive emails, Postfix is the mailserver - us techies call it an MTA
2. Yes, Postfix can operate on any given TCP port, but there's no way to tell other mailservers what that port is. In other words: you need a peer that does know the port(s) you're using and that you can use as an intermediate towards/from TCP 25

As far as a Wiki is concerned I think setting up standard email is rather straightforward in the B3. A Wiki would be useful for enabling TLS/SSL in the mailserver and might include the Stunnel4 SSL hack you put down here. Make certain to explain for what reason you want/need this, because maybe 99% will in fact have no use for this (and there's always webmail to support mobile users).

I don't really see a point in trying to setup a Wiki on how to circumvent any blocks that ISP A or ISP B might have in place or how you need to configure DNS with either one of these ISPs or name service provider A/B. There's too many variables to create any foolproof cookbook, unless of course you'd want to sell your own service for this. I'd say, if you don't know what MX records are then find someone who does know. And find a decent provider who doesn't shrug and says it can't be done...

Well, and it seems like a lot of work, so it probably will never happen

Sent from my GT-I9305N using Tapatalk 2

Consideribg the simplicity and robustness of the hack, i think future releases of bubbaOS should have smtp-auth enabled by default (except minimal password strengths then do apply )