Hi,
we are using two external MX servers in separate data centers. Both of them are running postfix since many years without problems.
Internally we do have a postfix server as final destination for all domains. On each MX we have defined a relay_transport with specific settings that rela
> On Jan 14, 2018, at 8:53 AM, lutz.niede...@gmx.net wrote:
>
> we are using two external MX servers in separate data centers. Both of them
> are running postfix since many years without problems.
>
> Internally we do have a postfix server as final destination for all domains.
> On each MX
lutz.niede...@gmx.net:
> Now we have two links to our internal server and we observed that
> it was the right decision to have those two links. Our internal
> server got two IP addresses (one per link) and is listening on
> both of them for connections from the MX servers. But we have no
> clue how
This weekend I added a service_name feature that is documented
as follows:
[begin quote]
service_name (read-only)
The master.cf service name of a Postfix daemon process. This
can be used to distinguish the logging from different services
that use the same program name.
Example ma
More information = more better :-)
This should give the fail2ban users/developers something to do.
Thanks,
Bill
On 1/14/2018 2:08 PM, Wietse Venema wrote:
This weekend I added a service_name feature that is documented
as follows:
[begin quote]
service_name (read-only)
The master.cf ser
On Friday, December 15, 2017 10:18:36 AM Wietse Venema wrote:
> Wietse Venema:
> > Scott Kitterman:
> > > Some Debian users aren't thrilled about a behavior change associated
> > > with the> >
> > > 20170611 Berkeley DB 2 DB_CONFIG fix. Apparently [1] something like:
> > > | root@playbox01:~# pos
On 2018-01-09 10:25 AM, Bill Cole wrote:
> A better place for this discussion would be the MailOps list, where a
> broader variety of mail admins *INCLUDING MS EMPLOYEES* take part, and
> this problem class has been discussed multiple times. See
> https://chilli.nosignal.org/cgi-bin/mailman/listinf
