Re: Postfix Helo reverse Exception

[Noel Jones]

On 3/20/2021 9:33 PM, li...@lazygranch.com wrote:



...


This got me wondering about my own configuration. It turns out I use the
other reverse check:

smtpd_client_restrictions =
   permit_sasl_authenticated,
   permit_mynetworks,
   reject_unauth_destination,
   check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre,


The fqrdns file is fine. I've used it for a long time with good 
results and (near) zero false positives. It also has the advantage 
that it doesn't need much maintenance.



   reject_unknown_reverse_client_hostname,


This will reject clients with no/bad PTR hostname. This is mostly 
safe since many major mail providers will either mark such mail as 
spam or outright reject it.


If these aren't causing you any trouble, feel free to keep using them.



  -- Noel Jones

Re: Postfix Helo reverse Exception

[li...@lazygranch.com]

On Sat, 20 Mar 2021 21:28:31 -0400
Viktor Dukhovni  wrote:

> On Sat, Mar 20, 2021 at 08:23:20PM -0400, Wietse Venema wrote:
> > David Mehler:
> 
> > > I don't want to blanket disable reject_unknown_helo_hostname is
> > > there a way I can set a helo exception for this one host/sender?
> > 
> > Yes you can.
> > 
> > smtpd_recipient_restrictions =
> > ...
> > reject_unauth_destination
> > check_client_access inline:{example.com=permit}
> > reject_unknown_helo_hostname
> 
> Since the OP has the rule in smtpd_helo_restrictions and also because
> whitelisting by client hostname (dynamically derived from PTR +
> forward lookup) is fragile, the rule I'd recommend would be:
> 
> smtpd_helo_restrictions =
> ...
> check_helo_access inline:{bogus.example=permit}
> reject_unknown_helo_hostname
> 
> This exempts the specific name that would otherwise be rejected,
> but does so for all clients.  One could instead permit any
> HELO name from a particular IP block, where the problem client
> lives:
> 
>   main.cf:
> cidr = cidr:${config_directory}/
> smtpd_helo_restrictions =
> ...
> check_client_access ${cidr}filter-helo.cidr
> 
>   filter-helo.cidr:
> 192.0.2.0/24DUNNO
> 0.0.0.0/0   reject_unknown_helo_hostname
> 
> Or, as Wietse suggested, if this becomes a game of whack-a-mole, just
> forgo the rule that requires PTR records for the HELO name.
> 

This got me wondering about my own configuration. It turns out I use the
other reverse check:

smtpd_client_restrictions =
  permit_sasl_authenticated,
  permit_mynetworks,
  reject_unauth_destination,
  check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre,
  reject_unknown_reverse_client_hostname,
  check_client_access hash:/etc/postfix/spamsources

This stops many a spammer. I forget who posted the info on the fqrdns
but that is very effective as well. 

Here is the prce as a pastebin since it is really large:

fpaste fqrdns.pcre 
Uploading (239.6KiB)...
https://paste.centos.org/view/07737b27

Re: Postfix Helo reverse Exception

[Viktor Dukhovni]

On Sat, Mar 20, 2021 at 08:23:20PM -0400, Wietse Venema wrote:
> David Mehler:

> > I don't want to blanket disable reject_unknown_helo_hostname is there
> > a way I can set a helo exception for this one host/sender?
> 
> Yes you can.
> 
>   smtpd_recipient_restrictions =
>   ...
>   reject_unauth_destination
>   check_client_access inline:{example.com=permit}
>   reject_unknown_helo_hostname

Since the OP has the rule in smtpd_helo_restrictions and also because
whitelisting by client hostname (dynamically derived from PTR + forward
lookup) is fragile, the rule I'd recommend would be:

smtpd_helo_restrictions =
...
check_helo_access inline:{bogus.example=permit}
reject_unknown_helo_hostname

This exempts the specific name that would otherwise be rejected,
but does so for all clients.  One could instead permit any
HELO name from a particular IP block, where the problem client
lives:

  main.cf:
cidr = cidr:${config_directory}/
smtpd_helo_restrictions =
...
check_client_access ${cidr}filter-helo.cidr

  filter-helo.cidr:
192.0.2.0/24DUNNO
0.0.0.0/0   reject_unknown_helo_hostname

Or, as Wietse suggested, if this becomes a game of whack-a-mole, just
forgo the rule that requires PTR records for the HELO name.

-- 
Viktor.

