[pfx] Re: Question to reject_rbl_client zen.spamhaus.org
On 10/04/23 16:52, tom--- via Postfix-users wrote: The default_action here actually defines what action postfix will take if the policyd errors out (e.g. not running). By default this is "451 4.3.5 Server configuration problem" which results in a deferral, so it would not cause the message to pass by default but rather to defer. That said, there is nothing wrong with this setting if that's what you actually want to happen if the policyd isn't working. I was thinking the python version configuration for policyd-spf maybe have bugs. If that's the case this won't solve it. If policyd-spf was returning something invalid that caused postfix to use this setting then as I stated before the default would be a 451 deferral, not a 2xx or OK response as you indicated is happening. The fact that you haven't been getting lots of mail deferred shows that this isn't the case. Peter ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Question to reject_rbl_client zen.spamhaus.org
On April 10, 2023 4:52:04 AM UTC, tom--- via Postfix-users
wrote:
>On 2023-04-10 12:39, Peter via Postfix-users wrote:
>> On 10/04/23 14:21, tom--- via Postfix-users wrote:
>>> I have resolved the issue by:
>>>
>>> 1. install unbound as dns resolver locally
>>
>> This is good.
>>
>>> 2. change this statement:
>>> check_policy_service unix:private/policyd-spf,
>>> to this one:
>>> check_policy_service { unix:private/policyd-spf, default_action=DUNNO },
>>
>> The default_action here actually defines what action postfix will take if
>> the policyd errors out (e.g. not running). By default this is "451 4.3.5
>> Server configuration problem" which results in a deferral, so it would not
>> cause the message to pass by default but rather to defer. That said, there
>> is nothing wrong with this setting if that's what you actually want to
>> happen if the policyd isn't working.
>>
>
>I was thinking the python version configuration for policyd-spf maybe have
>bugs.
>from the doc:
>https://manpages.debian.org/testing/postfix-policyd-spf-python/policyd-spf.conf.5.en.html
>
>which says:
>
>HELO/EHLO PASS RESTRICTION
>HELO Pass Restriction allows integration with other Postfix access controls by
>provding a user supplied name of a postfix access restriction to be applied to
>a message when the HELO checking result is Pass. The indicated restriction
>must be an action as defined for a Postfix SMTP server access table access(5)
>and explained in the Postfix RESTRICTION CLASS README. The
>README.per_user_whitelisting file provided with this distribution provides
>examples. Note: A helo pass restriction will be the returned result even if
>the mail from result would cause the message to be rejected.
>
>Example:
>
>HELO_pass_restriction = helo_passed_spf
>
>Default:
>
>None
>
>
>I think the Default should be set to "DUNNO" here. but it's None. so a system
>argument
> like mine is required.
>
>Am I right?
>Thanks.
No. If you set HELO_pass_restriction, you can override the normal responses.
If it's None (the default) the normally appropriate response will be returned
(e. g. DUNNO). If you haven't set a value for the option, you don't need to
worry about it, it does nothing.
Scott K
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Question to reject_rbl_client zen.spamhaus.org
On 2023-04-10 12:39, Peter via Postfix-users wrote:
On 10/04/23 14:21, tom--- via Postfix-users wrote:
I have resolved the issue by:
1. install unbound as dns resolver locally
This is good.
2. change this statement:
check_policy_service unix:private/policyd-spf,
to this one:
check_policy_service { unix:private/policyd-spf,
default_action=DUNNO },
The default_action here actually defines what action postfix will take
if the policyd errors out (e.g. not running). By default this is "451
4.3.5 Server configuration problem" which results in a deferral, so it
would not cause the message to pass by default but rather to defer.
That said, there is nothing wrong with this setting if that's what you
actually want to happen if the policyd isn't working.
I was thinking the python version configuration for policyd-spf maybe
have bugs.
from the doc:
https://manpages.debian.org/testing/postfix-policyd-spf-python/policyd-spf.conf.5.en.html
which says:
HELO/EHLO PASS RESTRICTION
HELO Pass Restriction allows integration with other Postfix access
controls by provding a user supplied name of a postfix access
restriction to be applied to a message when the HELO checking result is
Pass. The indicated restriction must be an action as defined for a
Postfix SMTP server access table access(5) and explained in the Postfix
RESTRICTION CLASS README. The README.per_user_whitelisting file provided
with this distribution provides examples. Note: A helo pass restriction
will be the returned result even if the mail from result would cause the
message to be rejected.
Example:
HELO_pass_restriction = helo_passed_spf
Default:
None
I think the Default should be set to "DUNNO" here. but it's None. so a
system argument
like mine is required.
Am I right?
Thanks.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Question to reject_rbl_client zen.spamhaus.org
On 10/04/23 14:21, tom--- via Postfix-users wrote:
I have resolved the issue by:
1. install unbound as dns resolver locally
This is good.
2. change this statement:
check_policy_service unix:private/policyd-spf,
to this one:
check_policy_service { unix:private/policyd-spf,
default_action=DUNNO },
The default_action here actually defines what action postfix will take
if the policyd errors out (e.g. not running). By default this is "451
4.3.5 Server configuration problem" which results in a deferral, so it
would not cause the message to pass by default but rather to defer.
That said, there is nothing wrong with this setting if that's what you
actually want to happen if the policyd isn't working.
now it works perfectly.
Excellent, glad you were able to work it out.
Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: REPOST: Envelope sender is not modified correctly
>If you were fully equipped to know what's relevant Again, I'm sorry if anything I wrote was hurtful or otherwise unpleasant: not at all what I wanted to express. I have no complaints at all, for any reason. I used Postfix for so many years now: I'm so totally grateful for your effort. Why this conversation went from technical terms to insults, I don't understand: it is unexpected for me. If I made a mistake, I'm sorry. I'm just happy I came for help, received some, and fixed the problem. Le dim. 9 avr. 2023, à 22 h 34, Viktor Dukhovni via Postfix-users < postfix-users@postfix.org> a écrit : > On Sun, Apr 09, 2023 at 10:29:46PM -0400, François wrote: > > > I did post the relevant parts (I believe) of main.cf: > > If you were fully equipped to know what's relevant, you'd not need to > look for help here. When you do seek help here, you need to be willing > to let others judge what is relevant. > > -- > Viktor. > ___ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org > ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: DNS resolvers difference for RBL checks
On Mon, Apr 10, 2023 at 10:22:24AM +0800, tom--- via Postfix-users wrote: > > My comiserations... > > Do you mean systemd-resolve is a bad choice for local resolver? Wow, you read my mind! :-) The only use-case I can think of for systemd-resolved is on mobile devices, or home networks, where autoconfiguration or support for mdns might be useful. On a server, I'd like to recommend a real resolver. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: REPOST: Envelope sender is not modified correctly
On Sun, Apr 09, 2023 at 10:29:46PM -0400, François wrote: > I did post the relevant parts (I believe) of main.cf: If you were fully equipped to know what's relevant, you'd not need to look for help here. When you do seek help here, you need to be willing to let others judge what is relevant. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: REPOST: Envelope sender is not modified correctly
Fran?ois via Postfix-users: > I'm sorry if any part of my request seemed disagreeable: not my intention. > > I did post the relevant parts (I believe) of main.cf: > > canonical_maps = regexp:/etc/postfix/canonical > canonical_classes = envelope_sender You failed to post "postconf -n" output as requested. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: REPOST: Envelope sender is not modified correctly
I'm sorry if any part of my request seemed disagreeable: not my intention. I did post the relevant parts (I believe) of main.cf: canonical_maps = regexp:/etc/postfix/canonical canonical_classes = envelope_sender I don't see a mistake in those lines (this affirmation could be in itself a mistake, I agree :-) I think the initial regex are better, in this case, if they are sloppy(ish). I do not know if the domain finishes or not with the TLD (whitespace is frequent: I just need to find the domain somewhere in the string). Again, sorry for any inconvenience. Le dim. 9 avr. 2023, à 22 h 08, Viktor Dukhovni via Postfix-users < postfix-users@postfix.org> a écrit : > On Sun, Apr 09, 2023 at 08:08:04PM -0400, François via Postfix-users wrote: > > > The regexp:/etc/postfix/canonical just did not want to map reliably a > > domain name to a certain Return-Path, even though I tested successfully > all > > regular expressions with (for example): > > > > postmap -q "info[at]ghi.com" regexp:/etc/postfix/canonical > > > > when used to test the file listing the following: > > > > /@abc\.com/ address_1[at]whereto.com > > /@def\.com/ address_1[at]whereto.com > > /@ghi\.com/ address_2[at]whereto.com > > /@jkl\.com/ address_1[at]whereto.com > > You had a mistake in "main.cf", which you never posted: > > https://www.postfix.org/DEBUG_README.html#mail > > > Those are pretty vanilla regular expressions matching all email addresses > > of the listed domains. > > They are (typically) sloppy. The correct form is: > > /@abc\.com$/ addres...@whereto.com > /@def\.com$/ addres...@whereto.com > /@jkl\.com$/ addres...@whereto.com > /@ghi\.com$/ addres...@whereto.com > > Also, in case it is applicable, keep in mind that canonical mapping is > recursive, and will apply to the RHS forms, should those also match. > > > Why "postmap -q" and the actual sending of a message from these > > domains behave differently I just don't understand. > > No telepaths on this list: > > https://www.postfix.org/DEBUG_README.html#mail > > -- > Viktor. > ___ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org > ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: DNS resolvers difference for RBL checks
On 2023-04-10 09:30, Viktor Dukhovni via Postfix-users wrote: On Mon, Apr 10, 2023 at 09:14:19AM +0800, tom--- via Postfix-users wrote: I have two debian boxes, one is running unbound for dns resolver, Congratulations on a sound choice. another is running systemd-resolve. My comiserations... Do you mean systemd-resolve is a bad choice for local resolver? Thanks. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Question to reject_rbl_client zen.spamhaus.org
On 2023-04-09 10:02, t...@myposts.ovh wrote:
I have this setting in main.cf:
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
check_policy_service unix:private/policyd-spf,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client bl.spamcop.net
When I sent message from a Spamhaus Zen listed IP (this IP not in my
whitelist), the message still came into system.
it seemsreject_rbl_client zen.spamhaus.org has no effect.
Where should i debug it?
Hello
I have resolved the issue by:
1. install unbound as dns resolver locally
2. change this statement:
check_policy_service unix:private/policyd-spf,
to this one:
check_policy_service { unix:private/policyd-spf, default_action=DUNNO
},
3. systemctl reload postfix dovecot rspamd etc
now it works perfectly.
Thank you for all your support.
regards
Tom Reed
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: REPOST: Envelope sender is not modified correctly
On Sun, Apr 09, 2023 at 08:08:04PM -0400, François via Postfix-users wrote: > The regexp:/etc/postfix/canonical just did not want to map reliably a > domain name to a certain Return-Path, even though I tested successfully all > regular expressions with (for example): > > postmap -q "info[at]ghi.com" regexp:/etc/postfix/canonical > > when used to test the file listing the following: > > /@abc\.com/ address_1[at]whereto.com > /@def\.com/ address_1[at]whereto.com > /@ghi\.com/ address_2[at]whereto.com > /@jkl\.com/ address_1[at]whereto.com You had a mistake in "main.cf", which you never posted: https://www.postfix.org/DEBUG_README.html#mail > Those are pretty vanilla regular expressions matching all email addresses > of the listed domains. They are (typically) sloppy. The correct form is: /@abc\.com$/ addres...@whereto.com /@def\.com$/ addres...@whereto.com /@jkl\.com$/ addres...@whereto.com /@ghi\.com$/ addres...@whereto.com Also, in case it is applicable, keep in mind that canonical mapping is recursive, and will apply to the RHS forms, should those also match. > Why "postmap -q" and the actual sending of a message from these > domains behave differently I just don't understand. No telepaths on this list: https://www.postfix.org/DEBUG_README.html#mail -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: DNS resolvers difference for RBL checks
On Mon, Apr 10, 2023 at 09:14:19AM +0800, tom--- via Postfix-users wrote: > I have two debian boxes, one is running unbound for dns resolver, Congratulations on a sound choice. > another is running systemd-resolve. My comiserations... -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] DNS resolvers difference for RBL checks
Hello I have two debian boxes, one is running unbound for dns resolver, another is running systemd-resolve. As you see the first, udp0 0 127.0.0.1:530.0.0.0:* 290152/unbound The second, udp0 0 127.0.0.53:53 0.0.0.0:* 268/systemd-resolve Checking for RBL on first node is successful: $ dig 17.39.33.194.zen.spamhaus.org +short 127.0.0.3 But second is not: $ dig 17.39.33.194.zen.spamhaus.org ; <<>> DiG 9.16.1-Ubuntu <<>> 17.39.33.194.zen.spamhaus.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 24980 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;17.39.33.194.zen.spamhaus.org. IN A ;; Query time: 35 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Mon Apr 10 09:12:15 HKT 2023 ;; MSG SIZE rcvd: 58 Can you tell me why? Thank you. Tom ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: REPOST: Envelope sender is not modified correctly
I tried your inline solution: it worked as expected. I saw the mapping happen between postfix/pickup and postfix/qmgr I finally could get the canonical mapping to change the Return-Path (and the Return-Path only: the From and Reply-To must be left as they are). The only way I found: list ALL sender email addresses in hash:/etc/postfix/canonical. The regexp:/etc/postfix/canonical just did not want to map reliably a domain name to a certain Return-Path, even though I tested successfully all regular expressions with (for example): postmap -q "info[at]ghi.com" regexp:/etc/postfix/canonical when used to test the file listing the following: /@abc\.com/ address_1[at]whereto.com /@def\.com/ address_1[at]whereto.com /@ghi\.com/ address_2[at]whereto.com /@jkl\.com/ address_1[at]whereto.com Those are pretty vanilla regular expressions matching all email addresses of the listed domains. Why "postmap -q" and the actual sending of a message from these domains behave differently I just don't understand. Thank you very much for your help! I appreciate it even more so because this is supposed to be a long weekend (Happy Easter). ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Question to reject_rbl_client zen.spamhaus.org
On 9/04/23 23:02, Peter via Postfix-users wrote:
On 9/04/23 21:23, tom--- via Postfix-users wrote:
I am using the policyd-spf by default configuration (never changed a
line), and this is the doc:
https://manpages.debian.org/testing/postfix-policyd-spf-python/policyd-spf.conf.5.en.html
But the doc says noting about "OK" and "DUNNO". so how?
Not sure, but since you identified that you are using Google DNS chasing
this is likely going to be a red herring, it probably already returns
DUNNO anyways.
Pretty sure it's not going to be policyd:
peter@linux:~/postfix/postfix-policyd-spf-perl$ grep DUNNO
postfix-policyd-spf-perl
my $DEFAULT_RESPONSE = 'DUNNO';
# Pick whatever response is not 'DUNNO'
if ($response and $response !~ /^DUNNO/i) {
return 'DUNNO' if ( ( ! defined( $domain ) ) or ( $domain eq '' ) );
return 'DUNNO';
return 'DUNNO';
return 'DUNNO';
peter@linux:~/postfix/postfix-policyd-spf-perl$ grep OK
postfix-policyd-spf-perl
Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: REPOST: Envelope sender is not modified correctly
Fran?ois via Postfix-users:
> >Envelope from? Header from?
>
> I just don't know. I tried to find the info but could not. My best guess:
> header from.
It sets both.
With a very simple canonical map
main.cf:
canonical_maps = inline:{{f...@porcupine.org = b...@porcupine.org}}
Command:
echo test|mail -r f...@porcupine.org wietse
Logging shows f...@porcupine.org before canonical mapping, and
b...@porcupine.org after canonical mapping.
Apr 9 16:32:06 wzv postfix/pickup[263275]: 9E0E0A01AA: uid=0
from=
...
Apr 9 16:32:06 wzv postfix/qmgr[263274]: 9E0E0A01AA:
from=, size=405, nrcpt=1 (queue active)
I used the inline map to keep the example as simple as possible. It is very
easy to make mistakes with regular expressions (by forgetting ^, \, or $).
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: REPOST: Envelope sender is not modified correctly
>Envelope from? Header from? I just don't know. I tried to find the info but could not. My best guess: header from. I'm starting to think what I asked is not possible (at least using canonical mapping): Return-Path: whatever or nothing From: whatever[at]ghi.com Changed to: Return-Path: address_2[at]whereto.com From: whatever[at]ghi.com I'm trying to ensure any and all emails sent will have a specific Return-Path, which Return-Path is specified according to the sender's From header address. Can this be done? ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: REPOST: Envelope sender is not modified correctly
Fran?ois via Postfix-users: > mail program links to mailx. mailx man page says: > > -r address > Sets the From address. Overrides any from variable specified Envelope from? Header from? Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: REPOST: Envelope sender is not modified correctly
>How do you specify the test message envelope sender addresses? I just use: date | mail -s "$(date)" -r 'whatever[at]ghi.com' someone[at]somedomain.com mail program links to mailx. mailx man page says: -r address Sets the From address. Overrides any from variable specified in environment or startup files. Tilde escapes are disabled. The -r address options are passed to the mail transfer agent unless SMTP is used. This option exists for compatibility only; it is recommended to set the from variable directly instead. I guess I misunderstood envelope sender address canonical mapping. I thought any email with a from header would have its envelope sender (it's the return-path I'm targeting) changed to an arbitrary value. How can I accomplish that? Return-Path: whatever or nothing From: whatever[at]ghi.com Changed to: Return-Path: address_2[at]whereto.com From: whatever[at]ghi.com ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: REPOST: Envelope sender is not modified correctly
How do you specify the test message envelope sender addresses? You can't put them in a message header (From:, Return-Path:, etc.). Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] REPOST: Envelope sender is not modified correctly
REPOST Sorry, all email addresses in my last post were garbled Please ignore my last post Hi, To channel bounce reports to multiple sender domains I control to specific addresses for analysis I used: In main.cf: canonical_maps = regexp:/etc/postfix/canonical canonical_classes = envelope_sender In canonical: /@abc\.com/ address_1[at]whereto.com /@def\.com/ address_1[at]whereto.com /@ghi\.com/ address_2[at]whereto.com /@jkl\.com/ address_1[at]whereto.com I checked the regular expressions using (for instance): postmap -q "info[at]ghi.com" regexp:/etc/postfix/canonical postmap -q "info[at]abc.com" regexp:/etc/postfix/canonical Got (in order): address_2[at]whereto.com address_1[at]whereto.com I then postmapped /etc/postfix/canonical and restarted the server. For some reason, the envelope sender is not modified properly when sending mail. A mail sent from "whatever[at]ghi.com" would leave this trace in maillog: Apr 9 10:44:52 acer postfix/qmgr[2299936]: 5CC3CC5ECD: from=, size=520, nrcpt=1 (queue active) The "from" should be "address_2[at]whereto.com" as specified in canonical. There is no "catchall" regexp put by mistake before the list you see above, and nothing after that could have that effect. I just don't get what I'm doing wrong. Any help would be much appreciated. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Envelope sender is not modified correctly
Hi, To channel bounce reports to multiple sender domains I control to specific addresses for analysis I used: In main.cf: canonical_maps = regexp:/etc/postfix/canonical canonical_classes = envelope_sender In canonical: /@abc\.com/ addres...@whereto.com /@def\.com/ addres...@whereto.com /@ghi\.com/ addres...@whereto.com /@jkl\.com/ addres...@whereto.com I checked the regular expressions using (for instance): postmap -q "i...@ghi.com" regexp:/etc/postfix/canonical postmap -q "i...@abc.com" regexp:/etc/postfix/canonical Got (in order): addres...@whereto.com addres...@whereto.com I then postmapped /etc/postfix/canonical and restarted the server. For some reason, the envelope sender is not modified properly when sending mail. A mail sent from "whate...@ghi.com" would leave this trace in maillog: Apr 9 10:44:52 acer postfix/qmgr[2299936]: 5CC3CC5ECD: from=< addres...@whereto.com>, size=520, nrcpt=1 (queue active) The "from" should be "addres...@whereto.com" as specified in canonical. There is no "catchall" regexp put by mistake before the list you see above, and nothing after that could have that effect. I just don't get what I'm doing wrong. Any help would be much appreciated. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Question to reject_rbl_client zen.spamhaus.org
On 2023-04-09 21:14, Wietse Venema via Postfix-users wrote: tom--- via Postfix-users: I have this setting in main.cf: smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_policy_service unix:private/policyd-spf, reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net When I sent message from a Spamhaus Zen listed IP (this IP not in my whitelist), the message still came into system. it seemsreject_rbl_client zen.spamhaus.org has no effect. Where should i debug it? By studying Postfix documentation? http://www.postfix.org/SMTPD_ACCESS_README.html#lists Each restriction list is evaluated from left to right until some restriction produces a result of PERMIT, REJECT or DEFER (try again later). The end of each list is equivalent to a PERMIT result. In your case, reject_rbl_client was NOT USED because permit_mynetworks, permit_sasl_authenticated, or check_policy_service returned a PERMIT result. @Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org Thank you for your support. I am studying what code is returned by policyd-spf. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Question to reject_rbl_client zen.spamhaus.org
tom--- via Postfix-users: > I have this setting in main.cf: > > smtpd_recipient_restrictions = > permit_mynetworks, > permit_sasl_authenticated, > reject_unauth_destination, > check_policy_service unix:private/policyd-spf, > reject_rbl_client zen.spamhaus.org, > reject_rbl_client bl.spamcop.net > > When I sent message from a Spamhaus Zen listed IP (this IP not in my > whitelist), the message still came into system. > it seemsreject_rbl_client zen.spamhaus.org has no effect. > Where should i debug it? By studying Postfix documentation? http://www.postfix.org/SMTPD_ACCESS_README.html#lists Each restriction list is evaluated from left to right until some restriction produces a result of PERMIT, REJECT or DEFER (try again later). The end of each list is equivalent to a PERMIT result. In your case, reject_rbl_client was NOT USED because permit_mynetworks, permit_sasl_authenticated, or check_policy_service returned a PERMIT result. @Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Question to reject_rbl_client zen.spamhaus.org
On 9/04/23 21:23, tom--- via Postfix-users wrote: I am using the policyd-spf by default configuration (never changed a line), and this is the doc: https://manpages.debian.org/testing/postfix-policyd-spf-python/policyd-spf.conf.5.en.html But the doc says noting about "OK" and "DUNNO". so how? Not sure, but since you identified that you are using Google DNS chasing this is likely going to be a red herring, it probably already returns DUNNO anyways. If fixing your DNS doesn't solve the issue then temporarily remove the line for policyd as I stated earlier and that will tell you if policyd is the issue or not. Peter ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Question to reject_rbl_client zen.spamhaus.org
tom--- via Postfix-users skrev den 2023-04-09 09:51: what action code policyd should return for passing the request to next check? DUNNO as in https://doc.dovecot.org/configuration_manual/quota_plugin/ 90-quota.conf example ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Question to reject_rbl_client zen.spamhaus.org
tom--- via Postfix-users skrev den 2023-04-09 08:18: I was exactly using google DNS. Do u mean Google will block queries for RBL? incorrect questions gives incorrect answers google does not block you, but the rbls is blocking google we all live in a free world of unlimited problems to solve Do u mean Google will block queries for RBL No, this does not refer to blocking of any kind on behalf of Google Search Engine (GSE). GSE is an open platform and it allows users to search whatever they want. However, if a query violates the terms & conditions set by Robust Blacklist Lists(RBL), then such queries will be blocked from being searched through RBL's blacklists. used that question to AI bots :) ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Question to reject_rbl_client zen.spamhaus.org
On 2023-04-09 17:12, Benny Pedersen via Postfix-users wrote: tom--- via Postfix-users skrev den 2023-04-09 04:02: I have this setting in main.cf: smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_policy_service unix:private/policyd-spf, reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net When I sent message from a Spamhaus Zen listed IP (this IP not in my whitelist), the message still came into system. it seemsreject_rbl_client zen.spamhaus.org has no effect. Where should i debug it? postfix restrictions is always first match wins so is spf have OK result ? I am using the policyd-spf by default configuration (never changed a line), and this is the doc: https://manpages.debian.org/testing/postfix-policyd-spf-python/policyd-spf.conf.5.en.html But the doc says noting about "OK" and "DUNNO". so how? Thank you. Tom ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Question to reject_rbl_client zen.spamhaus.org
tom--- via Postfix-users skrev den 2023-04-09 04:02: I have this setting in main.cf: smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_policy_service unix:private/policyd-spf, reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net When I sent message from a Spamhaus Zen listed IP (this IP not in my whitelist), the message still came into system. it seemsreject_rbl_client zen.spamhaus.org has no effect. Where should i debug it? postfix restrictions is always first match wins so is spf have OK result ? logs could have helped me helping you for proff smtpd_recipient_restrictions = reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_policy_service unix:private/policyd-spf this will give diffrent results of the problem imho full postconf -n is not unhelpfull aswell ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Question to reject_rbl_client zen.spamhaus.org
On 9/04/23 19:51, tom--- via Postfix-users wrote: First off make sure that policyd isn't somehow returning an OK (or equivalent) response, if you're not sure temporarily remove "check_policy_service unix:private/policyd-spf," from your restrictions above and see if it makes a difference. what action code policyd should return for passing the request to next check? "DUNNO", see access(5). Peter ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Question to reject_rbl_client zen.spamhaus.org
On 9/04/23 18:18, tom--- via Postfix-users wrote: Secondly, and this is *very* important, make certain you are not using your ISP's or another public DNS resolver (such as 8.8.8.8). You *must* run your own DNS resolver for DNSRBLs to work properly. I was exactly using google DNS. Do u mean Google will block queries for RBL? No, as someone else already mentioned, Spamhaus blocks queries from public DNS servers such as Google DNS. Also Spamhaus limits the number of queries that can be performed from a given DNS server so even if they don't explicitly block it you are sharing that limit with everyone else who uses that resolver and will not get reliable results that way. Peter ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: [ext] Question to reject_rbl_client zen.spamhaus.org
> smtpd_recipient_restrictions = >permit_mynetworks, >permit_sasl_authenticated, >reject_unauth_destination, >check_policy_service unix:private/policyd-spf, >reject_rbl_client zen.spamhaus.org, >reject_rbl_client bl.spamcop.net > > When I sent message from a Spamhaus Zen listed IP (this IP not in my > whitelist), the message still came into system. In that case you either sent from: a client in $mynetworks (permit_mynetworks) or an authenticated client (permit_sasl_authenticated) Another option might be that your mailserver is querying zen.spamhaus.org and bl.spamcop.net via a public resolver (1.1.1.1, 8.8.8.8 or the like) which might cause all kinds of odd problems -- thus examine /etc/resolv.conf -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | https://www.charite.de ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Question to reject_rbl_client zen.spamhaus.org
On 2023-04-09 13:53, Peter via Postfix-users wrote: On 9/04/23 14:02, tom--- via Postfix-users wrote: I have this setting in main.cf: smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_policy_service unix:private/policyd-spf, reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net When I sent message from a Spamhaus Zen listed IP (this IP not in my whitelist), the message still came into system. it seems reject_rbl_client zen.spamhaus.org has no effect. Where should i debug it? First off make sure that policyd isn't somehow returning an OK (or equivalent) response, if you're not sure temporarily remove "check_policy_service unix:private/policyd-spf," from your restrictions above and see if it makes a difference. what action code policyd should return for passing the request to next check? Secondly, and this is *very* important, make certain you are not using your ISP's or another public DNS resolver (such as 8.8.8.8). You *must* run your own DNS resolver for DNSRBLs to work properly. I will try to setup my dns resolver locally. Thank you. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Question to reject_rbl_client zen.spamhaus.org
On 9 Apr 2023, at 08:18, tom--- via Postfix-users wrote: > >> First off make sure that policyd isn't somehow returning an OK (or >> equivalent) response, if you're not sure temporarily remove >> "check_policy_service unix:private/policyd-spf," from your restrictions >> above and see if it makes a difference. >> Secondly, and this is *very* important, make certain you are not using your >> ISP's or another public DNS resolver (such as 8.8.8.8). You *must* run your >> own DNS resolver for DNSRBLs to work properly. > > I was exactly using google DNS. Do u mean Google will block queries for RBL? Spamhaus is blocking most queries from public DNS resolver. Also, you should subscribe to their free Data Query Service: https://www.spamhaus.com/free-trial/sign-up-for-a-free-data-query-service-account/ It will give you a dedicated, personal key that can help bypassing public DNS limitation. patpro ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Question to reject_rbl_client zen.spamhaus.org
On 2023-04-09 13:53, Peter via Postfix-users wrote: On 9/04/23 14:02, tom--- via Postfix-users wrote: I have this setting in main.cf: smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_policy_service unix:private/policyd-spf, reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net When I sent message from a Spamhaus Zen listed IP (this IP not in my whitelist), the message still came into system. it seems reject_rbl_client zen.spamhaus.org has no effect. Where should i debug it? First off make sure that policyd isn't somehow returning an OK (or equivalent) response, if you're not sure temporarily remove "check_policy_service unix:private/policyd-spf," from your restrictions above and see if it makes a difference. Secondly, and this is *very* important, make certain you are not using your ISP's or another public DNS resolver (such as 8.8.8.8). You *must* run your own DNS resolver for DNSRBLs to work properly. I was exactly using google DNS. Do u mean Google will block queries for RBL? Thanks ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
