Re: [SOGo] Client host rejected: cannot find your reverse hostname
Hi miguel, O think that its solved. O asked to my provider to create a reverse dns. Thanks, Pedro Antunes From: "users-requ...@sogo.nu" on behalf of Miguel Mucio Santos Moreira Reply-To: "users@sogo.nu" Date: Monday, 11 February 2019 at 11:41 To: "users@sogo.nu" Subject: Re: [SOGo] Client host rejected: cannot find your reverse hostname Hello Pedro! Your problem, probably is regard to DNS reverse validation. By default Postfix checks if an ip cliente has a name, if so, it also checks if client name matches with the client ip address. I think for more details you can google postfix reverse check. Regards -- Miguel Moreira Gerente DPR/SRE/GSR - Gerência de Serviços de Rede +55(31)3339-1401 PRODEMGE - Companhia de Tecnologia da Informação do Estado de Minas Gerais Aviso: Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação sigilosa e legalmente protegida. O uso impróprio será tratado conforme as normas da empresa e a legislação em vigor. Caso não seja o destinatário, favor notificar o remetente, ficando proibidas a utilização, divulgação, cópia e distribuição. Em Sexta, Fevereiro 08, 2019 19:17 -02, "Pedro Antunes" (pantu...@suroot.pt) escreveu: Hi, I’m not receiving some emails from some domains. Example: postfix-mailcow_1| Feb 8 21:10:08 mail postfix/smtpd[18033]: NOQUEUE: reject: RCPT from unknown[52.166.14.58]: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [52.166.14.58]; from= to= proto=ESMTP helo= Anybody can help me to solve it? Regards, Pedro Antunes -- users@sogo.nu https://inverse.ca/sogo/lists -- users@sogo.nu https://inverse.ca/sogo/lists -- users@sogo.nu https://inverse.ca/sogo/lists
[SOGo] Client host rejected: cannot find your reverse hostname
Hi, I’m not receiving some emails from some domains. Example: postfix-mailcow_1| Feb 8 21:10:08 mail postfix/smtpd[18033]: NOQUEUE: reject: RCPT from unknown[52.166.14.58]: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [52.166.14.58]; from= to= proto=ESMTP helo= Anybody can help me to solve it? Regards, Pedro Antunes -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] pid X has been hanging in the same request for X minutes
Christian,
I'm using mailcow dockerized.
When I change PREFORK, nothing happens... number of process is the same.
I changed WOWorkersCount to 100 and I have 101 proccess's
[root@mail ~]# ps -ef | grep -i sogo | wc -l
101
What's recommended workers to 280 mailboxes?
This is constantly down...
Regards,
Pedro Antunes
On 05/02/2019, 13:41, "users-requ...@sogo.nu on behalf of Christian Mack"
wrote:
Hello
This means, you do not have enough workers running.
Beware WOWorkersCount in sogo.conf only affects SOGo when running in
manual debug mode.
Check your default configuration used on startup.
On Debian/Ubuntu systems you will find it in /etc/default/sogo
Value PREFORK will set the amount of workers.
Kind regards,
Christian Mack
Am 05.02.19 um 13:04 schrieb Pedro Antunes (pantu...@suroot.pt):
> Hi again,
>
> I have constantly with bellow error:
>
> sogo-mailcow_1 | Feb 5 11:38:30 05e81f192545 sogod [11]: [ERROR]
<0x0x56396fb74f00[WOWatchDog]> No child available to handle incoming request!
> sogo-mailcow_1 | Feb 5 11:38:30 05e81f192545 sogod [11]: [ERROR]
<0x0x56396fb74f00[WOWatchDog]> No child available to handle incoming request!
> sogo-mailcow_1 | Feb 5 11:38:30 05e81f192545 sogod [11]: [ERROR]
<0x0x56396fb74f00[WOWatchDog]> No child available to handle incoming request!
> sogo-mailcow_1 | Feb 5 11:38:31 05e81f192545 sogod [11]: [ERROR]
<0x0x56396fb74f00[WOWatchDog]> No child available to handle incoming request!
> sogo-mailcow_1 | Feb 5 11:38:31 05e81f192545 sogod [11]: [ERROR]
<0x0x56396fb74f00[WOWatchDog]> No child available to handle incoming request!
> sogo-mailcow_1 | Feb 5 11:38:31 05e81f192545 sogod [11]: [ERROR]
<0x0x56396fb74f00[WOWatchDog]> No child available to handle incoming request!
> sogo-mailcow_1 | Feb 5 11:38:31 05e81f192545 sogod [11]: [ERROR]
<0x0x56396fb74f00[WOWatchDog]> No child available to handle incoming request!
> sogo-mailcow_1 | Feb 5 11:38:31 05e81f192545 sogod [11]: [ERROR]
<0x0x56396fb74f00[WOWatchDog]> No child available to handle incoming request!
> sogo-mailcow_1 | Feb 5 11:38:31 05e81f192545 sogod [11]: [ERROR]
<0x0x56396fb74f00[WOWatchDog]> No child available to handle incoming request!
> sogo-mailcow_1 | Feb 5 11:38:31 05e81f192545 sogod [11]: [ERROR]
<0x0x56396fb74f00[WOWatchDog]> No child available to handle incoming request!
> sogo-mailcow_1 | Feb 5 11:38:31 05e81f192545 sogod [11]: [ERROR]
<0x0x56396fb74f00[WOWatchDog]> No child available to handle incoming request!
> sogo-mailcow_1 | Feb 5 11:38:31 05e81f192545 sogod [11]: [ERROR]
<0x0x56396fb74f00[WOWatchDog]> No child available to handle incoming request!
> sogo-mailcow_1 | Feb 5 11:38:32 05e81f192545 sogod [11]: [ERROR]
<0x0x56396fb74f00[WOWatchDog]> No child available to handle incoming request!
>
> After that, I need restart sogo to solve this situation temporarily.
>
> At this moment I have this configuration:
> 280 mailboxes.
>
> WOWorkersCount = "40";
> SxVMemLimit = 384;
> SOGoMaximumPingInterval = 3540;
> SOGoInternalSyncInterval = 45;
> SOGoMaximumSyncInterval = 60;
>
> Regards,
>
> Pedro Antunes
>
>
> On 05/02/2019, 09:52, "Pedro Antunes" wrote:
>
> Thank you for the clarification. __
>
>
> Regards,
> Pedro Antunes
>
> On 05/02/2019, 08:08, "users-requ...@sogo.nu on behalf of Christian
Mack" wrote:
>
> Hello
>
> You use ActiveSync.
> ActiveSync blocks one worker for long times.
> Those messages are normal then.
> So nothing to worry about, as long as you don't get:
>
> ... [WARN] <0x0x56316ad28f30[WOWatchDogChild]> safety belt --
sending
> KILL signal to pid 18838
>
> Only then is your worker killed, because it exceeded the set max
time in
> WOWatchDogRequestTimeout (in Minutes).
>
>
> Kind regards,
> Christian Mack
>
>
> Am 04.02.19 um 19:22 schrieb Pedro Antunes (pantu...@suroot.pt):
> > Hi All,
> >
> > I migrated my production server (today) to mailcow.
> >
> > After analyze logs, I view that I have these constantly WARNS.
> >
&
Re: [SOGo] pid X has been hanging in the same request for X minutes
Hi again,
I have constantly with bellow error:
sogo-mailcow_1 | Feb 5 11:38:30 05e81f192545 sogod [11]: [ERROR]
<0x0x56396fb74f00[WOWatchDog]> No child available to handle incoming request!
sogo-mailcow_1 | Feb 5 11:38:30 05e81f192545 sogod [11]: [ERROR]
<0x0x56396fb74f00[WOWatchDog]> No child available to handle incoming request!
sogo-mailcow_1 | Feb 5 11:38:30 05e81f192545 sogod [11]: [ERROR]
<0x0x56396fb74f00[WOWatchDog]> No child available to handle incoming request!
sogo-mailcow_1 | Feb 5 11:38:31 05e81f192545 sogod [11]: [ERROR]
<0x0x56396fb74f00[WOWatchDog]> No child available to handle incoming request!
sogo-mailcow_1 | Feb 5 11:38:31 05e81f192545 sogod [11]: [ERROR]
<0x0x56396fb74f00[WOWatchDog]> No child available to handle incoming request!
sogo-mailcow_1 | Feb 5 11:38:31 05e81f192545 sogod [11]: [ERROR]
<0x0x56396fb74f00[WOWatchDog]> No child available to handle incoming request!
sogo-mailcow_1 | Feb 5 11:38:31 05e81f192545 sogod [11]: [ERROR]
<0x0x56396fb74f00[WOWatchDog]> No child available to handle incoming request!
sogo-mailcow_1 | Feb 5 11:38:31 05e81f192545 sogod [11]: [ERROR]
<0x0x56396fb74f00[WOWatchDog]> No child available to handle incoming request!
sogo-mailcow_1 | Feb 5 11:38:31 05e81f192545 sogod [11]: [ERROR]
<0x0x56396fb74f00[WOWatchDog]> No child available to handle incoming request!
sogo-mailcow_1 | Feb 5 11:38:31 05e81f192545 sogod [11]: [ERROR]
<0x0x56396fb74f00[WOWatchDog]> No child available to handle incoming request!
sogo-mailcow_1 | Feb 5 11:38:31 05e81f192545 sogod [11]: [ERROR]
<0x0x56396fb74f00[WOWatchDog]> No child available to handle incoming request!
sogo-mailcow_1 | Feb 5 11:38:31 05e81f192545 sogod [11]: [ERROR]
<0x0x56396fb74f00[WOWatchDog]> No child available to handle incoming request!
sogo-mailcow_1 | Feb 5 11:38:32 05e81f192545 sogod [11]: [ERROR]
<0x0x56396fb74f00[WOWatchDog]> No child available to handle incoming request!
After that, I need restart sogo to solve this situation temporarily.
At this moment I have this configuration:
280 mailboxes.
WOWorkersCount = "40";
SxVMemLimit = 384;
SOGoMaximumPingInterval = 3540;
SOGoInternalSyncInterval = 45;
SOGoMaximumSyncInterval = 60;
Regards,
Pedro Antunes
On 05/02/2019, 09:52, "Pedro Antunes" wrote:
Thank you for the clarification. __
Regards,
Pedro Antunes
On 05/02/2019, 08:08, "users-requ...@sogo.nu on behalf of Christian Mack"
wrote:
Hello
You use ActiveSync.
ActiveSync blocks one worker for long times.
Those messages are normal then.
So nothing to worry about, as long as you don't get:
... [WARN] <0x0x56316ad28f30[WOWatchDogChild]> safety belt -- sending
KILL signal to pid 18838
Only then is your worker killed, because it exceeded the set max time in
WOWatchDogRequestTimeout (in Minutes).
Kind regards,
Christian Mack
Am 04.02.19 um 19:22 schrieb Pedro Antunes (pantu...@suroot.pt):
> Hi All,
>
> I migrated my production server (today) to mailcow.
>
> After analyze logs, I view that I have these constantly WARNS.
>
> Anybody have this problem? How I can solve it?
>
>
> sogo-mailcow_1 | Feb 4 18:15:31 05e81f192545 sogod [11]:
[WARN] <0x0x557253cc7640[WOWatchDogChild]> pid 455 has been hanging in the same
request for 6 minutes
> sogo-mailcow_1 | Feb 4 18:15:31 05e81f192545 sogod [11]:
[WARN] <0x0x557253c672c0[WOWatchDogChild]> pid 52 has been hanging in the same
request for 8 minutes
> sogo-mailcow_1 | Feb 4 18:15:41 05e81f192545 sogod [11]:
[WARN] <0x0x557253c5b1c0[WOWatchDogChild]> pid 448 has been hanging in the same
request for 13 minutes
> sogo-mailcow_1 | Feb 4 18:15:41 05e81f192545 sogod [11]:
[WARN] <0x0x557253e0a630[WOWatchDogChild]> pid 72 has been hanging in the same
request for 13 minutes
> sogo-mailcow_1 | Feb 4 18:15:42 05e81f192545 sogod [11]:
[WARN] <0x0x557253cc7290[WOWatchDogChild]> pid 451 has been hanging in the same
request for 13 minutes
> sogo-mailcow_1 | Feb 4 18:15:42 05e81f192545 sogod [11]:
[WARN] <0x0x557253cce1b0[WOWatchDogChild]> pid 452 has been hanging in the same
request for 13 minutes
> sogo-mailcow_1 | Feb 4 18:15:43 05e81f192545 sogod [11]:
[WARN] <0x0x557253c921e0[WOWatchDogChild]> pid 454 has been hanging in the same
request for 13 minutes
> sogo-mailcow_1 | Feb 4 18:15:52 05e81f192545 sogod [11]:
[WARN] <0x0x557253cc6b00[WOWatchDogChild]>
Re: [SOGo] pid X has been hanging in the same request for X minutes
Thank you for the clarification. __ Regards, Pedro Antunes On 05/02/2019, 08:08, "users-requ...@sogo.nu on behalf of Christian Mack" wrote: Hello You use ActiveSync. ActiveSync blocks one worker for long times. Those messages are normal then. So nothing to worry about, as long as you don't get: ... [WARN] <0x0x56316ad28f30[WOWatchDogChild]> safety belt -- sending KILL signal to pid 18838 Only then is your worker killed, because it exceeded the set max time in WOWatchDogRequestTimeout (in Minutes). Kind regards, Christian Mack Am 04.02.19 um 19:22 schrieb Pedro Antunes (pantu...@suroot.pt): > Hi All, > > I migrated my production server (today) to mailcow. > > After analyze logs, I view that I have these constantly WARNS. > > Anybody have this problem? How I can solve it? > > > sogo-mailcow_1 | Feb 4 18:15:31 05e81f192545 sogod [11]: [WARN] <0x0x557253cc7640[WOWatchDogChild]> pid 455 has been hanging in the same request for 6 minutes > sogo-mailcow_1 | Feb 4 18:15:31 05e81f192545 sogod [11]: [WARN] <0x0x557253c672c0[WOWatchDogChild]> pid 52 has been hanging in the same request for 8 minutes > sogo-mailcow_1 | Feb 4 18:15:41 05e81f192545 sogod [11]: [WARN] <0x0x557253c5b1c0[WOWatchDogChild]> pid 448 has been hanging in the same request for 13 minutes > sogo-mailcow_1 | Feb 4 18:15:41 05e81f192545 sogod [11]: [WARN] <0x0x557253e0a630[WOWatchDogChild]> pid 72 has been hanging in the same request for 13 minutes > sogo-mailcow_1 | Feb 4 18:15:42 05e81f192545 sogod [11]: [WARN] <0x0x557253cc7290[WOWatchDogChild]> pid 451 has been hanging in the same request for 13 minutes > sogo-mailcow_1 | Feb 4 18:15:42 05e81f192545 sogod [11]: [WARN] <0x0x557253cce1b0[WOWatchDogChild]> pid 452 has been hanging in the same request for 13 minutes > sogo-mailcow_1 | Feb 4 18:15:43 05e81f192545 sogod [11]: [WARN] <0x0x557253c921e0[WOWatchDogChild]> pid 454 has been hanging in the same request for 13 minutes > sogo-mailcow_1 | Feb 4 18:15:52 05e81f192545 sogod [11]: [WARN] <0x0x557253cc6b00[WOWatchDogChild]> pid 380 has been hanging in the same request for 3 minutes > sogo-mailcow_1 | Feb 4 18:15:53 05e81f192545 sogod [11]: [WARN] <0x0x557253c5c6a0[WOWatchDogChild]> pid 49 has been hanging in the same request for 7 minutes > sogo-mailcow_1 | Feb 4 18:15:57 05e81f192545 sogod [11]: [WARN] <0x0x557253c67c20[WOWatchDogChild]> pid 530 has been hanging in the same request for 3 minutes > sogo-mailcow_1 | Feb 4 18:16:00 05e81f192545 sogod [11]: [WARN] <0x0x557253cc6e10[WOWatchDogChild]> pid 406 has been hanging in the same request for 18 minutes > sogo-mailcow_1 | Feb 4 18:16:04 05e81f192545 sogod [11]: [WARN] <0x0x557253caad30[WOWatchDogChild]> pid 66 has been hanging in the same request for 9 minutes > sogo-mailcow_1 | Feb 4 18:16:05 05e81f192545 sogod [11]: [WARN] <0x0x557253cac340[WOWatchDogChild]> pid 70 has been hanging in the same request for 2 minutes > sogo-mailcow_1 | Feb 4 18:16:05 05e81f192545 sogod [11]: [WARN] <0x0x557253c673e0[WOWatchDogChild]> pid 279 has been hanging in the same request for 18 minutes > sogo-mailcow_1 | Feb 4 18:16:09 05e81f192545 sogod [11]: [WARN] <0x0x557253c5d160[WOWatchDogChild]> pid 456 has been hanging in the same request for 8 minutes > sogo-mailcow_1 | Feb 4 18:16:10 05e81f192545 sogod [11]: [WARN] <0x0x557253cab720[WOWatchDogChild]> pid 69 has been hanging in the same request for 17 minutes > sogo-mailcow_1 | Feb 4 18:16:12 05e81f192545 sogod [11]: [WARN] <0x0x557253cc7010[WOWatchDogChild]> pid 81 has been hanging in the same request for 8 minutes > sogo-mailcow_1 | Feb 4 18:16:12 05e81f192545 sogod [11]: [WARN] <0x0x557253cc6ce0[WOWatchDogChild]> pid 78 has been hanging in the same request for 8 minutes > sogo-mailcow_1 | Feb 4 18:16:12 05e81f192545 sogod [11]: [WARN] <0x0x557253c5b670[WOWatchDogChild]> pid 47 has been hanging in the same request for 8 minutes > sogo-mailcow_1 | Feb 4 18:16:12 05e81f192545 sogod [11]: [WARN] <0x0x557253c5b9e0[WOWatchDogChild]> pid 48 has been hanging in the same request for 8 minutes > sogo-mailcow_1 | Feb 4 18:16:12 05e81f192545 sogod [11]: [WARN] <0x0x557253c5b0c0[WOWatchDogChild]> pid 273 has been hanging in the same request for 8 minutes > sogo-mailcow_1 | Feb 4 18:16:13 05e81f192545 sogod [11]: [WARN] <0x0x557253c5b2e0[WOWatchDogChild]> pid 450 has been hanging in the same request for 4 minutes >
[SOGo] pid X has been hanging in the same request for X minutes
Hi All, I migrated my production server (today) to mailcow. After analyze logs, I view that I have these constantly WARNS. Anybody have this problem? How I can solve it? sogo-mailcow_1 | Feb 4 18:15:31 05e81f192545 sogod [11]: [WARN] <0x0x557253cc7640[WOWatchDogChild]> pid 455 has been hanging in the same request for 6 minutes sogo-mailcow_1 | Feb 4 18:15:31 05e81f192545 sogod [11]: [WARN] <0x0x557253c672c0[WOWatchDogChild]> pid 52 has been hanging in the same request for 8 minutes sogo-mailcow_1 | Feb 4 18:15:41 05e81f192545 sogod [11]: [WARN] <0x0x557253c5b1c0[WOWatchDogChild]> pid 448 has been hanging in the same request for 13 minutes sogo-mailcow_1 | Feb 4 18:15:41 05e81f192545 sogod [11]: [WARN] <0x0x557253e0a630[WOWatchDogChild]> pid 72 has been hanging in the same request for 13 minutes sogo-mailcow_1 | Feb 4 18:15:42 05e81f192545 sogod [11]: [WARN] <0x0x557253cc7290[WOWatchDogChild]> pid 451 has been hanging in the same request for 13 minutes sogo-mailcow_1 | Feb 4 18:15:42 05e81f192545 sogod [11]: [WARN] <0x0x557253cce1b0[WOWatchDogChild]> pid 452 has been hanging in the same request for 13 minutes sogo-mailcow_1 | Feb 4 18:15:43 05e81f192545 sogod [11]: [WARN] <0x0x557253c921e0[WOWatchDogChild]> pid 454 has been hanging in the same request for 13 minutes sogo-mailcow_1 | Feb 4 18:15:52 05e81f192545 sogod [11]: [WARN] <0x0x557253cc6b00[WOWatchDogChild]> pid 380 has been hanging in the same request for 3 minutes sogo-mailcow_1 | Feb 4 18:15:53 05e81f192545 sogod [11]: [WARN] <0x0x557253c5c6a0[WOWatchDogChild]> pid 49 has been hanging in the same request for 7 minutes sogo-mailcow_1 | Feb 4 18:15:57 05e81f192545 sogod [11]: [WARN] <0x0x557253c67c20[WOWatchDogChild]> pid 530 has been hanging in the same request for 3 minutes sogo-mailcow_1 | Feb 4 18:16:00 05e81f192545 sogod [11]: [WARN] <0x0x557253cc6e10[WOWatchDogChild]> pid 406 has been hanging in the same request for 18 minutes sogo-mailcow_1 | Feb 4 18:16:04 05e81f192545 sogod [11]: [WARN] <0x0x557253caad30[WOWatchDogChild]> pid 66 has been hanging in the same request for 9 minutes sogo-mailcow_1 | Feb 4 18:16:05 05e81f192545 sogod [11]: [WARN] <0x0x557253cac340[WOWatchDogChild]> pid 70 has been hanging in the same request for 2 minutes sogo-mailcow_1 | Feb 4 18:16:05 05e81f192545 sogod [11]: [WARN] <0x0x557253c673e0[WOWatchDogChild]> pid 279 has been hanging in the same request for 18 minutes sogo-mailcow_1 | Feb 4 18:16:09 05e81f192545 sogod [11]: [WARN] <0x0x557253c5d160[WOWatchDogChild]> pid 456 has been hanging in the same request for 8 minutes sogo-mailcow_1 | Feb 4 18:16:10 05e81f192545 sogod [11]: [WARN] <0x0x557253cab720[WOWatchDogChild]> pid 69 has been hanging in the same request for 17 minutes sogo-mailcow_1 | Feb 4 18:16:12 05e81f192545 sogod [11]: [WARN] <0x0x557253cc7010[WOWatchDogChild]> pid 81 has been hanging in the same request for 8 minutes sogo-mailcow_1 | Feb 4 18:16:12 05e81f192545 sogod [11]: [WARN] <0x0x557253cc6ce0[WOWatchDogChild]> pid 78 has been hanging in the same request for 8 minutes sogo-mailcow_1 | Feb 4 18:16:12 05e81f192545 sogod [11]: [WARN] <0x0x557253c5b670[WOWatchDogChild]> pid 47 has been hanging in the same request for 8 minutes sogo-mailcow_1 | Feb 4 18:16:12 05e81f192545 sogod [11]: [WARN] <0x0x557253c5b9e0[WOWatchDogChild]> pid 48 has been hanging in the same request for 8 minutes sogo-mailcow_1 | Feb 4 18:16:12 05e81f192545 sogod [11]: [WARN] <0x0x557253c5b0c0[WOWatchDogChild]> pid 273 has been hanging in the same request for 8 minutes sogo-mailcow_1 | Feb 4 18:16:13 05e81f192545 sogod [11]: [WARN] <0x0x557253c5b2e0[WOWatchDogChild]> pid 450 has been hanging in the same request for 4 minutes Regards, Pedro Antunes -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] Signing into sogo redirects you to login again
Hi Matthew,
I had same problem but it was related with virtualhost that I created to
webmail.
My solution was redirect / to /SOGo on nginx.
location / {
try_files $uri $uri/ @strip-ext;
return 301 /SOGo$1;
}
Regards,
Pedro Antunes
On 25/01/2019, 23:32, "users-requ...@sogo.nu on behalf of Matthew Valdez"
wrote:
Hello all,
Currently have SOGo setup to authenticate and login using ldap for our
Active directory and when I go to sign in, it will redirect you to
sogo/SOGo/username and it will be the login screen again, and you can
keep repeating the login. I am assuming it has something to do with the
database? I created the database and the user, I tried creating the
tables and nothing changes. Below is my sogo config file with a few
modifications to remove any "sensitive" data.
Thanks,
-Matthew
{
SOGoProfileURL=
"mysql://sogo:sogo@127.0.0.1:3306/sogo/sogo_user_profile";
OCSFolderInfoURL =
"mysql://sogo:sogo@127.0.0.1:3306/sogo/sogo_folder_info";
OCSSessionsFolderURL =
"mysql://sogo:sogo@127.0.0.1:3306/sogo/sogo_sessions_info";
OCSEMailAlarmsFolderURL =
"mysql://sogo:sogo@127.0.0.1:3306/sogo/sogo_alarms_folder";
OCSStoreURL =
"mysql://sogo:sogo@127.0.0.1:3306/sogo/sogo_store";
OCSAclURL =
"mysql://sogo:sogo@127.0.0.1:3306/sogo/sogo_acl";
OCSCacheFolderURL =
"mysql://sogo:sogo@127.0.0.1:3306/sogo/sogo_cache_folder";
SOGoLanguage = English;
SOGoAuthenticationType= LDAP;
SOGoSieveScriptsEnabled = YES;
SOGoForwardEnabled= YES;
SOGoVacationEnabled = YES;
SOGoEnableEMailAlarms = YES;
SOGoTimeZone = US/Central;
SOGoSieveServer = sieve://127.0.0.1:4190;
SOGoCalendarDefaultRoles = ("PublicDAndTViewer");
SOGoAppointmentSendEMailNotifications = YES;
SOGoUserSources = (
{
type= ldap;
CNFieldName = cn;
IDFieldName = uid;
UIDFiledName= sAMAccountName;
baseDN = "CN=Users,DC=domain,DC=local";
bindDN = "CN=Sogo
User,CN=Users,DC=domain,DC=local";
bindFields = (sAMAccountName);
bindPassword= sogo;
canAuthenticate = YES;
displayName = "Active Directory";
hostname= "ldap://ipaddress:389;;
id = directory;
isAddressBook = YES;
}
);
}
--
Matthew Valdez
Ludlum Measurements, Inc.
501 Oak Street
Sweetwater, TX 79556 USA
(325) 235-5494 Phone, ext:3393
maval...@ludlums.com
--
users@sogo.nu
https://inverse.ca/sogo/lists
--
users@sogo.nu
https://inverse.ca/sogo/lists
Re: [SOGo] Alias for all mailboxes
I'm using postfix __
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks,
check_recipient_access
proxy:mysql:/opt/postfix/conf/sql/mysql_tls_enforce_in_policy.cf,
reject_invalid_helo_hostname, reject_unknown_reverse_client_hostname,
reject_unauth_destination
I think is there that I can restrict.. do you know how I can do it?
Regards,
Pedro Antunes
On 25/01/2019, 19:39, "Pedro Antunes" wrote:
How I can check it?
I'm using mailcow with dovecote.
Thanks in advance,
Pedro Antunes
On 25/01/2019, 18:13, "Christoph Kreutzer"
wrote:
Hi Pedro,
Do you use Postfix as MTA? Then it should be possible.
Actually, you can do quite the same with any other lookup instead of
LDAP (I also use one regexp as you can see):
http://www.postfix.org/DATABASE_README.html#types
If your user source is e.g. MySQL or Postgres, you can use that, too.
Or as the easiest forms in files there are the hash and texthash types.
So if you want to replace my ldap-internal_user_lookup.cf, you could
use a file of allowed senders in the following format (type texthash):
us...@example.com OK
us...@example.com OK
ldap-check_recipient_access.cf is the same, but you should have a list
that returns, so like:
li...@example.com internal_user_lookup
li...@example.com internal_user_lookup
Instead of texthash, it is usually better to use hash. For texthash,
you need to reload postfix to make it pick up the changes. For hash, you only
need to run postmap on the file (see the doc above).
Best regards,
Christoph
> Am 25.01.2019 um 17:24 schrieb Pedro Antunes :
>
> Thanks for your help.
>
> Without LDAP, I can restrict senders?
>
> Exists any config file to this?
>
> Regards,
> Pedro Antunes
>
> From: Christoph Kreutzer
> Date: Friday, 25 January 2019 at 15:59
> To: "users@sogo.nu"
> Cc: "pantu...@suroot.pt"
> Subject: Re: [SOGo] Alias for all mailboxes
>
> Hi,
>
> I implemented something like that in the backend, too. I’m using
OpenLDAP.
>
> I have a script (PHP CLI script as part of a Zend Framework
management frontend) that uses a config file containing some LDAP searches to
automatically add/remove users to/from groups based on some attributes. That
part is hard to share, but it shouldn’t be too hard implementing it with some
Shell script if you are using the LDAP backend, too.
>
> Regarding restrictions:
> As MJ proposed, I handle that in Postfix.
>
> In main.cf, after smtpd_recipient_restrictions and
smtpd_data_restrictions, there is a section:
> # allow setting action internal_user_lookup to disallow non-listed
users as sender
> smtpd_restriction_classes =
> internal_user_lookup
> internal_user_lookup =
> check_sender_access
ldap:/etc/postfix/ldap-internal_user_lookup.cf,
> # reject if not successful
> check_recipient_access
regexp:/etc/postfix/regexp-check_recipient_access-reject,
> reject
>
> ldap-internal_user_lookup.cf looks like this:
> # resolve all mail addresses to OK (for checking of internal users)
> query_filter =
(&(|(objectClass=mailGroup)(objectClass=mailRecipient)(objectClass=inetOrgPerson))(|(mail=%s)(mailAlternateAddress=%s)(mailForwardingAddress=%s)(mailRoutingAddress=%s)))
> result_attribute = mail
> result_format = OK
> (LDAP config is missing here)
>
> regexp-check_recipient_access-reject:
> # the same message for all
> /^(.*)$/550 5.4.1 Delivery to this mailbox is not permitted
for you
>
> You see the point - if the sender address is somewhere in my
Directory, the LDAP result returns OK - Mail is accepted. Otherwise, it returns
no result and the second check is performed.
>
> # postmap -q kreutzer.christ...@yesthatsmymail.com
ldap:/etc/postfix/ldap-internal_user_lookup.cf
> OK
> # postmap -q kreutzer.christ...@example.com
ldap:/etc/postfix/ldap-internal_user_lookup.cf
> (no result)
> # postmap -q kreutzer.christ...@example.com
regexp:/etc/postfix/regexp-check_recipient_access-reject
> 550 5.4.1 Delivery to this mailbox is not permitted for you
>
> That always returns the 550 so the message will be rejected.
>
>
> But how
Re: [SOGo] Alias for all mailboxes
How I can check it?
I'm using mailcow with dovecote.
Thanks in advance,
Pedro Antunes
On 25/01/2019, 18:13, "Christoph Kreutzer"
wrote:
Hi Pedro,
Do you use Postfix as MTA? Then it should be possible.
Actually, you can do quite the same with any other lookup instead of LDAP
(I also use one regexp as you can see):
http://www.postfix.org/DATABASE_README.html#types
If your user source is e.g. MySQL or Postgres, you can use that, too. Or as
the easiest forms in files there are the hash and texthash types.
So if you want to replace my ldap-internal_user_lookup.cf, you could use a
file of allowed senders in the following format (type texthash):
us...@example.com OK
us...@example.com OK
ldap-check_recipient_access.cf is the same, but you should have a list that
returns, so like:
li...@example.com internal_user_lookup
li...@example.com internal_user_lookup
Instead of texthash, it is usually better to use hash. For texthash, you
need to reload postfix to make it pick up the changes. For hash, you only need
to run postmap on the file (see the doc above).
Best regards,
Christoph
> Am 25.01.2019 um 17:24 schrieb Pedro Antunes :
>
> Thanks for your help.
>
> Without LDAP, I can restrict senders?
>
> Exists any config file to this?
>
> Regards,
> Pedro Antunes
>
> From: Christoph Kreutzer
> Date: Friday, 25 January 2019 at 15:59
> To: "users@sogo.nu"
> Cc: "pantu...@suroot.pt"
> Subject: Re: [SOGo] Alias for all mailboxes
>
> Hi,
>
> I implemented something like that in the backend, too. I’m using OpenLDAP.
>
> I have a script (PHP CLI script as part of a Zend Framework management
frontend) that uses a config file containing some LDAP searches to
automatically add/remove users to/from groups based on some attributes. That
part is hard to share, but it shouldn’t be too hard implementing it with some
Shell script if you are using the LDAP backend, too.
>
> Regarding restrictions:
> As MJ proposed, I handle that in Postfix.
>
> In main.cf, after smtpd_recipient_restrictions and
smtpd_data_restrictions, there is a section:
> # allow setting action internal_user_lookup to disallow non-listed users
as sender
> smtpd_restriction_classes =
> internal_user_lookup
> internal_user_lookup =
> check_sender_access ldap:/etc/postfix/ldap-internal_user_lookup.cf,
> # reject if not successful
> check_recipient_access
regexp:/etc/postfix/regexp-check_recipient_access-reject,
> reject
>
> ldap-internal_user_lookup.cf looks like this:
> # resolve all mail addresses to OK (for checking of internal users)
> query_filter =
(&(|(objectClass=mailGroup)(objectClass=mailRecipient)(objectClass=inetOrgPerson))(|(mail=%s)(mailAlternateAddress=%s)(mailForwardingAddress=%s)(mailRoutingAddress=%s)))
> result_attribute = mail
> result_format = OK
> (LDAP config is missing here)
>
> regexp-check_recipient_access-reject:
> # the same message for all
> /^(.*)$/550 5.4.1 Delivery to this mailbox is not permitted for
you
>
> You see the point - if the sender address is somewhere in my Directory,
the LDAP result returns OK - Mail is accepted. Otherwise, it returns no result
and the second check is performed.
>
> # postmap -q kreutzer.christ...@yesthatsmymail.com
ldap:/etc/postfix/ldap-internal_user_lookup.cf
> OK
> # postmap -q kreutzer.christ...@example.com
ldap:/etc/postfix/ldap-internal_user_lookup.cf
> (no result)
> # postmap -q kreutzer.christ...@example.com
regexp:/etc/postfix/regexp-check_recipient_access-reject
> 550 5.4.1 Delivery to this mailbox is not permitted for you
>
> That always returns the 550 so the message will be rejected.
>
>
> But how is internal_user_lookup actually enforced? This is how I’ve got
it done:
> ldap-check_recipient_access.cf:
> # get recipient policy for a mail group
> query_filter =
(&(objectClass=mailGroup)(|(mail=%s)(mailAlternateAddress=%s)))
> result_attribute = mgrpBroadcasterPolicy
>
> main.cf again:
> smtpd_recipient_restrictions =
> reject_non_fqdn_recipient,
> reject_unknown_recipient_domain,
> reject_unlisted_recipient,
> [...]
> check_recipient_access
ldap:/etc/postfix/ldap-check_recipient_access.cf,
> reject_unverified_recipient
>
> So, for every incoming mail I make a call to that LDAP search above. If
the group has the attribute mgrpBroadcasterPolicy set to
Re: [SOGo] Alias for all mailboxes
Thanks for your help. Without LDAP, I can restrict senders? Exists any config file to this? Regards, Pedro Antunes From: Christoph Kreutzer Date: Friday, 25 January 2019 at 15:59 To: "users@sogo.nu" Cc: "pantu...@suroot.pt" Subject: Re: [SOGo] Alias for all mailboxes Hi, I implemented something like that in the backend, too. I’m using OpenLDAP. I have a script (PHP CLI script as part of a Zend Framework management frontend) that uses a config file containing some LDAP searches to automatically add/remove users to/from groups based on some attributes. That part is hard to share, but it shouldn’t be too hard implementing it with some Shell script if you are using the LDAP backend, too. Regarding restrictions: As MJ proposed, I handle that in Postfix. In main.cf, after smtpd_recipient_restrictions and smtpd_data_restrictions, there is a section: # allow setting action internal_user_lookup to disallow non-listed users as sender smtpd_restriction_classes = internal_user_lookup internal_user_lookup = check_sender_access ldap:/etc/postfix/ldap-internal_user_lookup.cf, # reject if not successful check_recipient_access regexp:/etc/postfix/regexp-check_recipient_access-reject, reject ldap-internal_user_lookup.cf looks like this: # resolve all mail addresses to OK (for checking of internal users) query_filter = (&(|(objectClass=mailGroup)(objectClass=mailRecipient)(objectClass=inetOrgPerson))(|(mail=%s)(mailAlternateAddress=%s)(mailForwardingAddress=%s)(mailRoutingAddress=%s))) result_attribute = mail result_format = OK (LDAP config is missing here) regexp-check_recipient_access-reject: # the same message for all /^(.*)$/550 5.4.1 Delivery to this mailbox is not permitted for you You see the point - if the sender address is somewhere in my Directory, the LDAP result returns OK - Mail is accepted. Otherwise, it returns no result and the second check is performed. # postmap -q kreutzer.christ...@yesthatsmymail.com<mailto:kreutzer.christ...@yesthatsmymail.com> ldap:/etc/postfix/ldap-internal_user_lookup.cf OK # postmap -q kreutzer.christ...@example.com<mailto:kreutzer.christ...@example.com> ldap:/etc/postfix/ldap-internal_user_lookup.cf (no result) # postmap -q kreutzer.christ...@example.com<mailto:kreutzer.christ...@example.com> regexp:/etc/postfix/regexp-check_recipient_access-reject 550 5.4.1 Delivery to this mailbox is not permitted for you That always returns the 550 so the message will be rejected. But how is internal_user_lookup actually enforced? This is how I’ve got it done: ldap-check_recipient_access.cf: # get recipient policy for a mail group query_filter = (&(objectClass=mailGroup)(|(mail=%s)(mailAlternateAddress=%s))) result_attribute = mgrpBroadcasterPolicy main.cf again: smtpd_recipient_restrictions = reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_unlisted_recipient, [...] check_recipient_access ldap:/etc/postfix/ldap-check_recipient_access.cf, reject_unverified_recipient So, for every incoming mail I make a call to that LDAP search above. If the group has the attribute mgrpBroadcasterPolicy set to internal_user_lookup (that’s the only value that will be set at the moment, otherwise it won’t exist), the defined smtpd_restriction_class is called. Which does what I described above. Hope that helps :-) The postfix docs are actually really good, but it’s complex to implement. Sometimes you just need a test setup. I got started there, I believe: http://www.postfix.org/LDAP_README.html Best regards, Christoph Am 25.01.2019 um 13:09 schrieb mj (li...@merit.unu.edu<mailto:li...@merit.unu.edu>) mailto:users@sogo.nu>>: Hi, On 1/25/19 3:37 AM, Pedro Antunes (pantu...@suroot.pt<mailto:pantu...@suroot.pt>) wrote: Hi, how i can create an distribution list (alias) that contain all mailboxes of one domain? its possible? It’s possible restrict who can send emails to one alias? We do this in our accounts backend (ldap/AD) by creating a group, give it an email address, and add users to it. Then in sogo.conf we add a specific user source, something like: type = ldap; CNFieldName = displayName; IDFieldName = cn; UIDFieldName = uid; baseDN = "CN=Groups,DC="; canAuthenticate = NO; bindDN = "cn=sogo-groups,cn=."; bindPassword = ; displayName = "Our groups"; listRequiresDot = NO; MailFieldNames =(mail, otherMailbox, proxyAddresses); id = ad-mail-groups; isAddressBook = YES; port = 389; scope = "SUB"; filter = "(objectClass=group)"; You also need to configure postfix to handle these same groups. About restrictions: I guess I'd look at the postfix side of things for restrictions. But I don't have an answer ready for you. MJ -- users@sogo.nu<mailto:users@sogo.nu> https://inverse.ca/sogo/lists -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] Alias for all mailboxes
Ok. One more question.. It's possible restrict one alias to one sender? Example: One alias only receive emails from an specific email address. Regards, Pedro Antunes On 25/01/2019, 12:57, "users-requ...@sogo.nu on behalf of Christian Mack" wrote: Hello Am 25.01.19 um 03:37 schrieb Pedro Antunes (pantu...@suroot.pt): > > how i can create an distribution list (alias) that contain all mailboxes of one domain? its possible? > It’s possible restrict who can send emails to one alias? > There is no function who does that in SOGo. You could create an distribution list, that consists of all possible addresses, but you would need to create that manually and keep it up to date manually. Perhaps you could generate and add it per script. Distribution lists are per address book. Whoever can read that address book can use that distribution list. Kind regards, Christian Mack -- Christian Mack Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung Basisdienste 78457 Konstanz +49 7531 88-4416 -- users@sogo.nu https://inverse.ca/sogo/lists
[SOGo] Alias for all mailboxes
Hi, how i can create an distribution list (alias) that contain all mailboxes of one domain? its possible? It’s possible restrict who can send emails to one alias? Regards, Pedro Antunes -- users@sogo.nu https://inverse.ca/sogo/lists
