Re: match empty sender in hash: sender access map?

On 12.04.22 23:06, Greg Klanderman wrote: Thank you Bill! Knowing that now, I see where postmap(1) states: | The postmap(1) command can query any supported file type, but it can | create only the following file types: | ... [types not including 'regexp' or 'pcre'] Also, the error if you

Re: match empty sender in hash: sender access map?

On Thu, Apr 14, 2022 at 01:22:03AM -0400, Viktor Dukhovni wrote: > On Thu, Apr 14, 2022 at 12:25:11AM -0400, Greg Klanderman wrote: > > > > This is naturally documented in access(5), and also in postconf(5) > > > under: > > > > > > smtpd_null_access_lookup_key (default: <>) > > >

Re: match empty sender in hash: sender access map?

On Thu, Apr 14, 2022 at 12:25:11AM -0400, Greg Klanderman wrote: > > This is naturally documented in access(5), and also in postconf(5) > > under: > > > > smtpd_null_access_lookup_key (default: <>) > >The lookup key to be used in SMTP access(5) tables instead of the > >null

Re: match empty sender in hash: sender access map?

>>>>> On April 10, 2022 Viktor Dukhovni wrote: > On Sun, Apr 10, 2022 at 02:27:33PM -0400, Greg Klanderman wrote: >> Quick question, what is the correct syntax to match an empty sender in >> a hash: sender access map (i.e. check_sender_access)? > This is

Re: match empty sender in hash: sender access map?

> On April 13, 2022 Matus UHLAR <- fantomas > wrote: >>> On April 10, 2022 Bill Cole >>> wrote: >>> Right, because you do not need to run 'postmap' on regex or pcre maps. The >>> text >>> format ios what Postfix uses for those types. > On 12.04.22 23:06, Greg Klanderman wrote: >>

Re: match empty sender in hash: sender access map?

On April 10, 2022 Bill Cole wrote: Right, because you do not need to run 'postmap' on regex or pcre maps. The text format ios what Postfix uses for those types. On 12.04.22 23:06, Greg Klanderman wrote: Thank you Bill! Knowing that now, I see where postmap(1) states: | The postmap(1)

Re: match empty sender in hash: sender access map?

> On April 10, 2022 Bill Cole > wrote: > Right, because you do not need to run 'postmap' on regex or pcre maps. The > text > format ios what Postfix uses for those types. Thank you Bill! Knowing that now, I see where postmap(1) states: | The postmap(1) command can query any

Re: match empty sender in hash: sender access map?

On Sun, Apr 10, 2022 at 02:27:33PM -0400, Greg Klanderman wrote: > Quick question, what is the correct syntax to match an empty sender in > a hash: sender access map (i.e. check_sender_access)? This is naturally documented in access(5), and also in postconf(5)

Re: match empty sender in hash: sender access map?

