about MX hosts
Hello I saw my ESP has two MX records pointing to just the same host. rambler.ru. 21 IN MX 5 inmx.rambler.ru. rambler.ru. 21 IN MX 10 inmx.rambler.ru. Does this have any value inprovement? Thanks
Re: anvil statistics logging
Fourhundred Thecat skrev den 2019-10-23 05:56: statistics: max connection rate 1/60s for statistics: max connection count 1 for statistics: max message rate 1/60s for statistics: max recipient rate 1/60s statistics: max cache size Can I still use these limits, but suppress the statistics ? https://serverfault.com/questions/643125/how-can-i-suppress-postfix-anvil-statistics-from-system-logs
anvil statistics logging
Hello, can I disable the anvil statistics from being written to the logs ? I have quite short "anvil_rate_time_unit" (60s), and I have set some of the "smtpd_client" rate limits to 10. My log is basically flooded with these anvil statistics, which I am not really interested in. statistics: max connection rate 1/60s for statistics: max connection count 1 for statistics: max message rate 1/60s for statistics: max recipient rate 1/60s statistics: max cache size Can I still use these limits, but suppress the statistics ? thanks,
Re: Unusual TLS setting logged by Postfix
On Tue, Oct 22, 2019 at 05:37:14PM -0400, J Doe wrote: > > On Oct 22, 2019, at 1:18 AM, Viktor Dukhovni > > wrote: > > > >$ openssl ciphers -stdname -s -tls1 -V AES256-SHA > >0x00,0x35 - TLS_RSA_WITH_AES_256_CBC_SHA - AES256-SHA SSLv3 > > Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 > > Ah, cool - I did not realize I could use the openssl command to “translate” > the string that way. > > I see the AES mode, now, but I still can’t see whether DH/DHE/ECDHE was > used for negotiation (or am I missing that in the output) ? You see them not used. Kx=RSA. See ciphers(1): -v Verbose output: For each cipher suite, list details as provided by SSL_CIPHER_description(3). SSL_CIPHER_description(3): ... SSL_CIPHER_get_kx_nid() returns the key exchange NID corresponding to the method used by c. If there is no key exchange, then NID_undef is returned. If any appropriate key exchange algorithm can be used (as in the case of TLS 1.3 cipher suites) NID_kx_any is returned. Examples (not comprehensive): NID_kx_rsa NID_kx_ecdhe NID_kx_dhe NID_kx_psk ... The string returned by SSL_CIPHER_description() consists of several fields separated by whitespace: Textual representation of the cipher name. The minimum protocol version that the ciphersuite supports, such as TLSv1.2. Note that this is not always the same as the protocol version in which the ciphersuite was first defined because some ciphersuites are backwards compatible with earlier protocol versions. Kx= Key exchange method such as RSA, ECDHE, etc. Au= Authentication method such as RSA, None, etc.. None is the representation of anonymous ciphers. Enc= Encryption method, with number of secret bits, such as AESGCM(128). Mac= Message digest, such as SHA256. Some examples for the output of SSL_CIPHER_description(): ECDHE-RSA-AES256-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD RSA-PSK-AES256-CBC-SHA384 TLSv1.0 Kx=RSAPSK Au=RSA Enc=AES(256) Mac=SHA384 -- Viktor.
Re: Problem with new installation
Thanks, Noel. Very helpful. MySQL is definitely installed and working, but I don't know about Milter, as it was set up by someone else who didn't quite do well by me in educating me in the find points of Postfix management, which is why I am where I am today. I'll get on that and report back. On 10/22/2019 3:46 PM, Noel Jones wrote: On 10/22/2019 1:58 PM, Steve Matzura wrote: I am running a copy of configurations from a running version 2 installation from Ubuntu 14.04, now alive as version 3 on Ubuntu 18.04. I thought I'd be slick and port over all the user mailbox directories in /var/mail/vmail, all the customized .cf's, and the MySQL database. Everything ported over nicely, Postfix runs in backward compatibility mode, but for every mail message, I get this in syslog: Oct 22 18:51:36 tgvprod postfix/pickup[1114]: 852EB604E4: uid=1000 from= Oct 22 18:51:36 tgvprod postfix/cleanup[2770]: warning: connect to Milter service inet:localhost:8891: Connection refused This usually means the milter service isn't started, or not installed. Or maybe the firewall preventing connections to the milter. Did you install the milter from the other machine and copy its config? Ditto firewall config? Test until you get the milter working. The default value milter_default_action=tempfail will prevent postfix from receiving mail until this is fixed. Oct 22 18:51:36 tgvprod postfix/cleanup[2770]: warning: proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf lookup error for "tgvpadmin@tgvprod" maybe your sql service isn't started, or not installed. Did you install sql and copy the sql config files from the old machine? Test until you get sql queries working. Generally it's easier to start with hash: files before adding the complexity of a database. To prevent losing mail, postfix will tempfail all mail when there's a map lookup error. -- Noel Jones
Re: Unusual TLS setting logged by Postfix
> On Oct 22, 2019, at 1:18 AM, Viktor Dukhovni > wrote: > >$ openssl ciphers -stdname -s -tls1 -V AES256-SHA >0x00,0x35 - TLS_RSA_WITH_AES_256_CBC_SHA - AES256-SHA SSLv3 > Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 Hi Viktor, Ah, cool - I did not realize I could use the openssl command to “translate” the string that way. I see the AES mode, now, but I still can’t see whether DH/DHE/ECDHE was used for negotiation (or am I missing that in the output) ? Thanks, - J
Re: Problem with new installation
On 10/22/2019 1:58 PM, Steve Matzura wrote: I am running a copy of configurations from a running version 2 installation from Ubuntu 14.04, now alive as version 3 on Ubuntu 18.04. I thought I'd be slick and port over all the user mailbox directories in /var/mail/vmail, all the customized .cf's, and the MySQL database. Everything ported over nicely, Postfix runs in backward compatibility mode, but for every mail message, I get this in syslog: Oct 22 18:51:36 tgvprod postfix/pickup[1114]: 852EB604E4: uid=1000 from= Oct 22 18:51:36 tgvprod postfix/cleanup[2770]: warning: connect to Milter service inet:localhost:8891: Connection refused This usually means the milter service isn't started, or not installed. Or maybe the firewall preventing connections to the milter. Did you install the milter from the other machine and copy its config? Ditto firewall config? Test until you get the milter working. The default value milter_default_action=tempfail will prevent postfix from receiving mail until this is fixed. Oct 22 18:51:36 tgvprod postfix/cleanup[2770]: warning: proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf lookup error for "tgvpadmin@tgvprod" maybe your sql service isn't started, or not installed. Did you install sql and copy the sql config files from the old machine? Test until you get sql queries working. Generally it's easier to start with hash: files before adding the complexity of a database. To prevent losing mail, postfix will tempfail all mail when there's a map lookup error. -- Noel Jones
Problem with new installation
I am running a copy of configurations from a running version 2 installation from Ubuntu 14.04, now alive as version 3 on Ubuntu 18.04. I thought I'd be slick and port over all the user mailbox directories in /var/mail/vmail, all the customized .cf's, and the MySQL database. Everything ported over nicely, Postfix runs in backward compatibility mode, but for every mail message, I get this in syslog: Oct 22 18:51:36 tgvprod postfix/pickup[1114]: 852EB604E4: uid=1000 from= Oct 22 18:51:36 tgvprod postfix/cleanup[2770]: warning: connect to Milter service inet:localhost:8891: Connection refused Oct 22 18:51:36 tgvprod postfix/cleanup[2770]: warning: proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf lookup error for "tgvpadmin@tgvprod" or this: Oct 22 18:54:08 tgvprod postfix/smtpd[3174]: connect from web01.groups.io[66.175.222.12] Oct 22 18:54:09 tgvprod postfix/smtpd[3174]: NOQUEUE: reject: RCPT from web01.groups.io[66.175.222.12]: 451 4.3.0 : Temporary lookup failure; from= to= proto=ESMTP helo= Oct 22 18:54:09 tgvprod postfix/smtpd[3174]: lost connection after RCPT from web01.groups.io[66.175.222.12] Oct 22 18:54:09 tgvprod postfix/smtpd[3174]: disconnect from web01.groups.io[66.175.222.12] ehlo=2 starttls=1 mail=1 rcpt=0/1 commands=4/5 I'm thinking it's something common to both problems, but can't figure what. Any assistance gratefully appreciated.
Re: Change info message to warning
miim: > > > I agree. I customize the logging code quite a bit to my own > preferences for readability. What I need to know is where that > particular message is sent to syslog so I can change the call from > msg_info to msg_warn. Just the source module name will be sufficient; > I can hunt it down from there. The code that generates the text for DNSBL rejects sits in file smtpd_check.c function rbl_reject_reply(). However, this function does not choose between info and warning, that happens in the smtpd_check_reject() function that logs all 'reject' actions. To make the severity configurable one could run the formatted text through a configurable PCRE lookup table that returns what severity to log with (info, warn, error, panic). One would use a NAME_CODE table to parse that result and decide whether to call msg_info(), msg_warn(), etc. Wietse
Re: Change info message to warning
I agree. I customize the logging code quite a bit to my own preferences for readability. What I need to know is where that particular message is sent to syslog so I can change the call from msg_info to msg_warn. Just the source module name will be sufficient; I can hunt it down from there. On Tuesday, 22 October 2019, 12:13:33 PM GMT-5, Wietse Venema wrote: miim: > Oct 22 13:13:32 postfix[8412]: NOQUEUE: reject: RCPT from > unknown[300.301.302.303]: 510 5.7.1 Your IP address is blacklisted - send > from a different network; from= to= proto=ESMTP > helo= postscreen logging does not have unknown[ipaddress]; it just has [ipaddress]. Instead, this is an smtpd message. Postfix log messages have postfix/program[process-id]. In this case it should have been something like "postfix/smtpd[process-id]. Postfix source code does not contain 'Your IP address is blacklisted'. You're getting that string from elesewhere. You can configure Postfix log facility (mail, etc.) but not the severity (info, warning, etc.). Wietse
Re: Change info message to warning
miim: > Oct 22 13:13:32 postfix[8412]: NOQUEUE: reject: RCPT from > unknown[300.301.302.303]: 510 5.7.1 Your IP address is blacklisted - send > from a different network; from= to= proto=ESMTP > helo= postscreen logging does not have unknown[ipaddress]; it just has [ipaddress]. Instead, this is an smtpd message. Postfix log messages have postfix/program[process-id]. In this case it should have been something like "postfix/smtpd[process-id]. Postfix source code does not contain 'Your IP address is blacklisted'. You're getting that string from elesewhere. You can configure Postfix log facility (mail, etc.) but not the severity (info, warning, etc.). Wietse
Change info message to warning
I'd like to change the DNS blacklist message from msg_info (logged in the main log file) to msg_warn (logged in the warning file.) That is the second line in the log extract below. I have: a) looked through the postscreen source b) grepped the distribution for NOQUEUE: and reject: piped through grep msg_info and I can't find the code which generates that particular message Oct 22 13:13:31 postfix[8412]: Connect:Unknown [64.27.10.3] Oct 22 13:13:32 postfix[8412]: NOQUEUE: reject: RCPT from unknown[300.301.302.303]: 510 5.7.1 Your IP address is blacklisted - send from a different network; from= to= proto=ESMTP helo= Oct 22 13:13:32 postfix[8412]: lost connection after RCPT from unknown[64.27.10.3] Can someone advise me where the message is actually sent to syslog, (presumably) using msg_info ?
Re: Rewrite From header from old to new style
On Tue, 22 Oct 2019 at 17:05, Wietse Venema wrote: > > Noel Jones: > > On 10/22/2019 10:27 AM, Dominic Raferd wrote: > > > On Tue, 22 Oct 2019 at 16:18, Noel Jones wrote: > > >> ... > > >>> I am using postfix 3.3. Apart from cron, the only other local source > > >>> of such old-style headers that I can find is postfix itself: > > >>> e.g. From: mailer-dae...@streamingbats.co.uk (Mail Delivery System) > > >>> - maybe more recent postfix releases use the new style? > > >>> > > >> > > >> > > >> http://www.postfix.org/postconf.5.html#header_from_format > > > > > > Thanks Noel but I am using that (default) setting already: > > > # postconf header_from_format > > > header_from_format = standard > > > > > > I find the same behaviour in postfix 3.3.0 and 3.3.2. > > > > > > > > > Then whatever is generating the mail uses the obsolete format. You > > can use a header_checks IGNORE action to remove the offending > > header, and postfix will add it back. > > That is a better suggestion than using header_checks. However this > works only for /usr/bin/sendmail submission. I will try this, thanks. but it still seems to me that local double-bounce messages, which surely originate from Postfix, are using the legacy From header. I have put a (lightly obfuscated and shortened) example at https://pastebin.com/mVqGjAn2 which was generated while the server's internet connection was down - note the From: header.
Re: Rewrite From header from old to new style
Noel Jones: > On 10/22/2019 10:27 AM, Dominic Raferd wrote: > > On Tue, 22 Oct 2019 at 16:18, Noel Jones wrote: > >> ... > >>> I am using postfix 3.3. Apart from cron, the only other local source > >>> of such old-style headers that I can find is postfix itself: > >>> e.g. From: mailer-dae...@streamingbats.co.uk (Mail Delivery System) > >>> - maybe more recent postfix releases use the new style? > >>> > >> > >> > >> http://www.postfix.org/postconf.5.html#header_from_format > > > > Thanks Noel but I am using that (default) setting already: > > # postconf header_from_format > > header_from_format = standard > > > > I find the same behaviour in postfix 3.3.0 and 3.3.2. > > > > > Then whatever is generating the mail uses the obsolete format. You > can use a header_checks IGNORE action to remove the offending > header, and postfix will add it back. That is a better suggestion than using header_checks. However this works only for /usr/bin/sendmail submission. Wietse
Re: Rewrite From header from old to new style
On 10/22/2019 10:27 AM, Dominic Raferd wrote: On Tue, 22 Oct 2019 at 16:18, Noel Jones wrote: ... I am using postfix 3.3. Apart from cron, the only other local source of such old-style headers that I can find is postfix itself: e.g. From: mailer-dae...@streamingbats.co.uk (Mail Delivery System) - maybe more recent postfix releases use the new style? http://www.postfix.org/postconf.5.html#header_from_format Thanks Noel but I am using that (default) setting already: # postconf header_from_format header_from_format = standard I find the same behaviour in postfix 3.3.0 and 3.3.2. Then whatever is generating the mail uses the obsolete format. You can use a header_checks IGNORE action to remove the offending header, and postfix will add it back. -- Noel Jones
Re: Rewrite From header from old to new style
On Tue, 22 Oct 2019 at 16:18, Noel Jones wrote: >... > > I am using postfix 3.3. Apart from cron, the only other local source > > of such old-style headers that I can find is postfix itself: > > e.g. From: mailer-dae...@streamingbats.co.uk (Mail Delivery System) > > - maybe more recent postfix releases use the new style? > > > > > http://www.postfix.org/postconf.5.html#header_from_format Thanks Noel but I am using that (default) setting already: # postconf header_from_format header_from_format = standard I find the same behaviour in postfix 3.3.0 and 3.3.2.
Re: Rewrite From header from old to new style
On 10/22/2019 9:55 AM, Dominic Raferd wrote: I would like to rewrite an old-style header in a locally-generated mail (say by cron under Ubuntu 19.04 and earlier) e.g. From: r...@streamingbats.co.uk (Cron Daemon) to the new-style header e.g. From: Cron Daemon It must be done before milters so that it can be signed by opendkim milter after the header rewrite. canonical looks like the right tool but the examples I have seen only show it working on an address not the full header text. I am using postfix 3.3. Apart from cron, the only other local source of such old-style headers that I can find is postfix itself: e.g. From: mailer-dae...@streamingbats.co.uk (Mail Delivery System) - maybe more recent postfix releases use the new style? http://www.postfix.org/postconf.5.html#header_from_format -- Noel Jones
Re: Recipient address RESTRICTIONS are applied twice to the same e-mail with different parameters
Thanks for catching that. Setting it to: smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination solves this issue. On Tue, Oct 22, 2019 at 4:34 PM Wietse Venema wrote: > jean-christophe manciot: > > smtpd_relay_restrictions = permit_mynetworks, > >permit_sasl_authenticated, reject > > You changed this setting, and the result is that a remote system > (such as Google) will never be able to send mail to a recipient on > your server. > > This could have been immediately obvious to people who can help, > except foe all the debug logging and line wrapping. > > Wietse > -- Jean-Christophe
Re: Rewrite From header from old to new style
Dnia 22.10.2019 o godz. 15:55:45 Dominic Raferd pisze: > It must be done before milters so that it can be signed by opendkim > milter after the header rewrite. I think it's just enough to do it in the very first milter, isn't it? -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub."
Rewrite From header from old to new style
I would like to rewrite an old-style header in a locally-generated mail (say by cron under Ubuntu 19.04 and earlier) e.g. From: r...@streamingbats.co.uk (Cron Daemon) to the new-style header e.g. From: Cron Daemon It must be done before milters so that it can be signed by opendkim milter after the header rewrite. canonical looks like the right tool but the examples I have seen only show it working on an address not the full header text. I am using postfix 3.3. Apart from cron, the only other local source of such old-style headers that I can find is postfix itself: e.g. From: mailer-dae...@streamingbats.co.uk (Mail Delivery System) - maybe more recent postfix releases use the new style?
Re: Recipient address RESTRICTIONS are applied twice to the same e-mail with different parameters
jean-christophe manciot: > smtpd_relay_restrictions = permit_mynetworks, >permit_sasl_authenticated, reject You changed this setting, and the result is that a remote system (such as Google) will never be able to send mail to a recipient on your server. This could have been immediately obvious to people who can help, except foe all the debug logging and line wrapping. Wietse
Re: Recipient address RESTRICTIONS are applied twice to the same e-mail with different parameters
> > Sending > selected config lines and mangled debug log lines in an atrociously > misformatted HTML message is not it. > My request is perfectly formatted on chrome. I suppose that some "special formatting" features such as Italic that I used to differentiate the log from the rest of the text is not supported by the recipient mail system, so I'll keep that in mind to avoid any kind of gibberish with this list. The document you reference clearly states: "Please do not send your main.cf file, or 1000+ lines of postconf command output". Since my knowledge of postfix is limited, I thought that going straight to the point would be enough. However, I realize that some configuration settings might be missing here: There is no smtp proxy, but some content filtering; l hope this time no related setting is missing: content_filter = smtp-amavis:[127.0.0.1]:10024 milter_default_action = accept milter_protocol = 6 non_smtpd_milters = inet:localhost:8891 smtpd_data_restrictions = reject_unauth_pipelining smtpd_helo_restrictions = permit_mynetworks, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_unknown_helo_hostname smtpd_milters = inet:localhost:8891 smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, permit_auth_destination smtpd_reject_unlisted_recipient = yes smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject smtpd_sender_login_maps = hash:/etc/postfix/smtpd_sender_login_maps smtpd_sender_restrictions = reject_unknown_sender_domain Log: >>> START Recipient address RESTRICTIONS <<< generic_checks: name=permit_mynetworks permit_mynetworks: mail-il1-f173.google.com 209.85.166.173 match_hostname: mynetworks: mail-il1-f173.google.com ~? D.D.D.D/D match_hostaddr: mynetworks: 209.85.166.173 ~? D.D.D.D/D match_hostname: mynetworks: mail-il1-f173.google.com ~? D.D.D.D/D match_hostaddr: mynetworks: 209.85.166.173 ~? D.D.D.D/D match_list_match: mail-il1-f173.google.com: no match match_list_match: 209.85.166.173: no match generic_checks: name=permit_mynetworks status=0 generic_checks: name=permit_sasl_authenticated generic_checks: name=permit_sasl_authenticated status=0 generic_checks: name=permit_auth_destination permit_auth_destination: recipi...@example.org ctable_locate: move existing entry key sen...@gmail.com?recipi...@example.org smtpd_acl_permit: checking smtpd_log_access_permit_actions settings match_list_match: permit_auth_destination: no match smtpd_acl_permit: smtpd_log_access_permit_actions: no match generic_checks: name=permit_auth_destination status=1 >>> END Recipient address RESTRICTIONS <<< >>> START Recipient address RESTRICTIONS <<< generic_checks: name=permit_mynetworks permit_mynetworks: mail-il1-f173.google.com 209.85.166.173 match_hostname: mynetworks: mail-il1-f173.google.com ~? D.D.D.D/D match_hostaddr: mynetworks: 209.85.166.173 ~? D.D.D.D/D match_hostname: mynetworks: mail-il1-f173.google.com ~? D.D.D.D/D match_hostaddr: mynetworks: 209.85.166.173 ~? D.D.D.D/D match_list_match: mail-il1-f173.google.com: no match match_list_match: 209.85.166.173: no match generic_checks: name=permit_mynetworks status=0 generic_checks: name=permit_sasl_authenticated generic_checks: name=permit_sasl_authenticated status=0 generic_checks: name=reject NOQUEUE: reject: RCPT from mail-il1-f173.google.com[209.85.166.173]: 554 5.7.1 : Recipient address rejected: Access denied; from= to= proto=ESMTP helo= generic_checks: name=reject status=2 >>> END Recipient address RESTRICTIONS <<< On Mon, Oct 21, 2019 at 4:22 PM Bill Cole < postfixlists-070...@billmail.scconsult.com> wrote: > On 21 Oct 2019, at 10:08, jean-christophe manciot wrote: > > > Hi there, > > The context is: > > Ubuntu 19.10 > > postfix 3.4.7-1 > > > > in /etc/postfix/main.cf > > smtpd_recipient_restrictions = permit_mynetworks, > > permit_sasl_authenticated, permit_auth_destination > > > > This setting should accept the e-mail sent to my domain from > > google.com. > > Maybe. Other settings could break that. Notably, if you are using the > "SMTP proxy" filter mechanism, your log will show entires from both the > pre-filter smtpd and the post-filter smtpd. > > > > > Yet, I get in the log: > [snip of useless mangled debug logging] > > > Unless I'm missing something, this double check does not sound > > correct. > > Any suggestion? > > See http://www.postfix.org/DEBUG_README.html#mail for information about > how to document a Postfix problem so that others can help you. Sending > selected config lines and mangled debug log lines in an atrociously > misformatted HTML message is not it. > > > -- > Bill Cole >
Re: Remove duplicate header 'MIME-Version'
Wietse Venema schreef op 21-10-2019 18:10: You can remove all MIME-Version headers with the header_checks IGNORE action (header_checks has no counter). But that will almost certainly break signed messages (DKIM/DMARC). Thank you. The clients are quite outdated (which is why they don't use SES directly) and they don't sign their messages with DKIM or with DMARC. So now I remove all MIME-Version headers and the mail is accepted by SES. And there was much rejoice. Now I will try to convince the senders to fix their application. Regards, Lucas
Re: Use of PERMIT in smtpd restriction lists
On Tue, 22 Oct 2019 at 12:04, Wietse Venema wrote: > Dominic Raferd: > > By (limited) experiment it seems to me that the action 'PERMIT' is > > acceptable in access tables in smtpd restriction lists (e.g. > > smtpd_client_restrictions). > > > > As far as I can tell it is undocumented in this context, but I think it > is > > The 'permit' action is documented in the access(5) manpage > in the section 'OTHER ACTIONS'. > > $ man 5 access | less '+/^OTHER ACTIONS' > OTHER ACTIONS >restriction... > Applythe named UCE restriction(s) (permit, > reject, > reject_unauth_destination, and so on). > >BCC user@domain > ... > > Note the action name is case-insensitive, thus PERMIT is the same > as permit. > Thanks Wietse for pointing that out. I believe it confirms my understanding.
Re: Use of PERMIT in smtpd restriction lists
Dominic Raferd: > By (limited) experiment it seems to me that the action 'PERMIT' is > acceptable in access tables in smtpd restriction lists (e.g. > smtpd_client_restrictions). > > As far as I can tell it is undocumented in this context, but I think it is The 'permit' action is documented in the access(5) manpage in the section 'OTHER ACTIONS'. $ man 5 access | less '+/^OTHER ACTIONS' OTHER ACTIONS restriction... Applythe named UCE restriction(s) (permit, reject, reject_unauth_destination, and so on). BCC user@domain ... Note the action name is case-insensitive, thus PERMIT is the same as permit. Wietse
Use of PERMIT in smtpd restriction lists
By (limited) experiment it seems to me that the action 'PERMIT' is acceptable in access tables in smtpd restriction lists (e.g. smtpd_client_restrictions). As far as I can tell it is undocumented in this context, but I think it is synonymous with 'OK' i.e. any subsequent tests in the same restriction list are skipped/ignored but subsequent restriction lists are processed (and could indeed give a REJECT action). One practical advantage of using PERMIT instead of OK: a single ip whitelist file can then be used both in postscreen_access_list (where the action 'OK' is not acceptable) and in an smtpd restriction list. Is this correct - or incorrect / unwise?
