Changelog

[Ohm J]

What do you use instead of X-Forwarded-For for your own solution?

Yes I use " CF-Connecting-IP "

 

[smtalk]

Yes I use " CF-Connecting-IP "

So, it's still cloudflare, isn't it? It has both in its headers, so, you can just use X-Fowarded-For. What's the actual problem with it?

 

[Ohm J]

So, it's still cloudflare, isn't it? It has both in its headers, so, you can just use X-Fowarded-For. What's the actual problem with it?

Thanks

but I use CF-Connecting-IP for a long time and no problem at all that why I don't want to change my setting.
so I'll custom nginx-default.conf now.

 

[smtalk]

I see your point, I've moved the definition to nginx-cloudflare.conf.

 

[duntuk]

I see your point, I've moved the definition to nginx-cloudflare.conf.

Currently this breaks ngnix if you have cloudflare data inside /etc/nginx/nginx-includes.conf (not sure if this was explicitly customized, probably did this a while back)

If you have 'webserver=nginx_apache' in your custombuild/options.conf and run

./build update_versions; ./build rewrite_confs

This will create

/etc/nginx/nginx-cloudflare.conf

Which is almost identical to the existing file:

/etc/nginx/nginx-includes.conf

So we have 2 nearly identical files, however, the important difference here is that

/etc/nginx/nginx-includes.conf has:

real_ip_header CF-Connecting-IP;

While /etc/nginx/nginx-cloudflare.conf has:

real_ip_header X-Forwarded-For;

Having both of these will prevent ngnix from running...

The fix is to remove the cloudflare data from /etc/nginx/nginx-includes.conf (since as you noted, custombuild will be using /etc/nginx/nginx-includes.conf for cloudflare data).


Having both of these will prevent ngnix from running...

The fix is to remove the cloudflare data from /etc/nginx/nginx-includes.conf (since as you noted, custombuild will be using /etc/nginx/nginx-includes.conf for cloudflare data).

 

[factor]

I suggest you lock this and make it a sticky at the top.

 

[smtalk]

make it a sticky at the top

It's sticky already, isn't it?

 

[factor]

It's sticky already, isn't it?

yes it is sorry...

 

[gurek]

namespace_private.conf

mailbox spam {
special_use = \Junk # autocreate Spam, but don't autosubscribe
auto = create
}

I think it's not good solution. After login to Webmail on fresh email account i see 2 separate folders - Spam (spam) and Junk.
I suggest changing to:

mailbox Junk {
special_use = \Junk
auto = create
}

mailbox spam {
special_use = \Junk # autocreate Spam, but don't autosubscribe
auto = no
}

mailbox Spam {
special_use = \Junk
auto = no
}

 

[smtalk]

namespace_private.conf

I think it's not good solution. After login to Webmail on fresh email account i see 2 separate folders - Spam (spam) and Junk.
I suggest changing to:

Done in CB 2.0 rev. 2710, thank you!

 

[hatamiarash7]

Hi

One of the DNS providers recently changed its domain. It seems that the dnsproviders.json file should be updated

Provider: Arvancloud
Old API: napi.arvancloud.com
New API: napi.arvancloud.ir