Re: Postfix Helo reverse Exception

[Phil Stracchino]

On 3/20/21 8:23 PM, Wietse Venema wrote:
> But it is better to stop using reject_unknown_helo_hostname because
> the are many misconfigured servers that send legitimat mail.

That is an interesting piece of advice.


-- 
  Phil Stracchino
  Babylon Communications
  ph...@caerllewys.net
  p...@co.ordinate.org
  Landline: +1.603.293.8485
  Mobile:   +1.603.998.6958

Re: Postfix Helo reverse Exception

[Wietse Venema]

David Mehler:
> Mar 20 18:19:12 mail postfix/smtpd[53636]: NOQUEUE: reject: RCPT from
> xxx.xxx.xxx.xxx[xxx.xxx.xxx.xxx]: 550 5.7.1 : Helo
> command rejected: Host not found; from= to=
> proto=ESMTP helo=

As documented ("man 5 postconf", or www.postfix.org/postconf.5.html):

  reject_unknown_helo_hostname
Reject the request when the HELO or EHLO hostname has no DNS A
or MX record.

> Googling brought me to an issue where this was discussed pointing to
> reject_unknown_helo_hostname as the likely culprit since the mail
> server a and ptr records are working fine, but the helo it's sending
> doesn't reverse ptr.

Nope, this has nothing to do with PTR records. It's A and MX (and
 in the case that IPv6 is turned on).

> The fix was a suggestion of commenting out
> reject_unknown_helo_hostname checking:
> 
> https://serverfault.com/questions/922935/why-does-postfix-say-helo-command-rejected-host-not-found-when-dig-finds-the
> http://www.postfix.org/postconf.5.html#reject_invalid_helo_hostname
> 
> I don't want to blanket disable reject_unknown_helo_hostname is there
> a way I can set a helo exception for this one host/sender?

Yes you can.

smtpd_recipient_restrictions =
...
reject_unauth_destination
check_client_access inline:{example.com=permit}
reject_unknown_helo_hostname

But it is better to stop using reject_unknown_helo_hostname because
the are many misconfigured servers that send legitimat mail.

Wietse

Postfix Helo reverse Exception

[David Mehler]

Hello,

I'm needing to set up an helo exception for a single host.

Mar 20 18:19:11 mail postfix/smtpd[53636]: connect from
xxx.xxx.xxx[xxx.xxx.xxx.xxx]
Mar 20 18:19:11 mail postfix/smtpd[53636]: Anonymous TLS connection
established from xxx.xxx.xxx[xxx.xxx.xxx.xxx]: TLSv1.2 with cipher
ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)
Mar 20 18:19:12 mail postfix/smtpd[53636]: NOQUEUE: reject: RCPT from
xxx.xxx.xxx.xxx[xxx.xxx.xxx.xxx]: 550 5.7.1 : Helo
command rejected: Host not found; from= to=
proto=ESMTP helo=
Mar 20 18:19:12 mail postfix/smtpd[53636]: disconnect from
xxx.xxx.xxx[xxx.xxx.xxx.xxx] ehlo=2 starttls=1 mail=1 rcpt=0/1
data=0/1 rset=1 quit=1 commands=6/8

Googling brought me to an issue where this was discussed pointing to
reject_unknown_helo_hostname as the likely culprit since the mail
server a and ptr records are working fine, but the helo it's sending
doesn't reverse ptr. The fix was a suggestion of commenting out
reject_unknown_helo_hostname checking:

https://serverfault.com/questions/922935/why-does-postfix-say-helo-command-rejected-host-not-found-when-dig-finds-the
http://www.postfix.org/postconf.5.html#reject_invalid_helo_hostname

I don't want to blanket disable reject_unknown_helo_hostname is there
a way I can set a helo exception for this one host/sender?

My helo section is below with the commented out option:

# helo restrictions
smtpd_helo_required = yes
smtpd_helo_restrictions =
 permit_mynetworks
 permit_sasl_authenticated
 reject_invalid_helo_hostname
 reject_non_fqdn_helo_hostname
#reject_unknown_helo_hostname
check_helo_access hash:/usr/local/etc/postfix/helo_access,


