Server administration
Dear Sirs,
There is Postfix+Dovecot+Sogo installation in our company.
I have attentively red Installation and Configuration Guide.
However, I could not find some information.
Could you give me an advise how to:
Add/remove e-mail address
Change user e-mail address password
Add user e-mail address into mail alias
Forward e-mail
List all users e-mails
What is the best GUI interface for Dovecot administration?
With kind regards,
Alex
Op 1-9-2019 om 14:41 schreef Aleksandr Mette via dovecot:
Dear Sirs,
There is Postfix+Dovecot+Sogo installation in our company.
I have attentively red Installation and Configuration Guide.
However, I could not find some information.
Could you give me an advise how to:
Add/remove e-mail address
Change user e-mail address password
Add user e-mail address into mail alias
Forward e-mail
List all users e-mails
What is the best GUI interface for Dovecot administration?
With kind regards,
Alex
Have a look at Postfixadmin. We administer 700+ club members with that tool
Egbert Jan, NL
On 9/1/19 5:41 AM, Aleksandr Mette via dovecot wrote:
Dear Sirs,
There is Postfix+Dovecot+Sogo installation in our company.
I have attentively red Installation and Configuration Guide.
However, I could not find some information.
Could you give me an advise how to:
Add/remove e-mail address
Change user e-mail address password
Add user e-mail address into mail alias
Forward e-mail
List all users e-mails
What is the best GUI interface for Dovecot administration?
Hello,
Have a look at iredmail (www.iredmail.org). Best server-in-a-box you are going to find, and free. They do have an upgraded web interface if you want to pay (worth it) and paid support, but for a single company, this is your mail solution.
Mike-
Am 01.09.2019 um 14:41 schrieb Aleksandr Mette via dovecot:
- Forward e-mail
Don't do that nor let your users auto-forward their mail received on your MX. Else you will end up faster than you think on blacklists as very likely your server will forward SPAM and gets classified as a SPAM source.
Alexander
On 2019-09-02 06:24, Alexander Dalloz via dovecot wrote:
Am 01.09.2019 um 14:41 schrieb Aleksandr Mette via dovecot:
- Forward e-mail
Don't do that nor let your users auto-forward their mail received on your MX. Else you will end up faster than you think on blacklists as very likely your server will forward SPAM and gets classified as a SPAM source.
You have to let users forward their email because this is functionality they expect. The trick is to spam scan all email first, otherwise as Alexander has said, you end up on RBL's.
On 9/1/19 2:53 PM, Michael Hallager via dovecot wrote:
On 2019-09-02 06:24, Alexander Dalloz via dovecot wrote:
Am 01.09.2019 um 14:41 schrieb Aleksandr Mette via dovecot:
- Forward e-mail
Don't do that nor let your users auto-forward their mail received on your MX. Else you will end up faster than you think on blacklists as very likely your server will forward SPAM and gets classified as a SPAM source.
You have to let users forward their email because this is functionality they expect. The trick is to spam scan all email first, otherwise as Alexander has said, you end up on RBL's.
Its actually a lot harder than this. Most default installations I've seen don't take into account Return-Path notifications (i.e. passing these notifications upstream to the origin), Troubleshooting last-node delivery issues (user created loops causing mailserver Denial of service if Quota Management wasn't properly configured, greylisting, outbound mail suppression) and Abuse (hacked accounts, interspersed third party server that truncate the return path to obfuscate the full origin).
Mishandling any of these can result in lowered IP reputation which would cause you to wind up on an RBL eventually.
You have to let users forward their email because this is functionality they expect. The trick is to spam scan all email first, otherwise as Alexander has said, you end up on RBL's.
Its actually a lot harder than this. Most default installations I've seen don't take into account Return-Path notifications (i.e. passing these notifications upstream to the origin),
What is a "default installation"?
I have a good working knowledge of all the software I have deployed in my and my clients mail servers and I have spent a considerable amount of time over the years furthering my understanding and perfecting my configs.
If, by "default installation", you mean take a piece of software off the shelf and follow a quick and dirty howto guide without any understanding of what the options mean, then of course under these situations people are going to run into issues.
On 1 Sep 2019, at 15:53, Michael Hallager <michael@nettrust.nz> wrote:
On 2019-09-02 06:24, Alexander Dalloz via dovecot wrote:
Am 01.09.2019 um 14:41 schrieb Aleksandr Mette via dovecot:
- Forward e-mail Don't do that nor let your users auto-forward their mail received on your MX. Else you will end up faster than you think on blacklists as very likely your server will forward SPAM and gets classified as a SPAM source.
You have to let users forward their email
No you don’t.
because this is functionality they expect.
Which they can manage themselves with IMAP logging and local rules.
The trick is to spam scan all email first, otherwise as Alexander has said, you end up on RBL's.
A lot of mail that is not spam when it arrives WILL be spam when it is forwarded as it will fail SPF, Fail DKIM, and any header checks will flag the mail as suspicious.
The only way to safely forward mail is to enclose it as an attachment, and this is something users do not want.
-- Oh never resist an impulse, Sabrina. Especially if it's terrible.
On 04/09/2019 15:26, @lbutlr via dovecot wrote:
A lot of mail that is not spam when it arrives WILL be spam when it is forwarded as it will fail SPF, Fail DKIM, and any header checks will flag the mail as suspicious.
The only way to safely forward mail is to enclose it as an attachment, and this is something users do not want.
IMO this is wrong. A classic forwarding (e.g. by .forward or by a MLM that does not alter Subject and/or body) will *not* break DKIM. Therefore it will pass e.g. DMARC...
Just have a look at the postfix-users mailing list as a good example...
Just my 2¢.
Juri
Is it not better you either employ a proper educated/trained person or outsouce the work to a company that has the know how?
-----Original Message----- From: Aleksandr Mette via dovecot [mailto:dovecot@dovecot.org] Sent: zondag 1 september 2019 14:42 To: dovecot@dovecot.org Subject: Server administration
Dear Sirs,
There is Postfix+Dovecot+Sogo installation in our company.
I have attentively red Installation and Configuration Guide.
However, I could not find some information.
Could you give me an advise how to:
Add/remove e-mail address
Change user e-mail address password
Add user e-mail address into mail alias
Forward e-mail
List all users e-mails
What is the best GUI interface for Dovecot administration?
With kind regards,
Alex
Add/remove e-mail address
Change user e-mail address password
Add user e-mail address into mail alias
Forward e-mail
List all users e-mails
I agree with Mark.
We can't answer them anyway because we don't know what backend you are using. Typically all of the above would be done in an SQL database with queries which you have written into various config files like /etc/postfix/main.conf and /etc/dovecot/conf.d/auth-sql.conf.ext (and likely others!)
Am 2019-09-02 09:55, schrieb Michael Hallager via dovecot:
Add/remove e-mail address
Change user e-mail address password
Add user e-mail address into mail alias
Forward e-mail
List all users e-mails
I agree with Mark.
We can't answer them anyway because we don't know what backend you are using. Typically all of the above would be done in an SQL database with queries which you have written into various config files like /etc/postfix/main.conf and /etc/dovecot/conf.d/auth-sql.conf.ext (and likely others!)
No, please don't spread the info that you would need an SQL DB for running a mail service. Unless you run a big install with lots of accounts where it can be handy to use some sort of meta tool (modoboa, postfixadmin, ...) there is zero need for an SQL backend. And in enterprise environments you would normally use an LDAP / AD infrastructure component where your user base lives.
Anyhow, someone like the OP who appears not to be much experienced in the field of running his own mail service should not get the idea a database backend is what he really needs. Start KISS and master all the complex requirements in a simple manner first.
Or outsource the task to a mail service provider.
Alexander
On 2 Sep 2019, at 02:08, Alexander Dalloz <ad+lists@uni-x.org> wrote:
Unless you run a big install with lots of accounts where it can be handy to use some sort of meta tool (modoboa, postfixadmin, ...) there is zero need for an SQL backend.
It is much easier to manage users, even a few users, via a database than dealing with local users. (Having manage both for years and years and finally having moved everyone into a database I’ve spent a lot of time on this, a database back end is better.
And even without having a large user base, a tool like postfixadmin lets the user do some of their management themselves (changing passwords, creating aliases, etc).
Anyhow, someone like the OP who appears not to be much experienced in the field of running his own mail service should not get the idea a database backend is what he really needs. Start KISS and master all the complex requirements in a simple manner first.
Since local users open a security hole into your mail server, I would argue that virtual users *is* keeping it simple, also, if you end up with many users in the future you will need to got to a database of some sort anyway, whether SQL-like or LDAP like, so you might as well do it from the start. I’d say SQL is simpler to deal with than LDAP, but I also have more experience with SQL, so I would.
Or outsource the task to a mail service provider.
Yes, this is the best choice.
-- Q: how do you titillate an ocelot? A: you oscillate its tit a lot.
Since local users open a security hole into your mail server, I would argue that virtual users
Can you elaborate on that? I would argue exactly the oposite. Having your virtual users in a 3rd party environment, adds only security exploits of that 3rd party environment.
I guess most run dovecot with mysql? So how many issues have been found in mysql compared to linux os user accounts. Linux is designed as multi user environment and most other 3rd party software not.
Most secure IS running with linux user accounts, you can even enhance this security with selinux. How are you ever going to realize this in something like mysql? If something goes wrong there everything under the mysql uid is accessible. Thus all accounts.
*is* keeping it simple, also, if you end up with many users in the future you will need to got to a database of some sort anyway, whether SQL-like or LDAP like,
participants (9)
-
＠lbutlr
-
Aleksandr Mette
-
Alexander Dalloz
-
Egbert
-
Juri Haberland
-
Marc Roos
-
Michael Hallager
-
Mike
-
Nathan Singer