On 20/06/2025 08:35, Wietse Venema via Postfix-users wrote:
This behavior is consistent with the postscreen code: the code that
logs the PREGREET event shows all available input, but does not
actually receive that input. The input is received, one line at a
time, by the postscreen dummy TLS engin
Nick Tait via Postfix-users:
> The following command illustrates this:
>
> $ ( echo -en "EHLO foo.local\r\nSTARTTLS\r\n" ; sleep 0 ; echo -en "QUIT\r\n"
> ) | nc mx.tait.net.nz 25
>
> Note the "sleep 0" (which does nothing). For me, running the command
> above terminates 50% of the time and han
Nick Tait via Postfix-users:
> $ ( echo -en "EHLO foo.local\r\nSTARTTLS\r\n" ; sleep 0 ; echo -en "QUIT\r\n"
> ) | nc mx.tait.net.nz 25
>
> Note the "sleep 0" (which does nothing). For me, running the command
> above terminates 50% of the time and hangs 50% of the time, but it all
> depends on
On 19/06/2025 02:53, Viktor Dukhovni via Postfix-users wrote:
Ditto for me:
$ (sleep 7; printf "EHLO foo.local\r\n"; sleep 2; printf "STARTTLS\r\n"; sleep 2;
printf "QUIT\r\n") | nc -C 127.0.0.1 24
220-amnesiac.example ESMTP Postfix
<...6s pause...>
220 amnesiac.example ESMT
On Wed, Jun 18, 2025 at 10:13:21AM -0400, Wietse Venema via Postfix-users wrote:
> > After setting "postscreen_tls_security_level = none", when I now send a
> > STARTTLS, I get a "502 5.5.1 Error: command not implemented", and then
> > /the SMTP session/ stops responding to any subsequent comman
On Wed, Jun 18, 2025 at 10:59:37PM +1200, Nick Tait via Postfix-users wrote:
> On 18/06/2025 22:33, Nick Tait via Postfix-users wrote:
> > Prior to making the configuration change, the response to the STARTTLS
> > was "454 4.7.0 TLS not available due to local problem", and the SMTP
> > session rem
Nick Tait via Postfix-users:
> On 18/06/2025 22:33, Nick Tait via Postfix-users wrote:
> > Prior to making the configuration change, the response to the STARTTLS
> > was "454 4.7.0 TLS not available due to local problem", and the SMTP
> > session remained operational, meaning if the client then s
On 2025-06-18 at 06:59:37 UTC-0400 (Wed, 18 Jun 2025 22:59:37 +1200)
Nick Tait via Postfix-users
is rumored to have said:
After setting "postscreen_tls_security_level = none", when I now send
a STARTTLS, I get a "502 5.5.1 Error: command not implemented",
That is precisely what I'd expect. No
On 18/06/2025 22:33, Nick Tait via Postfix-users wrote:
Prior to making the configuration change, the response to the STARTTLS
was "454 4.7.0 TLS not available due to local problem", and the SMTP
session remained operational, meaning if the client then sent another
command (e.g. QUIT), it was p
Nick Tait via Postfix-users skrev den 2025-06-18 12:33:
I hope this is the right forum for reporting a possible bug in
Postscreen? (Apologies if it isn't...)
postconf -Mf
would be helpfull here
___
Postfix-users mailing list -- postfix-users@postfix
On 2025-04-17 at 21:05:50 UTC-0400 (Thu, 17 Apr 2025 21:05:50 -0400)
Greg Klanderman via Postfix-users
is rumored to have said:
> Hi Bill
>
> Thanks for your reply..
Always happy to be of help.
[...]
> OK:
>
> % postconf | grep 'postscreen_.*_\(enable\|action\)'
> [output order rearranged]
> #
On 2025-04-17 at 23:19:06 UTC-0400 (Fri, 18 Apr 2025 05:19:06 +0200)
Benny Pedersen via Postfix-users
is rumored to have said:
> Greg Klanderman via Postfix-users skrev den 2025-04-18 03:05:
>
>>> Hard evidence of that would be helpful to show exactly what is logged and
>>> exactly what configura
Greg Klanderman via Postfix-users skrev den 2025-04-18 03:05:
Hard evidence of that would be helpful to show exactly what is logged
and
exactly what configuration postscreen is
using. https://www.postfix.org/DEBUG_README.html#mail gives details.
OK:
% postconf | grep 'postscreen_.*_\(enable\
Hi Bill
Thanks for your reply..
> On April 17, 2025 Bill Cole via Postfix-users
> wrote:
> On 2025-04-17 at 16:15:20 UTC-0400 (Thu, 17 Apr 2025 16:15:20 -0400)
> Greg Klanderman via Postfix-users
> is rumored to have said:
>> Hi,
>>
>> Am I correct that the after greeting tests ar
On 2025-04-17 at 16:15:20 UTC-0400 (Thu, 17 Apr 2025 16:15:20 -0400)
Greg Klanderman via Postfix-users
is rumored to have said:
Hi,
Am I correct that the after greeting tests are turned off by default?
Yes. You can trust the documentation. It may require careful reading and
logical deductio
Christophe Kalt via Postfix-users wrote in
:
|no crash over the past day, so something must indeed be off with the
|packages, disappointing, oh well. On the bright side, I no longer depend on
|these getting updated.
There were often problems with the -s they use. Especially before
they starte
no crash over the past day, so something must indeed be off with the
packages, disappointing, oh well. On the bright side, I no longer depend on
these getting updated.
Thanks Wietse & Viktor.
On Sun, Feb 4, 2024 at 10:21 PM Viktor Dukhovni via Postfix-users <
postfix-users@postfix.org> wrote:
>
On Sun, Feb 04, 2024 at 08:12:56PM -0500, Christophe Kalt via Postfix-users
wrote:
> These are the alpine packages themselves, but I'm not familiar with how
> they're built so I can't rule out a bad build. It's also possible that I
> didn't let the 3.8.3 version run long enough for it to crash as
These are the alpine packages themselves, but I'm not familiar with how
they're built so I can't rule out a bad build. It's also possible that I
didn't let the 3.8.3 version run long enough for it to crash as it happens
irregularly.
Anyways, spent some time building 3.8.5 from source and am now wa
On Sun, Feb 04, 2024 at 05:06:22PM -0500, Viktor Dukhovni via Postfix-users
wrote:
> > - 3.8.4 on alpine 3.19.0
> > - 3.8.5 on alpine 3.19.1
> >
> > but apparently not for 3.8.3 on alpine 3.18.3
>
> There's perhaps an issue in the OpenSSL or other library dependencies.
> For further info we'd n
On Sun, Feb 04, 2024 at 01:37:18PM -0500, Christophe Kalt via Postfix-users
wrote:
> /usr/libexec/postfix/postscreen pid 93 killed by signal 11
>
> These connections are from an SMTP probe that goes EHLO STARTTLS EHLO QUIT
>
> I've not run postscreen previously, so I cannot tell whether this is
Christophe Kalt via Postfix-users:
> Hi,
>
> I'm seeing regular postscreen segfaults on a test server with minimal
> traffic. The patterns I noticed from the logs is that it seems to happen
> when the server gets 2 ~simultaneous connections from the same host:
>
> 2024-02-04T14:33:31.876390 info
duluxoz via Postfix-users:
> Hi All,
>
> When using `postscreen_upstream_proxy_protocol = haproxy` is there
> anything "special" that needs to be specified to ensure the use of v2 of
> the haproxy protocol, or does postfix automatically detect which version
> of the haproxy protocol is in use?
Matus UHLAR - fantomas via Postfix-users:
> I see this was changed in 20120222
> Cleanup: when multiple DNSBLs block an SMTP client, the
> postscreen "reject" message now gives credit to the DNSBL
> with the largest weight, instead of the DNSBL that replies
> fir
On 16.10.23 10:33, Ivan Ionut via Postfix-users wrote:
And in my logs I have this example of blocked email(a non-spam one):
blocked using dnsbl-2.uceprotect.net
blocked using spam.dnsbl.anonmails.de
So only two of them, not four. And I want to know if there is a way to
log more informatio
Matus UHLAR - fantomas via Postfix-users:
> >> On 16.10.23 10:33, Ivan Ionut via Postfix-users wrote:
> >> > And in my logs I have this example of blocked email(a non-spam one):
> >> >
> >> >blocked using dnsbl-2.uceprotect.net
> >> >blocked using spam.dnsbl.anonmails.de
> >> >
> >> >So onl
On 16.10.23 10:33, Ivan Ionut via Postfix-users wrote:
> And in my logs I have this example of blocked email(a non-spam one):
>
>blocked using dnsbl-2.uceprotect.net
>blocked using spam.dnsbl.anonmails.de
>
>So only two of them, not four. And I want to know if there is a way to
>log more i
Matus UHLAR - fantomas via Postfix-users:
> On 16.10.23 10:33, Ivan Ionut via Postfix-users wrote:
> >postscreen_blacklist_action = drop
> >postscreen_dnsbl_threshold = 4
> >postscreen_dnsbl_action = enforce
> >postscreen_dnsbl_sites =
> >zen.spamhaus.org
> >b.barracudacentral.org
> >bl
Viktor Dukhovni via Postfix-users:
> On Mon, Oct 16, 2023 at 10:33:34AM +0300, Ivan Ionut via Postfix-users wrote:
>
> > Hi, I'm using postscreen dnsbl configuration to block some spam:
> >
> > postscreen_blacklist_action = drop
> > postscreen_dnsbl_threshold = 4
> > postscreen_dnsbl_action = enf
On Mon, Oct 16, 2023 at 10:33:34AM +0300, Ivan Ionut via Postfix-users wrote:
> Hi, I'm using postscreen dnsbl configuration to block some spam:
>
> postscreen_blacklist_action = drop
> postscreen_dnsbl_threshold = 4
> postscreen_dnsbl_action = enforce
> postscreen_dnsbl_sites =
> zen.spamhau
Ivan Ionut via Postfix-users skrev den 2023-10-16 09:33:
And in my logs I have this example of blocked email(a non-spam one):
blocked using dnsbl-2.uceprotect.net
blocked using spam.dnsbl.anonmails.de
if this 2 dnsbl lists ips in dnswl.org then its time to remove in
postscreen, imh
On 5/10/23 02:40, Peter via Postfix-users wrote:
On 8/05/23 00:27, Wietse Venema via Postfix-users wrote:
After multiple such connnections, postscreen could theoretically
decide that the client is unlikely to ever connect to the primary
MX, but by then the client will likely already have given u
On 8/05/23 00:27, Wietse Venema via Postfix-users wrote:
After multiple such connnections, postscreen could theoretically
decide that the client is unlikely to ever connect to the primary
MX, but by then the client will likely already have given up, and
postscreen has done no harm.
Postscreen do
Mihaly Zachar via Postfix-users:
> On Sun, 7 May 2023 at 13:59, Wietse Venema via Postfix-users <
> postfix-users@postfix.org> wrote:
>
> > > > Look at output from:
> > > >
> > > > (postconf -n; postconf -P) | grep soft_bounce
> > > >
> > >
> > > this gives an empty set...
> >
> > In that case I n
On Sun, 7 May 2023 at 14:28, Wietse Venema via Postfix-users <
postfix-users@postfix.org> wrote:
> Mihaly Zachar via Postfix-users:
> > On Sun, 7 May 2023 at 03:12, Mihaly Zachar wrote:
> >
> > > On Sun, 7 May 2023 at 03:05, Wietse Venema via Postfix-users <
> > > postfix-users@postfix.org> wrote
Mihaly Zachar via Postfix-users:
> On Sun, 7 May 2023 at 03:12, Mihaly Zachar wrote:
>
> > On Sun, 7 May 2023 at 03:05, Wietse Venema via Postfix-users <
> > postfix-users@postfix.org> wrote:
> >
> >>
> >> Look at output from:
> >>
> >> (postconf -n; postconf -P) | grep soft_bounce
> >>
> >
> > t
On Sun, 7 May 2023 at 13:59, Wietse Venema via Postfix-users <
postfix-users@postfix.org> wrote:
> > > Look at output from:
> > >
> > > (postconf -n; postconf -P) | grep soft_bounce
> > >
> >
> > this gives an empty set...
>
> In that case I need the COMPLETE postscreen logging for
> such connecti
On Sun, 7 May 2023 at 03:05, Wietse Venema via Postfix-users <
postfix-users@postfix.org> wrote:
Look at output from:
(postconf -n; postconf -P) | grep soft_bounce
On Sun, 7 May 2023 at 03:12, Mihaly Zachar wrote:
this gives an empty set...
On 07.05.23 12:44, Mihaly Zachar via Postfix-use
Mihaly Zachar:
> On Sun, 7 May 2023 at 03:05, Wietse Venema via Postfix-users <
> postfix-users@postfix.org> wrote:
>
> >
> > Look at output from:
> >
> > (postconf -n; postconf -P) | grep soft_bounce
> >
>
> this gives an empty set...
In that case I need the COMPLETE postscreen logging for
such
On Sun, 7 May 2023 at 03:12, Mihaly Zachar wrote:
> On Sun, 7 May 2023 at 03:05, Wietse Venema via Postfix-users <
> postfix-users@postfix.org> wrote:
>
>>
>> Look at output from:
>>
>> (postconf -n; postconf -P) | grep soft_bounce
>>
>
> this gives an empty set...
>
>
I think I have figured it o
On Sun, 7 May 2023 at 03:05, Wietse Venema via Postfix-users <
postfix-users@postfix.org> wrote:
>
> Look at output from:
>
> (postconf -n; postconf -P) | grep soft_bounce
>
this gives an empty set...
___
Postfix-users mailing list -- postfix-users@post
Wietse Venema via Postfix-users:
> Mihaly Zachar via Postfix-users:
> > Hi All,
> >
> > Here is my postscreen section of my config:
> >
> > # POSTSCREEN
> > postscreen_access_list = permit_mynetworks,
> > cidr:/etc/postfix/postscreen_access.cidr
> > postscreen_denylist_action = enforce
> > postsc
Mihaly Zachar via Postfix-users:
> Hi All,
>
> Here is my postscreen section of my config:
>
> # POSTSCREEN
> postscreen_access_list = permit_mynetworks,
> cidr:/etc/postfix/postscreen_access.cidr
> postscreen_denylist_action = enforce
> postscreen_greet_wait = 10s
> postscreen_allowlist_interfac
Alex via Postfix-users:
> Hi,
>
> I have postscreen implemented on postfix-3.7.3 on fedora37, and not sure I
> understand if it's working properly. Sometimes I see the postscreen/dnsblog
> combination ending with a simple DISCONNECT. In this case, it met the
> 8-point threshold to be rejected, but
Hello
For this parameter of postscreen:
postscreen_dnsbl_allowlist_threshold
The docs says:
1. Specify a negative value to enable this feature.
2. This feature is available in Postfix 3.6 and later.
Available as postscreen_dnsbl_whitelist_threshold in Postfix 2.11 - 3.5.
So my questions are:
Saturday, April 29, 2023, 5:40:19 PM, Ken Peng via Postfix-users wrote:
> Hello
> When I enabled postscreen, why even gmail's sender IP was greylisted?
> The log says:
> Apr 29 15:35:35 mxin postfix/postscreen[59408]: NOQUEUE: reject: RCPT from
> [209.85.160.53]:50219: 450 4.3.2 Service curre
On 2023-04-29 at 06:43:01 UTC-0400 (Sat, 29 Apr 2023 10:43:01 +)
Ken Peng via Postfix-users
is rumored to have said:
Nope. I found that if I enabled protocol test, every provider
including gmail/orange/vodafone sending messages to me will get
response code 450. After I disabled those proto
On Sat, 29 Apr 2023, Ken Peng via Postfix-users wrote:
Nope. I found that if I enabled protocol test, every provider including
gmail/orange/vodafone sending messages to me will get response code 450. After
I disabled those protocol test, everything goes fine.
So what's the correct way to deal
The code 450 is the "deep tests" doing their stuff.
When a a remote host calls for the first time, it sees a temp-fail (code 450).
When the host calls back, *USING THE SAME IP ADDRESS*, it will be passed
through to the mail server. The host has to
call twice to get through.
With gmail and
Nope. I found that if I enabled protocol test, every provider including
gmail/orange/vodafone sending messages to me will get response code 450. After
I disabled those protocol test, everything goes fine.
So what's the correct way to deal with postscreen protocol tests?
I mean the following stu
On Sat, 29 Apr 2023, Ken Peng via Postfix-users wrote:
Hello
When I enabled postscreen, why even gmail's sender IP was greylisted?
Did you expect or configure to deal with gmail differently?
The log says:
Apr 29 15:35:35 mxin postfix/postscreen[59408]: NOQUEUE: reject: RCPT from [209.85.16
Hello
When I enabled postscreen, why even gmail's sender IP was greylisted?
The log says:
Apr 29 15:35:35 mxin postfix/postscreen[59408]: NOQUEUE: reject: RCPT from
[209.85.160.53]:50219: 450 4.3.2 Service currently unavailable;
from=, to=, proto=ESMTP,
helo=
And this is my configuration fo
The postscreen feature for RBL checks allows us to use scoring!
My configuration is based on this one here:
https://gitlab.com/noumenia/aetolos/-/blob/master/modules/el8/postfix/maincf.tpl
Take a look at lines 100 to 132.
For example:
postscreen_dnsbl_action = enforce (reject email with 55
Saturday, April 29, 2023, 10:15:41 AM, Ken Peng via Postfix-users wrote:
> Sorry i have a question to postscreen.
> I saw many people use postscreen for RBL checks.
> But postfix itself have the RBL checks already:
> smtpd_recipient_restrictions =
>...
>reject_rbl_client zen.spamhaus.org
April 28, 2023 at 1:02 AM, "Phil Stracchino via Postfix-users"
wrote:
>
> On 4/27/23 04:47, Ralph Seichter via Postfix-users wrote:
>
> >
> > * Ken Peng via Postfix-users:
> > Using rspamd instead of postscreen?
> > I'm not quite sure what you mean by that.
> > If you suggest relying on r
On 4/27/23 04:47, Ralph Seichter via Postfix-users wrote:
* Ken Peng via Postfix-users:
Using rspamd instead of postscreen?
I'm not quite sure what you mean by that.
If you suggest relying on rspamd only, and forgo postscreen, I have to
disagree. In my experience, postscreen has proven highl
On 26.04.23 19:40, Ken Peng via Postfix-users wrote:
Using rspamd instead of postscreen?
no, using spamassassin or rspamd in addition to postscreen.
postscreen is great for eliminating bots, which is something other spam
filters only hardly detect.
It's also can machines listed in multiple
* Ken Peng via Postfix-users:
> Using rspamd instead of postscreen?
I'm not quite sure what you mean by that.
If you suggest relying on rspamd only, and forgo postscreen, I have to
disagree. In my experience, postscreen has proven highly useful in spam
prevention, in particular when DNSBL lookup
On Wed, 26 Apr 2023 at 18:47, Wietse Venema via Postfix-users <
postfix-users@postfix.org> wrote:
> Don't do it unless you aree willing to suffer some pain. The mere
> fast that a button exists does not impy that everyone must use it.
>
>
Dear Wietse,
Could you please give me some examples where
Using rspamd instead of postscreen?
>
> Dear All,
>
> I am building a new server where I would like to build the best spam filter
> possible :)
> I am checking postscreen these days. I am planning to turn on the "deep
> tests" as well, but it seems to be really scary to me :)
>
> In the doc th
On 2023-04-26 at 11:56:01 UTC-0400 (Wed, 26 Apr 2023 17:56:01 +0200)
Mihaly Zachar via Postfix-users
is rumored to have said:
Dear All,
I am building a new server where I would like to build the best spam
filter
possible :)
I am checking postscreen these days. I am planning to turn on the
"
Mihaly Zachar via Postfix-users:
> Dear All,
>
> I am building a new server where I would like to build the best spam filter
> possible :)
> I am checking postscreen these days. I am planning to turn on the "deep
> tests" as well, but it seems to be really scary to me :)
Don't do it unless you ar
Saturday, March 18, 2023, 4:48:02 PM, Phil Biggs via Postfix-users wrote:
> Saturday, March 18, 2023, 4:39:36 PM, Bill Cole via Postfix-users wrote:
>> On 2023-03-18 at 01:28:42 UTC-0400 (Sat, 18 Mar 2023 16:28:42 +1100)
>> Phil Biggs via Postfix-users
>> is rumored to have said:
>>> I have j
Saturday, March 18, 2023, 4:39:36 PM, Bill Cole via Postfix-users wrote:
> On 2023-03-18 at 01:28:42 UTC-0400 (Sat, 18 Mar 2023 16:28:42 +1100)
> Phil Biggs via Postfix-users
> is rumored to have said:
>> I have just finished building a new server for a friend and, after
>> installing
>> the p
On 2023-03-18 at 01:28:42 UTC-0400 (Sat, 18 Mar 2023 16:28:42 +1100)
Phil Biggs via Postfix-users
is rumored to have said:
I have just finished building a new server for a friend and, after
installing
the postfix FreeBSD package and restoring his main.cf, I see no
postscreen logs
at all.
I h
On 15/08/22 23:42, Wietse Venema wrote:
When a postscreen_dnsbl_sites pattern matches one or more DNSBL
query results, postscreen(8) adds that pattern's weight once
to the remote SMTP client's DNSBL score.
That is extremely clear and concise, I like it.
Peter
Peter:
> On 12/08/22 08:41, Wietse Venema wrote:
> > After some delay, I have verified that postscreen_dnsbl_sites works
> > as promised: it adds up the scores from all matching patterns.
> >
> > This verification required some infrastructure to test postscreen's
> > scoring code outside of postsc
On 12/08/22 08:41, Wietse Venema wrote:
After some delay, I have verified that postscreen_dnsbl_sites works
as promised: it adds up the scores from all matching patterns.
This verification required some infrastructure to test postscreen's
scoring code outside of postscreen. I have written a half
On 8/9/22 16:02, Dino Edwards wrote:
>
>> It's absolutely not forwarding. It's resolving recursively. I'm using
> unbound with pfsense and I'm suspecting there is something wrong with it.
>> When I point to MS DNS server or 9.9.9.9, it's resolving correctly.
>
> The issue has been resolved. Just
>It's absolutely not forwarding. It's resolving recursively. I'm using
unbound with pfsense and I'm suspecting there is something wrong with it.
>When I point to MS DNS server or 9.9.9.9, it's resolving correctly.
The issue has been resolved. Just in case someone finds the solution useful,
pfse
>In any case, the OP may well be using a local resolver, but they didn't say
whether it's resolving recursively or forwarding (e.g. to 8.8.8.8), and I'd
bet it's the latter.
It's absolutely not forwarding. It's resolving recursively. I'm using
unbound with pfsense and I'm suspecting there is som
On Tue, 9 Aug 2022, Bill Cole wrote:
On 2022-08-09 at 12:50:22 UTC-0400 (Tue, 9 Aug 2022 12:50:22 -0400)
Dino Edwards
is rumored to have said:
Let's do some concreate tests.
1) What is the output from:
dig +short 2.0.0.127.zen.spamhaus.org
Output is nothing
Your DNS resolver is brok
Dino Edwards:
>
>
> >Let's do some concreate tests.
>
> >1) What is the output from:
>
> > dig +short 2.0.0.127.zen.spamhaus.org
>
> Output is nothing
There should be a list of responses, as pointed out by Bill Cole
(or an error response if you are using a provider's resolver).
Wiet
On 2022-08-09 at 12:50:22 UTC-0400 (Tue, 9 Aug 2022 12:50:22 -0400)
Dino Edwards
is rumored to have said:
>> Let's do some concreate tests.
>
>> 1) What is the output from:
>
>> dig +short 2.0.0.127.zen.spamhaus.org
>
> Output is nothing
Your DNS resolver is broken. That's a test name which shou
Dino Edwards:
>
> << I suggest that you start with dig/nslookup and establish that you have
> properly working DNS, and that your ISP is not replacing all "not found"
> responses with the IP address of some "helpful" website.
>
> Using local DNS servers and not ISP servers. DNS is working as it s
I suggest that you start with dig/nslookup and establish that you
have properly working DNS, and that your ISP is not replacing all
"not found" responses with the IP address of some "helpful" website.
Wietse
Benny Pedersen:
> On 2022-02-01 21:52, Wietse Venema wrote:
>
> > You appear to believe that a dnsbl test starts AFTER a pregreet
> > test ends (succeeds or fails),
>
> it could ?
No, because legitimate clients would have to wait longer.
> > but that is not the case. Both tests
> > start at the
On 2022-02-01 21:52, Wietse Venema wrote:
You appear to believe that a dnsbl test starts AFTER a pregreet
test ends (succeeds or fails),
it could ?
but that is not the case. Both tests
start at the same time,
with is fine, but waste dnsbl test
so the query is alredy in progress when the
Benny Pedersen:
> On 2022-02-01 20:32, Wietse Venema wrote:
> >> i noted that postscreen do dnsbl test on pregreet connections
> > The dnsbl test is done when you enabled dnsbl tests and the result
> > from a previous dnsbl test has expired.
>
> the first dnsbl is wasted on first pregreet ?
>
> e
On 2022-02-01 20:32, Wietse Venema wrote:
i noted that postscreen do dnsbl test on pregreet connections
The dnsbl test is done when you enabled dnsbl tests and the result
from a previous dnsbl test has expired.
the first dnsbl is wasted on first pregreet ?
eq if connection is already pregree
Benny Pedersen:
>
> i noted that postscreen do dnsbl test on pregreet connections
>
> can this be solved ?
The dnsbl test is done when you enabled dnsbl tests and the result
from a previous dnsbl test has expired.
> also if connection ip is known in cache, why pregreet test again ?
The pregree
On 2021-12-22 at 03:53:24 UTC-0500 (Wed, 22 Dec 2021 09:53:24 +0100)
natan
is rumored to have said:
Postscreen would it be to aggressive or gmail send "non normal"
e-mails
See http://www.postfix.org/POSTSCREEN_README.html#after_220
Any postscreen tests which are done after the initial '220'
On 2021-05-29 at 10:22:23 UTC-0400 (Sat, 29 May 2021 10:22:23 -0400)
Timo Geusch
is rumored to have said:
The fix/workaround in my case is relatively easy as I mostly need to
update the configuration for my local DNS server. That said, I'm not
sure if postscreen should treat this kind of error
On 30/05/2021 12:47, Laura Smith wrote:
It is a fairly recent change, perhaps a year ago, that they return the .254 and
.255
codes rather than just ignoring the request, as a hint that you need to fix your
configuration.
Seems the change is dated 11/2/2021
(https://www.spamhaus.org/news/ar
> It is a fairly recent change, perhaps a year ago, that they return the .254
> and .255
> codes rather than just ignoring the request, as a hint that you need to fix
> your
> configuration.
>
>
Seems the change is dated 11/2/2021
(https://www.spamhaus.org/news/article/807/using-our-public-mi
On 5/29/21 2:19 PM, John Levine wrote:
According to Bastian Blank :
Already addressed it, however I figured it would be worth mentioning on here
as it seem to be a fairly recent change at SpamHaus's end.
No, it is not a recent change. SpamHaus rejects requests via done
public resolvers since a
According to Bastian Blank :
>> Already addressed it, however I figured it would be worth mentioning on here
>> as it seem to be a fairly recent change at SpamHaus's end.
>
>No, it is not a recent change. SpamHaus rejects requests via done
>public resolvers since a long time.
It is a fairly recen
On Sat, May 29, 2021 at 11:55:02AM -0400, Timo Geusch wrote:
> On 5/29/21 11:03 AM, Wietse Venema wrote:
> > Timo Geusch:
> > > Based on zen.spamhaus.org's documentation 127.255.255.25[245] are
> > > actually error codes and not indicators of allow/denylisting - in this
> > > case, their error is t
On Saturday, 29 May 2021 16:55, Timo Geusch wrote:
> On 5/29/21 11:03 AM, Wietse Venema wrote:
>
> > Timo Geusch:
> >
> > > Based on zen.spamhaus.org's documentation 127.255.255.25[245] are
> > > actually error codes and not indicators of allow/denylisting - in this
> > > case, their error is tha
On 5/29/21 11:40 AM, Phil Stracchino wrote:
On 5/29/21 10:22 AM, Timo Geusch wrote:
Based on zen.spamhaus.org's documentation 127.255.255.25[245] are
actually error codes and not indicators of allow/denylisting - in this
case, their error is that I was querying via a public resolver, see link
On 5/29/21 11:03 AM, Wietse Venema wrote:
Timo Geusch:
Based on zen.spamhaus.org's documentation 127.255.255.25[245] are
actually error codes and not indicators of allow/denylisting - in this
case, their error is that I was querying via a public resolver, see link
here: https://www.spamhaus.org
On 5/29/21 10:22 AM, Timo Geusch wrote:
> Based on zen.spamhaus.org's documentation 127.255.255.25[245] are
> actually error codes and not indicators of allow/denylisting - in this
> case, their error is that I was querying via a public resolver, see link
> here: https://www.spamhaus.org/faq/sec
Timo Geusch:
> Based on zen.spamhaus.org's documentation 127.255.255.25[245] are
> actually error codes and not indicators of allow/denylisting - in this
> case, their error is that I was querying via a public resolver, see link
> here: https://www.spamhaus.org/faq/section/DNSBL%20Usage#200
So
Maurizio Caloro:
> Hello
>
> Please iam play now one day with dovecot sieve to filter mails, so that Spam
> mail will forwarded to other folders.
>
> This arnt running now, and asking doevcot, no answer are reached out now.
>
> smtp inet n - y - 1 postscreen
> -o
On 9/02/21 2:48 am, maciejm wrote:
Hello
What I must set to enable "postscreen" ?
I ask because I must use "-o
receive_override_options=no_address_mappings" in master.cf
smtp inet n - y - 100 smtpd
-o receive_override_options=no_address_mappings
...
prox
On 08.02.21 14:48, maciejm wrote:
What I must set to enable "postscreen" ?
On 08.02.2021 14:50, Matus UHLAR - fantomas wrote:
it's described on:
http://www.postfix.org/POSTSCREEN_README.html
I ask because I must use "-o
receive_override_options=no_address_mappings" in master.cf
no, you
On 08.02.2021 14:50, Matus UHLAR - fantomas wrote:
> On 08.02.21 14:48, maciejm wrote:
>> What I must set to enable "postscreen" ?
>
> it's described on:
> http://www.postfix.org/POSTSCREEN_README.html
>
>> I ask because I must use "-o
>> receive_override_options=no_address_mappings" in master.cf
>
On 08.02.21 14:48, maciejm wrote:
What I must set to enable "postscreen" ?
it's described on:
http://www.postfix.org/POSTSCREEN_README.html
I ask because I must use "-o
receive_override_options=no_address_mappings" in master.cf
no, you usually don't have to do this, it should usually be use
On 06/10/2020 00:05, Wietse Venema wrote:
> John Fawcett:
>> Actually to be more precise: is it guaranteed to return not null and
>> with all the function pointers in the returned dict struct also not
>> null. I'm adding this because I think it does always return something
>> not null, but I'm not
John Fawcett:
> Actually to be more precise: is it guaranteed to return not null and
> with all the function pointers in the returned dict struct also not
> null. I'm adding this because I think it does always return something
> not null, but I'm not sure that the function pointers are always not
>
1 - 100 of 946 matches
Mail list logo