and my complete postconf -n output
#postconf -n
allow_percent_hack = no
append_dot_mydomain = no
biff = no
bounce_queue_lifetime = 1h
bounce_template_file = /usr/local/etc/postfix/bounce.cf
broken_sasl_auth_clients = no
command_directory = /usr/local/sbin
compatibility_level = 2
daemon_directory = /usr/local/libexec/postfix
data_directory = /var/db/postfix
delay_warning_time = 4h
disable_vrfy_command = yes
header_checks = regexp:/usr/local/etc/postfix/phish419.regexp
html_directory = no
in_flow_delay = 1s
inet_interfaces = xxx.xxx.xxx.xxx
inet_protocols = ipv4
lmtp_tls_mandatory_protocols = $smtpd_tls_mandatory_protocols
lmtp_tls_protocols = $smtpd_tls_protocols
local_recipient_maps = $virtual_mailbox_maps
mail_owner = postfix
mailbox_size_limit = 0
mailq_path = /usr/local/bin/mailq
manpage_directory = /usr/local/man
maximal_backoff_time = 15m
maximal_queue_lifetime = 1h
message_size_limit = 52428800
meta_directory = /usr/local/libexec/postfix
milter_default_action = accept
milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen}
milter_protocol = 6
mime_header_checks = regexp:/usr/local/etc/postfix/mime_header_checks
minimal_backoff_time = 5m
mydestination = mail.example.com
mydomain = example.com
myhostname = mail.example.com
mynetworks = $config_directory/mynetworks
myorigin = $mydomain
newaliases_path = /usr/local/bin/newaliases
non_smtpd_milters = $smtpd_milters
postscreen_access_list = permit_mynetworks,
cidr:/usr/local/etc/postfix/postscreen_access.cidr,
cidr:/usr/local/etc/postfix/postscreen_spf_whitelist.cidr
postscreen_bare_newline_action = enforce
postscreen_bare_newline_enable = yes
postscreen_blacklist_action = drop
postscreen_cache_cleanup_interval = 0
postscreen_cache_map = proxy:btree:${data_directory}/postscreen_cache
postscreen_dnsbl_action = enforce
postscreen_dnsbl_reply_map =
pcre:$config_directory/postscreen_dnsbl_reply_map.pcre
postscreen_dnsbl_sites = zen.spamhaus.org*3 b.barracudacentral.org*2
bl.spameatingmonkey.net*2 bl.spamcop.net dnsbl.sorbs.net
psbl.surriel.com bl.mailspike.net
list.dnswl.org=127.[0..255].[0..255].0*-2
list.dnswl.org=127.[0..255].[0..255].1*-3
list.dnswl.org=127.[0..255].[0..255].[2..255]*-4
postscreen_dnsbl_threshold = 3
postscreen_dnsbl_whitelist_threshold = -1
postscreen_greet_action = enforce
postscreen_non_smtp_command_enable = yes
postscreen_pipelining_enable = yes
queue_directory = /var/spool/postfix
queue_run_delay = 5m
readme_directory = no
recipient_delimiter = +
sample_directory = /usr/local/etc/postfix
sendmail_path = /usr/local/sbin/sendmail
setgid_group = maildrop
shlib_directory = /usr/local/lib/postfix
show_user_unknown_table_name = no
smtp_helo_timeout = 60s
smtp_tls_CApath = $smtpd_tls_CApath
smtp_tls_ciphers = high
smtp_tls_loglevel = 1
smtp_tls_mandatory_ciphers = medium
smtp_tls_mandatory_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4,
MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDC3-SHA, KRB5-DE5,
CBC3-SHA
smtp_tls_mandatory_protocols = $smtpd_tls_mandatory_protocols
smtp_tls_protocols = $smtpd_tls_protocols
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_use_tls = yes
smtpd_banner = $myhostname ESMTP
smtpd_client_restrictions = permit_sasl_authenticated
reject_unknown_reverse_client_hostname check_client_access
cidr:/usr/local/etc/postfix/spamfarms c

Re: BINARYMIME in Postfix

[Wietse Venema]

Demi Marie Obenour:
> How useful would BINARYMIME support be?  It does mean that DKIM signing
> would need to be done in the sending path, but I cannot think of any
> reasons that would be a blocker.  Having DKIM and DMARC built-in to
> Postfix would be a nice feature, tbh.  The only open-source MTA I
> know of with built-in DKIM is Exim but I would never dare use it in
> production.
> 
> Ideally, the signing keys should be in a separate process for privilege
> separation, but Postfix is already multi-process so that should be
> doable.  Of course, the final decision is up to Wietse.

See also https://github.com/OpenSMTPD/OpenSMTPD/issues/1090

I haven't had the time to properly analyze what this would take.
Here's a first inventory.

- Background: there is no 1:1 relationship between BINARYMIME chunks
and MIME segments. One incoming BINARYMIME chunk can contain any
combination of MIME text segments and MIME binary segments, and one
large MIME segment can span multiple chunks.

- Background: Postfix does not store text line endings ( or
) internally. When receiving mail, the Postfix SMTP server
strips  line endings from text, and the Postfix sendmail
command strips  line endings when ingesting mail submitted with
UNIX command-line tools. When delivering mail, Postfix appends 
line endings when writing message text to a UNIX file or command,
and Postfix appends  line endings when writing message text
to a remote SMTP server. Line endings are not a message property;
instead, they are a property of the external environment, to be
added by Postfix delivery agents and to be stripped by Postfix mail
receiving programs.

- Impact: in a receiving Postfix server, the Postfix MIME parser
needs to be changed to strip  line endings from MIME headers
and from lines in MIME text segments, and the Postfix SMTP server
needs to be changed to stop stripping those  line endings.

- Impact: the Postfix MIME parser needs new support for 'type binary'
MIME body content, and it must parse such content not as lines of
text ending in --boundary-string", but as a binary
blob with a length determined by a preceding Content-Length MIME
header.

- Impact: binary blobs need to be passed around internally in Postfix
as a new type of record, so that they remain distinct from Postfix
text records. Specifically, the smtpd daemon sends BINARYMIME chunks
as blobs to the cleanup daemon (and maybe also other message content).

- The impact on Milters or other extrnal content filters is unknown. 

- The impact on smtpd_proxy_filter is unknown. Currently, the Postfix
SMTP daemon replaces a sequence of BDAT commands with a single DATA
command. That can't work with BINARYMIME, because BINARYMIME is
fundamentally incompatible with DATA.

- The impact on UNIX mailbox stores is unknown (these store multiple
messages per file). Every mail reading program will have to understand
MIME and will have to parse Content-Length: headers or else it will
be hopelessly confused about where a message ends.

That's just a few things off the top of my head.:1

Wietse

BINARYMIME in Postfix

[Demi Marie Obenour]

On 3/20/21 2:51 PM, John Levine wrote:
> It's defined in RFC 3030.  Read all about it: 
> https://www.rfc-editor.org/info/rfc3030
> 
> It happens that I just added CHUNKING and BDAT to an MTA I use (mailfront if 
> you know
> what that is.)  Inbound the code is quite simple and I would be surprised if 
> there were
> any problems with it.  Outbound it's a little trickier since BDAT requires 
> you to know
> the exact size of the chunk of message you're sending, which means it has to 
> deal with
> turning \n into \r\n, but again, it's not a big deal.
> 
> I'm guessing that someone had some problem talking to Gmail or 
> Hotmail/Outlook, the
> two largest systems that can use BDAT, turned it off to see if that was the 
> problem,
> and never bothered to turn it back on when it wasn't.

This reminded me that Postfix does not have BINARYMIME support.
GMail does not, but Outlook does.

How useful would BINARYMIME support be?  It does mean that DKIM signing
would need to be done in the sending path, but I cannot think of any
reasons that would be a blocker.  Having DKIM and DMARC built-in to
Postfix would be a nice feature, tbh.  The only open-source MTA I
know of with built-in DKIM is Exim but I would never dare use it in
production.

Ideally, the signing keys should be in a separate process for privilege
separation, but Postfix is already multi-process so that should be
doable.  Of course, the final decision is up to Wietse.

Sincerely,

Demi Marie Obenour
she/her/hers


OpenPGP_0xB288B55FFF9C22C1.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: Backscatter problems + fixes + RFC idea

[Rahul Dhesi]

On Sat, 20 Mar 2021, Dominic Raferd wrote:

You may find my script helpful: 
https://www.timedicer.co.uk/programs/help/relay-enforcer.sh.php


Looks very interesting, thanks. I ran 'shellcheck' on it and saw many 
scary warnings; highly recommended to revise the code to fix all of them.


Rahul

Re: discarding EHLO keywords: CHUNKING

[John Levine]

