External Email
- Thread starter Mike
- Start date
Nyr
Active Member
I misunderstood your message then.
I was thinking the budged solutions were exchange based too, that's why I was so surprised by the price.
Maybe that's what buffalooed was thinking too.
We use Google Apps for Enterprise, in addition to SendGrid.
Are you happy with SendGrid? Was considering using that myself.
wlanboy
Content Contributer
Ok, then buy a VPS and host email on it
As long as you do not have to send a lot of Emails a self hosted postfix/dovecot on a small 128 MB vps will do the job fine.
And I agree that I would not run any other services on that vps. Email servers are still a valuable target.
Running an Email server is quite easy.
Nyr
Active Member
Running an email server isn't hard.
Correctly running an email server requires big amounts of work.
And you can't run something like AMaViS on a low end VPS.
Also: availability, backups, blacklists, contacts synchronization with mobile devices, etc...
The idea of running my own mailserver terrifies me. Security first and foremost.
I'd rather pay a subscription to an expert to host my mail securely. Still haven't found one, though I'm sure there will be a raft of new services soon.
Also keeping my hopes up for Bitmessage, but it has a long way to go yet. On the bitmessage broadcasts here have been hints of another, more robust p2p-based mail system about to hit the net.
I'd rather pay a subscription to an expert to host my mail securely. Still haven't found one, though I'm sure there will be a raft of new services soon.
Also keeping my hopes up for Bitmessage, but it has a long way to go yet. On the bitmessage broadcasts here have been hints of another, more robust p2p-based mail system about to hit the net.
amavisd-new runs just fine on any VPS. If your setup requires a lot of maintenance or a lot of resources then there's a problem with your setup.
Security - so stick to standard packages that upgrade with your package maintainer. A web server is much more vulnerable than a mail server; so does that terrify you too?
Edit: of course if privacy is a concern you shouldn't run it on VPS; but obviously then you even more shouldn't run on hosted "solution"
Security - so stick to standard packages that upgrade with your package maintainer. A web server is much more vulnerable than a mail server; so does that terrify you too?
Edit: of course if privacy is a concern you shouldn't run it on VPS; but obviously then you even more shouldn't run on hosted "solution"
Last edited by a moderator:
Nyr
Active Member
Even the creators of iRedMail recommend at least 1GB of available memory for their stack.
Also, a misconfigured mail server is not something you want to trust your email on. And an email stack is much more difficult to configure than a standard web server. That's a fact: you can get a web server + PHP and MySQL running in five minutes while Postfix + Dovecot + MySQL + Roundcube + Amavisd with spam and virus scanning + DKIM takes hours for an experienced administrator.
wlanboy
Content Contributer
As I said.
But it is not consuming a lot of work if you stick to the right tools.
This tutorial is a start. You can easly add feature after feature to your own mail server.
If you need a web frontend or any mobile support you can stick to tools that are based on IMAP.
I did not say that you have to abandon any service you are using. But a lot of people just need an IMAP account. And that is a quite easy task.
As easy as a web server or a game server.
Did anyone said something against amavis? Did not read anything.
Or are you referring to my tutorial? If yes it was a statement on a 128 MB vps.
wlanboy
Content Contributer
Takes an hour tops, all you have to do is copy and paste from a guide... I've set up mine and once for William or someone, doesn't take long at all.
Not sure why iRedMail is needed.
Probably also more secure than both, for different reasons.
Last edited by a moderator:
Nyr
Active Member
OMFG, I can set up a mail server in ten minutes if you want, that's not the point.
A *proper* setup takes hours and I had found really few guides written by someone who really knows all the stack used.
For example, the tutorial referenced by wlanboy has multiple fails that denote the lack of knoweldge of the author on some topics:
- Setting "disable_plaintext_auth = yes" will ensure you have problems with some Microsoft software.
- Uses system users for authentication, virtual users will do the same and it's better and more flexible.
- Virtual mappings are the proper way to set up aliases, but he sets up a simple aliases file instead.
- He doesn't explain that Postgrey will delay your reception of emails for even hours. It can even make you lose some email completely and isn't really useful to combat spam nowadays.
- He doesn't setup DKIM/SPF at all. In the year 2013, this isn't optional and you will have deliverability problems if that's missing.
- I don't remember how SpamAssassin works alone, but I think that he is either discarding all the Spam or only marking it without filtering (the first option, I suppose). Why not placing it on a spam folder for each user?
- IIRC, SpamAssassin checks a RBL or two by default but even if not with the Ubuntu configuration, he should probably set RBL checking at SpamAssassin and don't double checks like he is doing.
There are probably more misconfigurations, but those are the first who caught my eye. I don't really want to trash his work, but the tutorial was lacking.
If you really want to manually configure your own mail stack, this is the best guide I could find:
https://workaround.org/ispmail/squeeze
Please note that this is for Debian Squeeze and with Wheezy, some Dovecot configuration has changed.
If you decide that it isn't worth the effort, iRedMail is a *really* good way to do this work. I don't know why they use Apache instead of nginx or lighttpd, but the script does an enormous amount of work automatically and sets up a very decent mail stack.
Last edited by a moderator:
They're ok. The http api goes wonky at times, and they've had some smtp outages recently though. We ended up writing a feature-complete alternative that we use, but it's not for public consumption.
Nyr
Active Member
Mandrill is a good alternative to SendGrid too. I use them and am happy with the service.
SPF is exclusively DNS, there's nothing to change on the mail server itself. DKIM is easy enough to set up.
So, don't install postgrey, big deal? I don't get it. That saves time, one less thing to install.
Well if you want a different method you can set up amavisd-new and configure it to do whatever you want. Personally I prefer marking ***Spam***.
wlanboy
Content Contributer
I knew that this would come if I start one of my lean turorials about this topic.
This tutorial is about running a bare minimum mail server for private usage. I run this setup for 1 1/2 years for two of my domains. No abuse, no spam, no problems at all.
If you want an enterprise setup take Zimbra, cPanel, etc.
This is not about "this is the best solution" - this is all about starting a discussion.
My tutorials refine by feedback. Best example is my tutorial about iptables. A lot of good feedback and therefore a good solution for the community.
Good feedback is all about working examples. Not that simple "määähh I would do that better". But all necessary steps to add a feature / to do it in another way.
To your points:
- disable_plaintext_auth = yes ... yes this will crash Outlook Express on Windows 2000. Every mail client for Windows 7 and Windows 8 can handle this. But if you need that ... disable this option.
- I mentioned virtual mappings. You can use it if you want. For me the management is easier for real users - like cronjobs for backups.
- Yup it is simple to setup virtual_alias_domains and virtual_alias_maps. But my tutorial is at the beginning. I stated that I will add topics in the next weeks. You have to start somewhere. And you cannot say that the setup will not work for one domain and 10 accounts.
- Well ... time for some Myth Busters. Postgrey is not bad. And you will not loose Emails. It is delaying email delivery for 50 seconds.
After 1 1/2 year I can say that 90% of spam was blocked through Postgrey because not a single spammer was resending an email after it got rejected. Simple because the spammer does not see if it is rejected by spam detection of by greylisting. And I never got a call from anybody that his/her email did not arravied. Even AOL and mail.ru are handling postgrey in the right way.
And yes I am able to wait 50 seconds for an email!
- SPF is a simple TXT entry.
@ IN TXT "v=spf1 mx -all"
This entry means only the MX servers for the domain are allowed to send email for this domain.
Well quite a huge impact on security and for trust ... well default policies say: "if this test fails - ignore the test".
And of course you can add other ips too. But this is only needed if some ip is sending emails but is not a mx server.
- DKIM
Easy setup but one additional service listening. A simple DNS entry:
k=rsa; t=y; p=the_public_key;
Well a public openssl key to ensure that the mail server can be identified by a crypt hand shake to be a good email sender.
Like SPF its is all about mail forwarders.
I am not a MX server, I don't have any rDNS records, I send emails for thousand of domains - so I look like a spammer and I smell like a spammer but I am not a spammer because I am allowed to send emails for this domain.
Therefore you need DKIM.
But even services like Hotmail for domains (domains.live.com) do not need DKIM entries because they are generating unique subdomains (for MX) per mail services. And yes live mail is using SPF but only the simple "all MX servers are ok".
- You can do this. But this is a phase two step. Not needed but a nice to have. Something I will write about later.
- On my point of view my goal is to reject an email as soon as possible. And doing it right on the receiver side of postfix is the first (and therefore best place) to do it in the postfix chain.
So no deal breakers and not something everyone needs.
If you want to add some valuable feedback feel free to post on my mail server thread.
Nyr
Active Member
SPF and DKIM are very important parts to not be even mentioned. And yeah, they aren't hard to setup *if you know you should*.
Yeah, big deal because you shouldn't instruct people to setup something if they don't expect the consequences.
You clearly don't understand how Postgrey works. That 50 seconds is the time Postgrey will be dropping incoming email from a sender. The time you need to wait deppends on the sender's MTA configuration and can be several hours. If the MTA doesn't want to retry the delivery, you lost that email. And yeah, most modern MTAs try resending an email multiple times by default.
As I said, mi intention wasn't to trash your work at all. You simplified a complex setup and it's fine. I will maybe do an automated script myself, but that is going to take me some time, so I am not sure when it will be finished. Anyway, thanks for trying to help people to evade the big brother, really
Yes, I guess. But what I mean is, there doesn't need to be one single mail server tutorial. You can have instead a summary of what one should (or might want to) set up and then a link to each thing. Because guides to set up each of those already exist.
I thought the postgrey page was pretty clear about the consequences. Personally I don't see a reason to use it. Still, if you use email to communicate with people you know mostly, then it isn't a problem.
Also should add backup mail server to the guide. Some people may not want it, just like with postgrey the MTA will always retry later if the connection times out or is rejected or whatever, but backup is useful.
Last edited by a moderator: