On 3/1/2022 14:55, Alexander Stienstra wrote:
On 29-12-2021 11:13, Matus UHLAR - fantomas wrote:
- With smtpd_delay_reject=no, Postfix will log a DNSBL 'reject' in
smtpd_client_restrictions without any sender or recipient information.
That makes it difficult to answer questions about "missin
On 29-12-2021 11:13, Matus UHLAR - fantomas wrote:
- With smtpd_delay_reject=no, Postfix will log a DNSBL 'reject' in
smtpd_client_restrictions without any sender or recipient information.
That makes it difficult to answer questions about "missing" email.
And when SASL is used with delays
On 26/12/2021 17:51, Wietse Venema wrote:
Depends on what you mean with "accurate".
On 27.12.21 04:03, Lefteris Tsintjelis wrote:
I mean the locally maintained IP RBL. It is critical as this will be
doing most of the rejection.
- With smtpd_delay_reject=yes, Postfix logs the client, helo, s
On 26/12/2021 17:51, Wietse Venema wrote:
Depends on what you mean with "accurate".
I mean the locally maintained IP RBL. It is critical as this will be
doing most of the rejection.
- With smtpd_delay_reject=yes, Postfix logs the client, helo, sender,
and recipient.
With delays set to ye
Lefteris Tsintjelis:
> On 25/12/2021 17:55, Wietse Venema wrote:
> >
> > Use fail2ban etc. to lock out bad clients, whether they fail SASL
> > requirements, rate limit requirements, or other requirements.
>
> I used to do it with fail2ban for a while and still use it in some cases
> but I wanted
On 25/12/2021 17:55, Wietse Venema wrote:
Use fail2ban etc. to lock out bad clients, whether they fail SASL
requirements, rate limit requirements, or other requirements.
I used to do it with fail2ban for a while and still use it in some cases
but I wanted something in-house more permanent and
Lefteris Tsintjelis:
> On 25/12/2021 16:50, Wietse Venema wrote:
> > Wietse Venema:
> >
> > Rejects for SMTP syntax and SASL login are evaluated separate from
> > smtpd_{client, helo, etc}_restrictions.
>
> SASL was my main concern. Is it possible to evaluate and reveal that
> info last then aft
On 25/12/2021 16:50, Wietse Venema wrote:
Rejects for SMTP syntax and SASL login are evaluated separate from
smtpd_{client, helo, etc}_restrictions.
On 25.12.21 17:29, Lefteris Tsintjelis wrote:
SASL was my main concern. Is it possible to evaluate and reveal that
info last then after all other
On 25/12/2021 16:50, Wietse Venema wrote:
Wietse Venema:
Rejects for SMTP syntax and SASL login are evaluated separate from
smtpd_{client, helo, etc}_restrictions.
SASL was my main concern. Is it possible to evaluate and reveal that
info last then after all other rejects instead of first and
Wietse Venema:
> Lefteris Tsintjelis:
> > That is the impression I got. When delay rejects are on, in case of
> > multiple rejections, the final rejection reason appears to always be the
> > same even if a client rejection precedes a helo one for example(?). As
> > much as delay rejects have som
Lefteris Tsintjelis:
> That is the impression I got. When delay rejects are on, in case of
> multiple rejections, the final rejection reason appears to always be the
> same even if a client rejection precedes a helo one for example(?). As
> much as delay rejects have some benefits, this can be a
On 25/12/2021 14:45, Wietse Venema wrote:
Lefteris Tsintjelis:
I am trying to find more info about how delay rejects work and more
specifically how they are evaluated in case of multiple rejections when
delay rejects are on. Are all restrictions evaluated until RCPT TO in
case of multiple reject
Lefteris Tsintjelis:
> I am trying to find more info about how delay rejects work and more
> specifically how they are evaluated in case of multiple rejections when
> delay rejects are on. Are all restrictions evaluated until RCPT TO in
> case of multiple rejects? Do some restrictions have prior
13 matches
Mail list logo
