>
> Michael Orlitzky:
If you want something more generic than what's already in postfix, the
> next level up is probably iptables.
I was looking for something with host lookup capability and tcp wrappers
was exactly the thing. There were allow/deny.hosts files present in the
system, which made m
Viktor Dukhovni:
> > On Feb 15, 2021, at 9:57 PM, Wietse Venema wrote:
> >
> > I just verified that TLS works when running "sendmail -bs" as user
> > 'postfix' from inetd. But I agree that this mode of operation is
> > suitable only for extraordinary cases.
>
> How was the SMTP server able to lo
Michael Orlitzky wrote:
> Eugene Podshivalov wrote:
> > Generic approach to system administration and access control
> > reconfiguration at runtime (without service reload).
>
> If you want something more generic than what's already in postfix, the
> next level up is probably iptables.
+1. I agr
> On Feb 15, 2021, at 9:57 PM, Wietse Venema wrote:
>
> I just verified that TLS works when running "sendmail -bs" as user
> 'postfix' from inetd. But I agree that this mode of operation is
> suitable only for extraordinary cases.
How was the SMTP server able to load the certificate chain? The
On Tue, 2021-02-16 at 01:51 +0300, Eugene Podshivalov wrote:
> Generic approach to system administration and access control
> reconfiguration at runtime (without service reload).
>
If you want something more generic than what's already in postfix, the
next level up is probably iptables.
Viktor Dukhovni:
> > On Feb 15, 2021, at 9:03 PM, Wietse Venema wrote:
> >
> >> Is it by chance possible that tcp wrappers will be supported in future at
> >> least as an optionally compiled feature?
> >
> > If you must, you can run "/usr/sbin/sendmail -bs" as user "postfix"
> > under TCP Wrappe
> On Feb 15, 2021, at 8:51 PM, Eugene Podshivalov wrote:
>
> Generic approach to system administration and access control reconfiguration
> at runtime (without service reload).
If your max_idle and max_use are not too high, Postfix does
not need to be "reloaded" to detect changes in main.cf.
Ea
> On Feb 15, 2021, at 9:03 PM, Wietse Venema wrote:
>
>> Is it by chance possible that tcp wrappers will be supported in future at
>> least as an optionally compiled feature?
>
> If you must, you can run "/usr/sbin/sendmail -bs" as user "postfix"
> under TCP Wrappers from inetd.
Please don't re
Eugene Podshivalov:
> Is it by chance possible that tcp wrappers will be supported in future at
> least as an optionally compiled feature?
If you must, you can run "/usr/sbin/sendmail -bs" as user "postfix"
under TCP Wrappers from inetd.
I prefer to spend my limited development cycles on things t
Generic approach to system administration and access control
reconfiguration at runtime (without service reload).
вт, 16 февр. 2021 г. в 01:24, Bob Proulx :
> Eugene Podshivalov wrote:
> > Is it by chance possible that tcp wrappers will be supported in future at
> > least as an optionally compile
Eugene Podshivalov wrote:
> Is it by chance possible that tcp wrappers will be supported in future at
> least as an optionally compiled feature?
One can't say something will never happen. But why would it be
needed?
As others have said Postfix already supports all of the same feature
set but in
Is it by chance possible that tcp wrappers will be supported in future at
least as an optionally compiled feature?
пн, 8 февр. 2021 г. в 23:00, Eugene Podshivalov :
> Thanks, Noel! Your comments are helpful indeed.
>
> пн, 8 февр. 2021 г. в 22:37, Noel Jones :
>
>>
>> On 2/8/2021 11:45 AM, Eugene
Thanks, Noel! Your comments are helpful indeed.
пн, 8 февр. 2021 г. в 22:37, Noel Jones :
>
> On 2/8/2021 11:45 AM, Eugene Podshivalov wrote:
> > Thanks for the explanation, Wietse.
> >
> > Probably the issue is just with the logging levels.
> > My current configuration already has
> >
> > sm
On 2/8/2021 11:45 AM, Eugene Podshivalov wrote:
Thanks for the explanation, Wietse.
Probably the issue is just with the logging levels.
My current configuration already has
smtpd_client_restrictions=reject_unknown_client_hostname
and the log file is flooded with message like this
co
Eugene Podshivalov:
> Thanks for the explanation, Wietse.
>
> Probably the issue is just with the logging levels.
> My current configuration already has
>
> > smtpd_client_restrictions=reject_unknown_client_hostname
>
> and the log file is flooded with message like this
>
> > connect from unkno
Thanks for the explanation, Wietse.
Probably the issue is just with the logging levels.
My current configuration already has
> smtpd_client_restrictions=reject_unknown_client_hostname
and the log file is flooded with message like this
> connect from unknown[ x.x.x.x]
> NOQUEUE: reject: CONNECT
Eugene Podshivalov:
> Have read through the postscreen documentation closely and got it setup and
> running already, but could not find the three major possibilities provided
> by the tcp wrappers:
> 1. block by hostname
> 2. block clients with unknown hostname
> 3. block clients with invalid addre
Do you mean with the help of reject_unknown_client_hostname
and check_sender_access params?
пн, 8 февр. 2021 г. в 16:37, Matus UHLAR - fantomas :
> On 08.02.21 16:27, Eugene Podshivalov wrote:
> >Have read through the postscreen documentation closely and got it setup
> and
> >running already, but
On 08.02.21 16:27, Eugene Podshivalov wrote:
Have read through the postscreen documentation closely and got it setup and
running already, but could not find the three major possibilities provided
by the tcp wrappers:
1. block by hostname
2. block clients with unknown hostname
3. block clients wit
Have read through the postscreen documentation closely and got it setup and
running already, but could not find the three major possibilities provided
by the tcp wrappers:
1. block by hostname
2. block clients with unknown hostname
3. block clients with invalid address<->name mapping
The last two
I'm new to postscreen and it's what I was looking for. Thanks a lot for the
answers!
пн, 8 февр. 2021 г. в 11:22, Dominic Raferd :
> On 08/02/2021 08:04, Eugene Podshivalov wrote:
> > There are a bunch of spiders and spammers nowadays which are knocking
> > the service every hour or so every day.
On 08/02/2021 08:04, Eugene Podshivalov wrote:
There are a bunch of spiders and spammers nowadays which are knocking
the service every hour or so every day. Postfix has a really powerful
access control system to protect itself but it becomes a bit hard to
read the log file flooded by the connec
There are a bunch of spiders and spammers nowadays which are knocking the
service every hour or so every day. Postfix has a really powerful access
control system to protect itself but it becomes a bit hard to read the log
file flooded by the connection attempts. I'm currently trying to filter
those
On Mon, Feb 08, 2021 at 02:17:46AM +0300, Eugene Podshivalov wrote:
> Are there any reasons not to have Postfix compiled with TCP wrappers?
Because that would likely be entirely redundant. Postfix already has
IP-based access controls (local tables, RBL lookups, postscreen(8), ...
and can also lo
24 matches
Mail list logo