It appears that LoneStarKen  said:
>Possibly.  Since I am unsure why the package maintainer disabled
>CHUNKING I am concerned enabling it, we might have a broken
>implementation of BDAT or even worse something else breaks.
>Since this is a production server, I'm going to err on the
>side of caution until I get some clarification from the
>package maintainer regarding the decision to disable it.
>
>In addition, I have been unable to find enough information on
>BDAT to feel comfortable I know how it should work and how
>to test it in the event we decided to enable it.

It's defined in RFC 3030.  Read all about it: 
https://www.rfc-editor.org/info/rfc3030

It happens that I just added CHUNKING and BDAT to an MTA I use (mailfront if 
you know
what that is.)  Inbound the code is quite simple and I would be surprised if 
there were
any problems with it.  Outbound it's a little trickier since BDAT requires you 
to know
the exact size of the chunk of message you're sending, which means it has to 
deal with
turning \n into \r\n, but again, it's not a big deal.

I'm guessing that someone had some problem talking to Gmail or Hotmail/Outlook, 
the
two largest systems that can use BDAT, turned it off to see if that was the 
problem,
and never bothered to turn it back on when it wasn't.

To test it, turn it on, send yourself a fairly large message from a Gmail 
account,
and see if you get it.

R's,
John

Re: discarding EHLO keywords: CHUNKING

[Benny Pedersen]

On 2021-03-20 15:22, LoneStarKen wrote:


In addition, I have been unable to find enough information on
BDAT to feel comfortable I know how it should work and how
to test it in the event we decided to enable it.


thank you for using postfix, its stable code in the first place unless 
you can show examples of not stable, one could drop postfix if exim or 
sendmail is more stable, but i have used postfix last 30 years or so, 
its stable for me at least


i am just shooked to see you trust centos more then maintainers of 
postfix c code

Re: discarding EHLO keywords: CHUNKING

[LoneStarKen]

Possibly.  Since I am unsure why the package maintainer disabled
CHUNKING I am concerned enabling it, we might have a broken
implementation of BDAT or even worse something else breaks.
Since this is a production server, I'm going to err on the
side of caution until I get some clarification from the
package maintainer regarding the decision to disable it.

In addition, I have been unable to find enough information on
BDAT to feel comfortable I know how it should work and how
to test it in the event we decided to enable it.

> On Mar 20, 2021, at 9:01 AM, Matus UHLAR - fantomas  wrote:
> 
> On 20.03.21 08:38, LoneStarKen wrote:
>> Thank you for all the help Viktor.  Based on your advice, I decided
>> the package maintainer probably had some reason to disable
>> CHUNKING so I just added the following to main.cf to quiet the
>> logging:
>> 
>> smtpd_discard_ehlo_keywords = chunking, silent-discard
>> 
>> I also entered a bug in bugs.centos.org requesting clarification on
>> the decision to disable CHUNKING.
> 
> wouldn't is be better to enable chunking by setting it to empty?
> 
> smtpd_discard_ehlo_keywords = 
> especially when you want to have BDAT working...
> -- 
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> Microsoft dick is soft to do no harm

Re: discarding EHLO keywords: CHUNKING

[Matus UHLAR - fantomas]

On 20.03.21 08:38, LoneStarKen wrote:

Thank you for all the help Viktor.  Based on your advice, I decided
the package maintainer probably had some reason to disable
CHUNKING so I just added the following to main.cf to quiet the
logging:

smtpd_discard_ehlo_keywords = chunking, silent-discard

I also entered a bug in bugs.centos.org requesting clarification on
the decision to disable CHUNKING.


wouldn't is be better to enable chunking by setting it to empty?

smtpd_discard_ehlo_keywords = 


especially when you want to have BDAT working...
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Microsoft dick is soft to do no harm

Re: discarding EHLO keywords: CHUNKING

[LoneStarKen]

Thank you for all the help Viktor.  Based on your advice, I decided
the package maintainer probably had some reason to disable
CHUNKING so I just added the following to main.cf to quiet the
logging:

smtpd_discard_ehlo_keywords = chunking, silent-discard

I also entered a bug in bugs.centos.org requesting clarification on
the decision to disable CHUNKING. 

Re: Send advice when user receive email

On 19 Mar 2021, at 07:13, Enrico Morelli  wrote:
> I have a postfix server with virtual_transport = 
> lmtp:unix:private/dovecot-lmtp
> 
> Is there a way to send and advise to another email address each time I 
> receive an email?




   ^ remove

(Remove the space in the mailto link of you use it, inserted because of postfix 
list restrictions.)