On 2022-04-10 at 14:27:33 UTC-0400 (Sun, 10 Apr 2022 14:27:33 -0400) Greg Klanderman is rumored to have said: Hi all, Quick question, what is the correct syntax to match an empty sender in a hash: sender access map (i.e. check_sender_access)? Somewhat related, if I have a regexp: map (header

match empty sender in hash: sender access map?

Hi all, Quick question, what is the correct syntax to match an empty sender in a hash: sender access map (i.e. check_sender_access)? Somewhat related, if I have a regexp: map (header checks), like so: /^Subject:.*foo bar/ REJECT /^Subject:.*foo baz/ REJECT when it is postmap'd, it warns

Re: PATCH: Access map matches sub domain with empty parent_domain_matches_subdomains

Henrik Larsson: > > That always sets MA_FIND_PDMS and therefore always matches the > > subdomain. Corrected patch follows. > > I have tested the new patch, and that works for my use case as well. > > In both cases, the recipient using a subdomain of the a

Re: PATCH: Access map matches sub domain with empty parent_domain_matches_subdomains

That always sets MA_FIND_PDMS and therefore always matches the subdomain. Corrected patch follows. I have tested the new patch, and that works for my use case as well. In both cases, the recipient using a subdomain of the access map was blocked. Best regards Henrik Larsson

Re: PATCH: Access map matches sub domain with empty parent_domain_matches_subdomains

> -#define LOOKUP_STRATEGY (MA_FIND_FULL | MA_FIND_NOEXT | MA_FIND_DOMAIN \ > - | MA_FIND_PDMS | MA_FIND_LOCALPART_AT) > +lookup_strategy = MA_FIND_FULL | MA_FIND_NOEXT | MA_FIND_DOMAIN > + | MA_FIND_PDMS | MA_FIND_LOCALPART_AT > + | (access_parent_style ==

Re: PATCH: Access map matches sub domain with empty parent_domain_matches_subdomains

Patch follows. Add the lines with '+', remove lines with '-'. Patch builds and seem to fix my use case. Thanks a lot. Best regards Henrik Larsson

PATCH: Access map matches sub domain with empty parent_domain_matches_subdomains

Henrik Larsson: > I'm using Postfix 3.2.0 from the FreeBSD ports collection > > I experienced that access maps matches sub domains, even though > parent_domain_matches_subdomains is set to an empty value. > > What did I miss? I only want the access map to match specific

Access map matches sub domain with empty parent_domain_matches_subdomains

I'm using Postfix 3.2.0 from the FreeBSD ports collection I experienced that access maps matches sub domains, even though parent_domain_matches_subdomains is set to an empty value. What did I miss? I only want the access map to match specific domain, not sub domains. The log show

Re: postfix access map

On 20.02.2017 17:54, Viktor Dukhovni wrote: On Feb 20, 2017, at 4:31 AM, Admin Beckspaced wrote: I always had the impression that an OK will skip all further tests in any restrictions lists following. I now added in smtpd_recipient_restrictions before the RBL checks

Re: postfix access map

> On Feb 20, 2017, at 4:31 AM, Admin Beckspaced wrote: > > I always had the impression that an OK will skip all further tests in any > restrictions lists following. > > I now added in smtpd_recipient_restrictions before the RBL checks > > check_sender_access

Re: postfix access map

nd: I'm running Postfix version 2.11.6 and have setup an access map of sender email addresses someu...@somedomain.com <mailto:someu...@somedomain.com> OK then doing a postmap on the access map and in the main.cf <http://main.cf> I setup the following: s

Re: postfix access map

On 20 February 2017 at 07:58, Admin Beckspaced <ad...@beckspaced.com> wrote: > Dear Postfix users, > > First a belated BIG THANK YOU to Wietse and his 20 years of Postfix. > You're awesome! > > Second: > > I'm running Postfix version 2.11.6 and have setup an access m

postfix access map

Dear Postfix users, First a belated BIG THANK YOU to Wietse and his 20 years of Postfix. You're awesome! Second: I'm running Postfix version 2.11.6 and have setup an access map of sender email addresses someu...@somedomain.com OK then doing a postmap on the access map and in the main.cf

Re: access map fallthrough - prevent lookup of IP address

Roel van Meer writes: I was wondering if it is possible to return something (other than OK) on the first pass, so the second lookup does not happen? So, something like DUNNO, that prevents further lookups in the same map, and immediately continues in the next map. Ok, this is exactly

access map fallthrough - prevent lookup of IP address

Hi list! I'm trying to do some complicated things with a postfix access map, of the regexp type: ... check_client_access regexp:/etc/postfix/maps/client.regexp ... When a connection is made, first the client hostname and then the client IP address are looked up in the map

Re: Static WARN action without an (external) access-map in i.e. restriction_class possible?

On 11/16/2015 04:54 PM, Wietse Venema wrote: > With Postfix 3.0 or later: > >... check_client_access static:{warn text...} ... > > Older Postfix releases require that the lookup result is stored > outside main.cf. > > (Postfix 3.0 also introduces inline: tables whose keys and values > are

Re: Static WARN action without an (external) access-map in i.e. restriction_class possible?

Christian Rohmann: > Hey postfix-users, > > I am afraid I have a hopefully simple configuration style question: > > I set up a restriction class. Every connection/sending attempt that goes > into this somewhat trapping class via an access-map, naturally. > > Now I

Static WARN action without an (external) access-map in i.e. restriction_class possible?

Hey postfix-users, I am afraid I have a hopefully simple configuration style question: I set up a restriction class. Every connection/sending attempt that goes into this somewhat trapping class via an access-map, naturally. Now I would love to log a warn or info message to the log file whenever

Re: Is it possible to stack access map actions + use a custom reject message?

deoren: The question I had would have been better phrased as, Is there a way to limit which clients can claim to be from your domain(s) when sending mail? After doing some additional digging it looks like Envelope sender address authorization is what I'm looking for?

Is it possible to stack access map actions + use a custom reject message?

I was reading through Linux Email and it has an example policy where only clients from your networks are allowed to use your domain in the sender address: smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/sender_access # /etc/postfix/sender_access example.com permit_mynetworks,

Re: Is it possible to stack access map actions + use a custom reject message?

deoren: permit_mynetworks, REJECT Unauthorized use of domain name Where does the Postfix documentation promise that you can do this? Wietse

Re: Is it possible to stack access map actions + use a custom reject message?

On November 22, 2014 10:22:12 AM CST, wie...@porcupine.org wrote: deoren: permit_mynetworks, REJECT Unauthorized use of domain name Where does the Postfix documentation promise that you can do this? Wietse Thanks for the reply. I know you are a busy guy and I appreciate the direct

Re: Is it possible to stack access map actions + use a custom reject message?

deoren: Is there a way to accomplish what the Linux Email book mentions? Basically restricting use of your domain to your clients/backup MX and using a custom response or log message to indicate what rule blocked offenders? /etc/postfix/main.cf: smtpd_client_restrictions =

Re: Is it possible to stack access map actions + use a custom reject message?

On 11/22/2014 6:03 PM, Wietse Venema wrote: deoren: Is there a way to accomplish what the Linux Email book mentions? Basically restricting use of your domain to your clients/backup MX and using a custom response or log message to indicate what rule blocked offenders? /etc/postfix/main.cf:

Re: postfix access map for sasl authenticated users

Otherwise, postfwd and the like could be configured for a rate limit of zero (can't send mail). Sorry, for the late answer, but no zero rate limits are required here. With postfwd simply use: id=SASLDROP sasl_username==barrak sasl_username==vladimir sasl_username==mao

Re: PATCH: access map for sasl authenticated users

On 10/29/2013 01:11 AM, Wietse Venema wrote: . I have a patch that should also work with other Postfix releases at ftp://ftp.porcupine.org/mirrors/postfix-release/experimental/feature-patches/20131028-check-sasl-access-patch I saw there was a newer one

Re: PATCH: access map for sasl authenticated users

Rudy Gevaert: On 10/29/2013 01:11 AM, Wietse Venema wrote: I have a patch that should also work with other Postfix releases at ftp://ftp.porcupine.org/mirrors/postfix-release/experimental/feature-patches/20131028-check-sasl-access-patch I saw there was a newer one

Re: postfix access map for sasl authenticated users

Quoting wie...@porcupine.org (Wietse Venema), Fri, 25 Oct 2013: Rudy Gevaert: Hello, I was wondering if I could add a access map (to deny access in fact) for specific sasl authenticated users? Adding check_sasl_sender_access support would not be difficult. It just hasn't been done yet

Re: postfix access map for sasl authenticated users

. However because of the current setup, we can't only disable smtp auth. Having an extra sender access map would have helped :) Here is just another workaround. Simply reject a given MAIL FROM address with 'check_sender_access', but make sure SASL authenticated users can't choose any arbitrary

PATCH: access map for sasl authenticated users

Wietse Venema: Rudy Gevaert: Hello, I was wondering if I could add a access map (to deny access in fact) for specific sasl authenticated users? Adding check_sasl_sender_access support would not be difficult. It just hasn't been done yet. Well, it's done now. check_sasl_access

Re: postfix access map for sasl authenticated users

On 10/25/2013 04:44 PM, Rudy Gevaert wrote: Hello, I was wondering if I could add a access map (to deny access in fact) for specific sasl authenticated users? E.g. even if the login succeeds that user can't send email. I couldn't find anything in the docs, but maybe I'm looking

postfix access map for sasl authenticated users

Hello, I was wondering if I could add a access map (to deny access in fact) for specific sasl authenticated users? E.g. even if the login succeeds that user can't send email. I couldn't find anything in the docs, but maybe I'm looking in the wrong place. Thanks, Rudy

Re: postfix access map for sasl authenticated users

Rudy Gevaert skrev den 2013-10-25 16:44: I was wondering if I could add a access map (to deny access in fact) for specific sasl authenticated users? remove users is not solution ?

Re: postfix access map for sasl authenticated users

Rudy Gevaert: Hello, I was wondering if I could add a access map (to deny access in fact) for specific sasl authenticated users? Adding check_sasl_sender_access support would not be difficult. It just hasn't been done yet. E.g. even if the login succeeds that user can't send email. You

access map as smtpd_sender_restrictions value

Hi list, I've noticed that the syntax: smtpd_sender_restrictions = pcre:/etc/postfix/sender_access is valid, and by all means as effective as: smtpd_sender_restrictions = check_sender_access pcre:/etc/postfix/sender_access I couldn't find this syntax in the documentation, would you please

Re: access map as smtpd_sender_restrictions value

On Fri, Aug 30, 2013 at 06:52:52PM +0200, Fabio Sangiovanni wrote: I've noticed that the syntax: smtpd_sender_restrictions = pcre:/etc/postfix/sender_access is valid, and by all means as effective as: smtpd_sender_restrictions = check_sender_access pcre:/etc/postfix/sender_access

Re: access map as smtpd_sender_restrictions value

Viktor Dukhovni postfix-users at dukhovni.org writes: On Fri, Aug 30, 2013 at 06:52:52PM +0200, Fabio Sangiovanni wrote: I've noticed that the syntax: smtpd_sender_restrictions = pcre:/etc/postfix/sender_access is valid, and by all means as effective as:

Re: Access Map

Zitat von DN Singh dnsingh@gmail.com: Hello group, I was configuring some restrictions on the Postfix level using access map. It is in has format. It is has a pretty good number of domains in it. So, I was wondering, how large can be the file, without affecting the performance

Access Map

Hello group, I was configuring some restrictions on the Postfix level using access map. It is in has format. It is has a pretty good number of domains in it. So, I was wondering, how large can be the file, without affecting the performance? These are configured in recipient restrictions, so

Re: PCRE access map mistake

On 09/24/10 01:10, Sahil Tandon wrote: On Thu, 2010-09-23 at 21:37:40 -0400, Michael Orlitzky wrote: check_client_access pcre:/fudged/generic_rbl_clients.pcre, The content of generic_rbl_clients.pcre: # sutton-partners.com /^64\.191\.79\.245$/public_rbls # mabel.ca

Re: PCRE access map mistake

Michael Orlitzky put forth on 9/24/2010 2:37 AM: Ok, I see what's going on. 'unknown' gets looked up first, and so /./ matches it before the client IP address gets looked up. Wouldn't check_reverse_client_hostname_access suffer the same fate? I think switching to a CIDR map probably avoids

Re: PCRE access map mistake

Sahil Tandon put forth on 9/24/2010 12:10 AM: Sep 23 10:05:42 mx1 postfix/smtpd[12164]: connect from unknown[64.191.79.245] ^^^ Nice catch Sahil. I'd momentarily forgotten the fact that check_client_access goes after rdns host name as well as IP. -- Stan

Re: PCRE access map mistake

Michael Orlitzky put forth on 9/23/2010 8:37 PM: # sutton-partners.com /^64\.191\.79\.245$/public_rbls # mabel.ca /^70\.38\.108\.42$/ public_rbls # dsnews.com /^209\.172\.40\.21[157]$/ public_rbls Should the carat and dollar be there? I just

Re: PCRE access map mistake

On Fri, 2010-09-24 at 03:37:22 -0400, Michael Orlitzky wrote: # sutton-partners.com /^64\.191\.79\.245$/public_rbls # Default: check these lists. # /./ all_rbls However, 64.191.79.245 is still being subjected to the private RBL

Re: PCRE access map mistake

On Fri, 2010-09-24 at 05:31:15 -0500, Stan Hoeppner wrote: Michael Orlitzky put forth on 9/23/2010 8:37 PM: # sutton-partners.com /^64\.191\.79\.245$/public_rbls # mabel.ca /^70\.38\.108\.42$/ public_rbls # dsnews.com

Re: PCRE access map mistake

On 9/24/2010 2:37 AM, Michael Orlitzky wrote: On 09/24/10 01:10, Sahil Tandon wrote: On Thu, 2010-09-23 at 21:37:40 -0400, Michael Orlitzky wrote: check_client_access pcre:/fudged/generic_rbl_clients.pcre, The content of generic_rbl_clients.pcre: # sutton-partners.com

Re: PCRE access map mistake

On Sep 24, 2010, at 8:43 AM, Noel Jones njo...@megan.vbhcs.org wrote: On 9/24/2010 2:37 AM, Michael Orlitzky wrote: On 09/24/10 01:10, Sahil Tandon wrote: On Thu, 2010-09-23 at 21:37:40 -0400, Michael Orlitzky wrote: check_client_access pcre:/fudged/generic_rbl_clients.pcre, The content

Re: PCRE access map mistake

Sahil Tandon put forth on 9/24/2010 7:12 AM: On Fri, 2010-09-24 at 05:31:15 -0500, Stan Hoeppner wrote: Michael Orlitzky put forth on 9/23/2010 8:37 PM: # sutton-partners.com /^64\.191\.79\.245$/public_rbls # mabel.ca /^70\.38\.108\.42$/ public_rbls #

Re: PCRE access map mistake

Noel Jones put forth on 9/24/2010 7:43 AM: Stan Hoeppner wrote: /\[([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})\]/ all_rbls It only matches on a dotted quad enclosed in []. It won't match on the rdns name, or lack thereof (unknown). No, the table is searched twice; first with

Re: PCRE access map mistake

On 09/24/10 10:41, Stan Hoeppner wrote: Sahil Tandon put forth on 9/24/2010 7:12 AM: On Fri, 2010-09-24 at 05:31:15 -0500, Stan Hoeppner wrote: Michael Orlitzky put forth on 9/23/2010 8:37 PM: # sutton-partners.com /^64\.191\.79\.245$/public_rbls # mabel.ca

Re: PCRE access map mistake

Stan Hoeppner: Noel Jones put forth on 9/24/2010 7:43 AM: Stan Hoeppner wrote: /\[([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})\]/ all_rbls It only matches on a dotted quad enclosed in []. It won't match on the rdns name, or lack thereof (unknown). No, the table is

Re: PCRE access map mistake

Michael Orlitzky mich...@orlitzky.com wrote: On 09/24/10 10:41, Stan Hoeppner wrote: Sahil Tandon put forth on 9/24/2010 7:12 AM: On Fri, 2010-09-24 at 05:31:15 -0500, Stan Hoeppner wrote: Michael Orlitzky put forth on 9/23/2010 8:37 PM: # sutton-partners.com /^64\.191\.79\.245$/

PCRE access map mistake

We run a private RBL, jerks.viabit.com, and check against it as well as four other lists at SMTP time. Occasionally, I'll get a false positive due to blocking an entire /24 and want to whitelist them from our private RBL check but not against e.g. Spamhaus. I'm doing something wrong w.r.t.

Re: PCRE access map mistake

I don't see your master.cf here. In a setup like this I'd assume you may be running more than one smtpd for submission. master.cf settings can override main.cf settings. This might explain why you're seeing behavior different than what main.cf says you should be seeing. Please post master.cf.

Re: PCRE access map mistake

On 09/23/10 21:55, Stan Hoeppner wrote: I don't see your master.cf here. In a setup like this I'd assume you may be running more than one smtpd for submission. master.cf settings can override main.cf settings. This might explain why you're seeing behavior different than what main.cf says

Re: PCRE access map mistake

I don't see anything in master.cf either. Hmmm Wait a second. My lack of regex foo may be showing. :) The content of generic_rbl_clients.pcre: # sutton-partners.com /^64\.191\.79\.245$/public_rbls # mabel.ca /^70\.38\.108\.42$/ public_rbls # dsnews.com

Re: PCRE access map mistake

On 09/23/10 22:29, Stan Hoeppner wrote: I don't see anything in master.cf either. Hmmm Wait a second. My lack of regex foo may be showing. :) The content of generic_rbl_clients.pcre: # sutton-partners.com /^64\.191\.79\.245$/public_rbls # mabel.ca

Re: PCRE access map mistake

Michael Orlitzky put forth on 9/23/2010 9:44 PM: Alternatively, lookup tables can be specified in Perl Compatible Regu- lar Expression form. In this case, each input is compared against a list of patterns. When a match is found, the corresponding result is returned and the search is

Re: PCRE access map mistake

Michael Orlitzky September 23, 2010 9:37 PM We run a private RBL, jerks.viabit.com, and check against it as well as four other lists at SMTP time. Occasionally, I'll get a false positive due to blocking an entire /24 and want to whitelist them from our private RBL check but not against e.g.

Re: PCRE access map mistake

On Thu, 2010-09-23 at 21:37:40 -0400, Michael Orlitzky wrote: check_client_access pcre:/fudged/generic_rbl_clients.pcre, The content of generic_rbl_clients.pcre: # sutton-partners.com /^64\.191\.79\.245$/public_rbls # mabel.ca /^70\.38\.108\.42$/

Re: how to specify any/catch_all domain/email in HASH access map?

[EMAIL PROTECTED] a écrit : How to implement logic like below in one HASH map? pcre:/etc/postfix/maps/check_client: /mail\.ru/ DUNNO I guess you mean /mail\.ru$/ DUNNO otherwise, the expression matches mail.ruby.org and other stuff... /yandex\.ru/ DUNNO same as above. /.*/

how to specify any/catch_all domain/email in HASH access map?

How to implement logic like below in one HASH map? pcre:/etc/postfix/maps/check_client: /mail\.ru/ DUNNO /yandex\.ru/ DUNNO /.*/ goto_check_class Thanks.

Re[2]: how to specify any/catch_all domain/email in HASH access map?

To: postfix-users@postfix.org Subject: how to specify any/catch_all domain/email in HASH access map? For example in this hash I wanna OK for all domains except mail.ru and yandex.ru: hash:/etc/postfix/maps/check_sender: mail.ru REJECT yandex.ru REJECT all other OK So what I

Re: how to specify any/catch_all domain/email in HASH access map?

Please do not top post: http://en.wikipedia.org/wiki/Posting_style http://www.caliburn.nl/topposting.html http://mailformat.dan.info/quoting/top-posting.html [EMAIL PROTECTED] wrote: Actually I wanna selective rbl checks. - doctor, I want meds for my stomatch - take this, that, ... - oh

how to specify any/catch_all domain/email in HASH access map?

For example in this hash I wanna OK for all domains except mail.ru and yandex.ru: hash:/etc/postfix/maps/check_sender: mail.ru REJECT yandex.ru REJECT all other OK So what I must write insteed of all other? Maybe . (single point)? Thanks.

FW: how to specify any/catch_all domain/email in HASH access map?

-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, 8 October 2008 2:12 PM To: postfix-users@postfix.org Subject: how to specify any/catch_all domain/email in HASH access map? For example in this hash I

Re: how to specify any/catch_all domain/email in HASH access map?

[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: For example in this hash I wanna OK for all domains except mail.ru and yandex.ru: hash:/etc/postfix/maps/check_sender: No, you do not want an OK for all domains except those two. You want a DUNNO, which is the default; so just REJECT those domains.