New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
You probably have something already listening on port 25. You'll have to stop and deinstall it before.
Yes I will; mailcow's installed apps. Re-read what I said.
Ok I thought this was the error you were refering to.
Will tell you what's listening - it's probably master from postfix. uninstalling postfix* (postfix, postfix-pcre & postfix-mysql) will probably do the trick.
@Servercow - an uninstall script could be nice
edit: regarding my install, everything works fine - it's pretty neat. I'll read the code a bit more but so fat, it seems pretty clean
Thanks, @Servercow!
It is; Basically if the installer fails further into the install, e.g. sw installed but then a config issue we remove all and start again as opposed to the installer picking up where it left off.
@Aene Thanks for your report, this was fixed on GitHub.
@Sentinel Thanks for sharing your experience!
@scy There is.
You can uninstall mailcow with "bash misc/purge.sh" (no exec flag, to prevent accidental deletion) or "bash misc/purge.sh --all" which also deletes the webroot, databases etc.
@marrco I integrated the signatures now (master branch @ Git
Thank you, again!
By the way, the installer stops the installation, when a MTA, IMAP etc. server is running, to prevent its automatic removal when Postfix, Dovecot etc. are installed.
A clean Debian installation comes with exim4, just remove it before installing mailcow.
Ahh, almost forgot: @Anna_Parker moo back!
Nice, you thought about everything!
Congrats
Looks excellent.
Seems really cool. Is everything set up so that it's IPv6 ready? (SMTP, IMAP server, etc?)
Thx!
On debian Jessie you will probably want to manually enable spamassassin:
"systemctl enable spamassassin.service"
@Servercow : why did you provide fail2ban (https://github.com/andryyy/mailcow/tree/master/fail2ban/inst) rather than using the one packaged by the distro? Wouldn't it better to have as much software as possible coming from the distribution's packages? (security updates, signed packages are more easy to trust, etc)
Also, would you consider in a next release to add a way to select (in config file) if we want to install clamav (or other step) to make it easy to disable the install is it's unneeded?
Thanks
@scy, Ubuntu, Debian 7 and 8 all come with a different (older) version of fail2ban, even some filters were not correct. So I decided to just pull the stable version from GitHub and make one "general configuration" for all. It comes with a huge set of filters which you can benefit from, just have a look into it.
ClamAV has been a topic ever since... some want it, others don't. So I implemented an option to disable it in the control center. After that you can disable the daemon.
The SA packages are strange, I never run into an installation where the daemon was disabled. But someone told me a while ago, too. I just implemented a check for this, thanks!
Well clamav is nice but some people don't need it and it seems like MailCow can run fine on a 512MB vps without ClamaV while it would need more than 512MB with it running...
Also, I've seen that you choose to use reject_unknown_helo_hostname - doesn't it reject too many clean mail? Wouldn't reject_non_fqdn_helo_hostname & reject_invalid_helo_hostname be enough?
Thanks for the great work!
It is hard to find a one-fits-all config in Postfix. I tried a bunch of different configs and found this to be working best/good.
Most unknown HELOs were also non-FQDN or invalid in my tests.
Maybe I will add a config option for this, thanks!
This works great, but looking at my logs it was blocking legit mail from a major local ISP - so while I agree on the choice theoretically I had to remove it and find other alternatives... Searching google many people encounter the same problem when they use this option.
http://comments.gmane.org/gmane.mail.postfix.devel/2712
http://graysonpeddie.com/postfix-getting-helo-command-rejected-host-not-found/
A config option would be great but people can also modify the config file manually if the feel the need. But as the rejected messages won't show in the web interface they might not now that it's happening...
I made a PoC for this in the control center, but it still needs some review. It is important to use the correct sequence of restrictions, that's still kind of "problematic".
I wonder which major ISP uses an unknown HELO hostname. To be honest, this MUST be punished.
Consider looking into building a Nix package, if you have some spare time. That way, you'd have a cross-distro package that, if it works on one system, is guaranteed to work everywhere (though you may still need some distro-specific code for things like firewall configuration, as system components wouldn't be managed by Nix).
Thanks joepie91, will keep that in mind!
@scy, I just added "Recipient restrictions" to the control center, you can check it @ https://mail.mailcow.de/admin.php with admin:demo
Checked it, that's nice, even though it was not that hard to set it up changing the config file. The explanation of each rule makes the whole process easy
Thanks.
I just switched the demo installation to Ubuntu to find a bug that was reported, I hope I did not kick you out.
One quick suggestion I have is the option to have mailcow be configured as a backup mail server (with the same spam and virus filtering).
PS. If this functionality is already availableavailable please tell me how to activate it because I must have missed it...
There will be a new 0.12.1 release soon to fix that. You can then use mailcow as a backup mx for a domain. Have a look at https://mail.mailcow.de/mailbox.php (admin:demo).
I just updated the installation.
With 0.12.1 you will be able to use tags, too. Messages to an address like "[email protected]" will be stored in the folder "facebook" then.
There are some more minor fixes and changes (I think I already mentioned the time-limited aliases before?) you can find on GitHub.
André
Cool! Thanks for all the hard work
Look nice, keep the hard work. We'll test it for sure.
MX2 is interesting even though we hope never to need it
In that case that would send the emails back to the MX1 when it comes back up or that creates an account on the server? Thx
First you need to add a backup mx domain via control center.
Next you add a "mailbox" to your backup mx domain which then gets recognized as a relay recipient (you see a "forward" icon in front of it).
You will need to add all relay recipients as a mailbox (you can use a MySQL dump from your final destination mx).
This way we can convert a backup mx domain to a final destination domain by just removing the "Backup MX" checkbox. You won't need to add any mailboxes first. Might help when you cannot recover your primary mx in time.
Spam and virus checks are not skipped for relayed domains.
Nice!
Thoughts on integrating SOGo backend? Seems like it would add a lot of features: CalDAV, CardDAV, GroupDAV, ActiveSync, OpenChange.
Finishing my setup now - but whats the easiest way to do a full mail backup here?
I rsync /, tar gz it and then run it through gpg to encrypt it. Works well, can give you code if you have use for it.
Is the backupmx already implemented? looking for exactly that, something i can just run as backupmx with a webinterface.
Yep:
btw @Servercow :
Is it needed to set up a rule via roundcube to get that working or is it supposed to work magically out of the box? Thanks