-- 
'The trouble with my friend here is that he doesn't know the
difference between a postulate and a metaphor of human existence.
Or a hole in the ground.' --Pyramids

Re: _time_limit

[@lbutlr]

> On 20 Mar 2021, at 03:19, Simon Wilson  wrote:
> 
> 0 check_policy_service unix:private/policyd-spf
> 11 ...
> 12 policyd-spf_time_limit = 3600

Just out of curisotu, have you tried it exactly as the sample shows:

policy  unix  -   n   n   -   0   spawn
   user=nobody argv=/usr/bin/policyd-spf

. . .

check_policy_service unix:private/policy 
policy_time_limit = 3600


-- 
Naked blonde walks into a bar with a poodle under one arm, and
two-foot salami under the other. The bartender says, I guess you
won't be needing a drink. Naked lady says

Re: _time_limit

[Simon Wilson]

- Message from Simon Wilson  -
Date: Sat, 20 Mar 2021 19:19:49 +1000
From: Simon Wilson 
Reply-To: si...@simonandkate.net
 Subject: _time_limit
  To: postfix-users@postfix.org


According to  Postfix SMTP Access Policy Delegation[1] "_time_limit"  
takes the format of


"transport_time_limit ($command_time_limit): The maximal amount of  
time the policy daemon is allowed to run before it is terminated.  
The transport is the service name of the master.cf entry for the  
policy daemon service."


Replicating the format on that page, my setup is:

 1 /etc/postfix/master.cf:
 2 policyd-spf  unix  -   n   n   -   0   spawn
 3  user=nobody argv=/usr/bin/policyd-spf
 4
 5 /etc/postfix/main.cf:
 6 smtpd_recipient_restrictions =
 7 ...
 8 reject_unauth_destination
 9 ...
10 check_policy_service unix:private/policyd-spf
11 ...
12 policyd-spf_time_limit = 3600

It looks to me like I am naming it all correctly, but I get:

 postconf: warning: /etc/postfix/main.cf: unused parameter:  
policyd-spf_time_limit=3600


This is on Postfix 3.3 on RHEL8

What am I doing wrong here, or is this just because the name is a  
transportname_parameter construct?


Simon


Links:
--
[1] http://www.postfix.org/SMTPD_POLICY_README.html



- End message from Simon Wilson  -


I had an errant space. Apologies for the un-needed message to the list...

Simon

--
Simon Wilson
M: 0400 12 11 16

_time_limit

[Simon Wilson]

According to  Postfix SMTP Access Policy Delegation[1] "_time_limit"  
takes the format of


"transport_time_limit ($command_time_limit): The maximal amount of  
time the policy daemon is allowed to run before it is terminated. The  
transport is the service name of the master.cf entry for the policy  
daemon service."


Replicating the format on that page, my setup is:

 1 /etc/postfix/master.cf:
 2 policyd-spf  unix  -   n   n   -   0   spawn
 3  user=nobody argv=/usr/bin/policyd-spf
 4
 5 /etc/postfix/main.cf:
 6 smtpd_recipient_restrictions =
 7 ...
 8 reject_unauth_destination
 9 ...
10 check_policy_service unix:private/policyd-spf
11 ...
12 policyd-spf_time_limit = 3600

It looks to me like I am naming it all correctly, but I get:

 postconf: warning: /etc/postfix/main.cf: unused parameter:  
policyd-spf_time_limit=3600


This is on Postfix 3.3 on RHEL8

What am I doing wrong here, or is this just because the name is a  
transportname_parameter construct?


Simon


Links:
--
[1] http://www.postfix.org/SMTPD_POLICY_README.html

--
Simon Wilson
M: 0400 12 11 16

Re: Backscatter problems + fixes + RFC idea

[Dominic Raferd]

On 20/03/2021 01:53, Rahul Dhesi wrote:

On Fri, 19 Mar 2021, Wietse Venema wrote:


See examples in:
http://www.postfix.org/postconf.5.html#default_delivery_status_filter
(this was originally designed to turn soft TLS errors into hard ones).


Thanks, that is a vey nice feature I did not know about.

I should mention that my strategy of using a cron job to delete 
spam-suspect queued mail is not yet final, because:


When Gmail returns a spam-related temporary error, it might just be 
greylisting the sending client for some time, and maybe the message is 
not spam and will eventually be accepted.


This needs to be observed further.


You may find my script helpful: 
https://www.timedicer.co.uk/programs/help/relay-enforcer.sh.php