Re: Assist with a spam message, check_sender_access and check_client_access targets

Wietse Venema: > Viktor Dukhovni: > > On Sat, Jan 21, 2023 at 02:49:34PM -0500, Wietse Venema wrote: > > > > > Correction: the MTA<==>Milter protocol hides the Received: header > > > that is prepended by the MTA, but it exposes headers that are already > > > present. That's what Sendmail does,

Re: Assist with a spam message, check_sender_access and check_client_access targets

Viktor Dukhovni: > On Sat, Jan 21, 2023 at 02:49:34PM -0500, Wietse Venema wrote: > > > Correction: the MTA<==>Milter protocol hides the Received: header > > that is prepended by the MTA, but it exposes headers that are already > > present. That's what Sendmail does, and therefore Postfix, too. >

Re: Assist with a spam message, check_sender_access and check_client_access targets

On Sat, Jan 21, 2023 at 02:49:34PM -0500, Wietse Venema wrote: > Correction: the MTA<==>Milter protocol hides the Received: header > that is prepended by the MTA, but it exposes headers that are already > present. That's what Sendmail does, and therefore Postfix, too. Not only does Sendmail do

Re: Assist with a spam message, check_sender_access and check_client_access targets

Bill Cole: > What is likely happening here is that when a milter sees a message, it > does not have the current Received header, because it has yet to be > fully received. If you are extracting this message from that stage > rather than after final delivery, Postfix has not yet added the

RE: Assist with a spam message, check_sender_access and check_client_access targets

>> No idea what's stripping them. I use amavisd and spamassassin, the >> later I expect. > >Nope. ASF SpamAssassin does not manipulate existing headers in any way >except for pre-existing X-Spam-* headers that it is specifically >configured to remove. When used via amavisd or MIMEDefang or any

Re: Assist with a spam message, check_sender_access and check_client_access targets

in a check_client_access map. No idea what's stripping them. I use amavisd and spamassassin, the later I expect. Nope. ASF SpamAssassin does not manipulate existing headers in any way except for pre-existing X-Spam-* headers that it is specifically configured to remove. When used via amavisd

Re: Assist with a spam message, check_sender_access and check_client_access targets

Dnia 20.01.2023 o godz. 15:25:56 Scott Techlist pisze: > X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on > myhost.myservername.com > X-Virus-Scanned: amavisd-new at myservername.com > X-Spam-Flag: NO > X-Spam-Score: 1.451 > X-Spam-Level: * > X-Spam-Status: No, score=1.451

RE: Assist with a spam message, check_sender_access and check_client_access targets

Re: Raf >In other words, check_sender_access tests the address >that ended up being stored in the From_ mbox pseudo header: > > From > bounce-91040_html-994996332-142678-514026815-45...@bounce.s11.mc.pd25.com > Fri Jan 20 12:40:11 2023 > >And check_client_access d

Re: Assist with a spam message, check_sender_access and check_client_access targets

On Fri, Jan 20, 2023 at 03:53:25PM -0600, Noel Jones wrote: > On 1/20/2023 3:25 PM, Scott Techlist wrote: > > I'm fuzzy on if I can block a message like the one below one using > > check_sender_access or check_client_access. > > check_sender_access is the envelope sender

Re: check_client_access

On Sat, 30 Apr 2022 01:11:05 -0400 Viktor Dukhovni wrote: > On Sat, Apr 30, 2022 at 10:28:06AM +1000, raf wrote: > > > > .domain.tld > > > > > > Matches subdomains of domain.tld, but only when the > > > string smtpd_access_maps is not listed in the Postfix > > >

Re: check_client_access

On Sat, Apr 30, 2022 at 08:55:54PM +1000, raf wrote: > Ah yes, and access(5) says .domain.tld only matches > subdomains when smtpd_access_maps is not in > parent_domain_matches_subdomains, but it is there by > default, so ".domain.tld" wouldn't work at all. It > needs to be "domain.tld". I

Re: check_client_access

On Sat, Apr 30, 2022 at 01:11:05AM -0400, Viktor Dukhovni wrote: > On Sat, Apr 30, 2022 at 10:28:06AM +1000, raf wrote: > > > > .domain.tld > > > > > > Matches subdomains of domain.tld, but only when the > > > string smtpd_access_maps is not listed in the Postfix > > >

Re: check_client_access

On Sat, Apr 30, 2022 at 10:28:06AM +1000, raf wrote: > > .domain.tld > > > > Matches subdomains of domain.tld, but only when the > > string smtpd_access_maps is not listed in the Postfix > > parent_domain_matches_subdomains configuration setting. > > The .domain.tld notation only covers a single

Re: check_client_access

On Fri, Apr 29, 2022 at 04:47:51PM -0700, "li...@lazygranch.com" wrote: > I'm trying to allow-list (formerly whitelist) a TLD. I have these lines > in my postfix main.cf: > > check_client_access hash:/etc/postfix/client_checks, > check_sender_access hash:/

check_client_access

I'm trying to allow-list (formerly whitelist) a TLD. I have these lines in my postfix main.cf: check_client_access hash:/etc/postfix/client_checks, check_sender_access hash:/etc/postfix/sender_checks, check_client_access hash:/etc/postfix/rbl_override, For the rbl_override file

Re: Domain not being blocked in check_client_access

access  regexp:/etc/postfix/senderaccess         check_client_access     hash:/etc/postfix/sender_reject_domain check_client_access is for checking the client domain name or IP. You probably want check_sender_access to check the MAIL FROM address.         check_client_access     cidr:/etc/p

Re: Domain not being blocked in check_client_access

check_client_access hash:/etc/postfix/sender_reject_domain check_client_access cidr:/etc/postfix/sender_reject_ip check_recipient_access hash:/etc/postfix/sender_reject_invalid check_client_access acts on the valid hostname or IP address of thge connecting SMTP

Re: check_client_access not blocking /8 /16 /24 etc.

it. main.cf. smtpd_recipient_restrictions =       permit_mynetworks,       permit_sasl_authenticated,       check_client_access hash:/etc/postfix/client_checks.cf, [...] client_checks.cf. 5.0.0.0/8 REJECT We have not seen your IP Address before.  Please visit https://example.com?newip

Re: check_client_access not blocking /8 /16 /24 etc.

Philip skrev den 2018-07-11 04:24: check_client_access hash:/etc/postfix/client_checks.cf, change hash here to cidr 5.0.0.0/8 REJECT We have not seen your IP Address before.  Please visit https://example.com?newip=5.0.0.0/8 to unblock your IP and remember cidr does not need

check_client_access not blocking /8 /16 /24 etc.

,       permit_sasl_authenticated,       check_client_access hash:/etc/postfix/client_checks.cf,       check_sender_access hash:/etc/postfix/sender_checks.cf,       reject_unlisted_sender,       reject_unauth_pipelining,       reject_unauth_destination,   reject_rbl_client bl.spamcop.net

Re: check_client_access won't check hostname.

> On Sep 12, 2016, at 12:54 AM, Jeremy wrote: > > Sep 12 15:36:58 mailsrv postfix/smtpd[30413]: connect from > unknown[210.246.XX.XX] > *** > Sep 12 15:37:32 mailsrv postfix/smtpd[30413]: NOQUEUE: reject: RCPT from > unknown[210.246.XX.XX]: 554 5.7.1

check_client_access won't check hostname.

Hi I'm administering an old server using Postfix v2.5.6 and have trouble with a "check_client_access" rule. I'm trying to whitelist another system (operating on a dynamic IP address which is blocked by an RBL) by including its domain in a hash table. I have access to both syste

Re: check_client_access cidr - Performance concerns ?

list...@tutanota.com: > 23. May 2016 18:48 by njo...@megan.vbhcs.org: > > > Yes, exactly right idea, but your expressions could use some improvement > > Thanks it helped! > > >IF /^(To|From|Cc|Reply-To): / Why not: /^(To|From|Cc|Reply-To): *(addr1|addr2|addr3)/ > Is the space between ":

Re: check_client_access cidr - Performance concerns ?

23. May 2016 18:48 by njo...@megan.vbhcs.org: > Yes, exactly right idea, but your expressions could use some improvement Thanks it helped! >IF /^(To|From|Cc|Reply-To): / Is the space between ": /" always needed? I think yes.  

Re: check_client_access cidr - Performance concerns ?

On 5/23/2016 5:55 PM, list...@tutanota.com wrote: > I noticed this email today about IF ... ENDIF. > > I didnt know about it yet so I have been reading and looking at > examples. > > I can understand some but not all yet. The examples with matching > on just an IP or CIDR are easy to see. > >

Re: check_client_access cidr - Performance concerns ?

I noticed this email today about IF ... ENDIF. I didnt know about it yet so I have been reading and looking at examples. I can understand some but not all yet.  The examples with matching on just an IP or CIDR are easy to see. But can IF ... ENDIF in Postfix be used to make this .pcre

Re: check_client_access cidr - Performance concerns ?

Viktor Dukhovni: > On Fri, May 20, 2016 at 03:24:26PM -0400, Wietse Venema wrote: > > > I can do a little better than thats, and also give a number for the > > per-query overhead. With this i5-650 CPU @3.2GHZ, it takes 0.92 > > seconds to parse 1 million IPv4 patterns, and less than about 0.01 >

Re: check_client_access cidr - Performance concerns ?

On Fri, May 20, 2016 at 03:24:26PM -0400, Wietse Venema wrote: > I can do a little better than thats, and also give a number for the > per-query overhead. With this i5-650 CPU @3.2GHZ, it takes 0.92 > seconds to parse 1 million IPv4 patterns, and less than about 0.01 > second to search through

Re: check_client_access cidr - Performance concerns ?

Wietse Venema: > To measure [cidr map] initialization overhead, look at the difference between > > $ time postmap -q /dev/null static:foo > $ time postmap -q /dev/null pcre:yourfile > > You will probably have to run this several times to get a meaningful > result. The /dev/null can be

Re: check_client_access cidr - Performance concerns ?

> On May 20, 2016, at 1:42 PM, Noel Jones wrote: > > The cidr: map is quite efficient. > > IIRC the last time someone performance tested the cidr: map type, > performance stayed high even with 10's of thousands of entries. (or > was it 100's of thousands?? whatever...

Re: check_client_access cidr - Performance concerns ?

Brandon Applegate: > In any case - I've been wondering about the potential performance > impact related to the size of the cidr_client_checks file. I > currently have ~ 600 networks listed there. I haven't noticed > anything yet - but would like to know if there's a size where I > should worry.

Re: check_client_access cidr - Performance concerns ?

On 5/20/2016 11:20 AM, Brandon Applegate wrote: > Hello all, > > In my cascade of smtpd restrictions, along with RBL, rDNS etc - I have: > > check_client_access cidr:/etc/postfix/cidr_client_checks > > I mainly (manually) throw egregious offenders in there that haven’t

check_client_access cidr - Performance concerns ?

Hello all, In my cascade of smtpd restrictions, along with RBL, rDNS etc - I have: check_client_access cidr:/etc/postfix/cidr_client_checks I mainly (manually) throw egregious offenders in there that haven’t been added to one of the RBLs yet. In any case - I’ve been wondering about

Re: check_client_access before reject_unknown_client_hostname in smtpd_client_restrictions block

User Nexus: I've found the answer on my questions in the official Postfix documentation. Feel free to skip answering on this email. Thanks again. There still is hope for humanity. Wietse

Re: check_client_access before reject_unknown_client_hostname in smtpd_client_restrictions block

bellow: smtpd_client_restrictions = permit_mynetworks, check_client_access hash:/etc/postfix/access reject_unknown_client_hostname, reject_unauth_destination

Re: check_client_access before reject_unknown_client_hostname in smtpd_client_restrictions block

= permit_mynetworks, check_client_access hash:/etc/postfix/access reject_unknown_client_hostname, reject_unauth_destination, reject_invalid_hostname

Re: check_client_access before reject_unknown_client_hostname in smtpd_client_restrictions block

User Nexus: My question now, is it correct to use 'check_sender_access' in 'smtpd_client_restrictions' section? smtpd_client_restrictions (default: empty) ... Other restrictions that are valid in this context: o SMTP command specific restrictions that are described

Re: check_client_access before reject_unknown_client_hostname in smtpd_client_restrictions block

, check_client_access hash:/etc/postfix/access reject_unknown_client_hostname, reject_unauth_destination, reject_invalid_hostname, reject_unauth_pipelining,reject_non_fqdn_sender

check_client_access before reject_unknown_client_hostname in smtpd_client_restrictions block

Hello Guys, I'm trying to set up some restrictions in 'smtpd_client_restrictions' Postfix config block. You can see my 'smtpd_client_restrictions' block bellow: smtpd_client_restrictions = permit_mynetworks, check_client_access hash:/etc

looks like smtpd_recipient_restrictions check_client_access is being ignored ?

, check_client_access hash:/etc/postfix-in/pop-before-smtp reject_unauth_destination Judging by a trace, it looks like check_client_access is being ignored? smtpd[20213]: START Recipient address RESTRICTIONS smtpd[20213]: generic_checks: name=permit_mynetworks smtpd[20213

Re: looks like smtpd_recipient_restrictions check_client_access is being ignored ?

, permit_sasl_authenticated, check_client_access hash:/etc/postfix-in/pop-before-smtp reject_unauth_destination Judging by a trace, it looks like check_client_access is being ignored? smtpd[20213]: START Recipient address RESTRICTIONS smtpd[20213]: generic_checks: name

Re: looks like smtpd_recipient_restrictions check_client_access is being ignored ?

, reject_unknown_recipient_domain, permit_sasl_authenticated, check_client_access hash:/etc/postfix-in/pop-before-smtp reject_unauth_destination Judging by a trace, it looks like check_client_access is being ignored? smtpd[20213]: START Recipient address RESTRICTIONS smtpd

Re: looks like smtpd_recipient_restrictions check_client_access is being ignored ?

, permit_sasl_authenticated, check_client_access hash:/etc/postfix-in/pop-before-smtp reject_unauth_destination Judging by a trace, it looks like check_client_access is being ignored? smtpd[20213]: START Recipient address RESTRICTIONS smtpd[20213]: generic_checks

Re: looks like smtpd_recipient_restrictions check_client_access is being ignored ?

On Mon, Jun 23, 2014 at 02:23:21PM +0200, li...@rhsoft.net wrote: Note that this has no reject_unknown_recipient_domain. That's because Postfix is not evalating smtpd_recipient_restrictions! As a result of a REJECT or DEFER action in relay restrictions. With Postfox 2.11, relay access

Problem understanding check_client_access and tcp_table

Hello, Subject: Problem understanding check_client_access and tcp_table I have a problem understanding how to properly use check_client_access with an external tcp_table (daemon) in my main.cf i have put the following: smtpd_client_restrictions = check_client_access tcp:[127.0.0.1]:1

Re: Problem understanding check_client_access and tcp_table

On 6/10/2014 2:59 PM, uffe wrote: Hello, Subject: Problem understanding check_client_access and tcp_table I have a problem understanding how to properly use check_client_access with an external tcp_table (daemon) in my main.cf i have put the following: smtpd_client_restrictions

Re: Problem understanding check_client_access and tcp_table

uffe: smtpd_client_restrictions = check_client_access tcp:[127.0.0.1]:1 But what I was expecting was to receive lookup get requests with the raw source ip address as argument - as unknown is not of much use for spam analysis. There will be no get client-address query when the get client

Re: Problem understanding check_client_access and tcp_table

Thanks for your swift answers I'll try the recommendations immediately. English is not my native language - but it did not occour to me from reading that documentation for tcp_table lookups that returning 500 would be aproprialte - I would have believed that is would have stopped the while

Re: Problem understanding check_client_access and tcp_table

Now I got it working - thanks Are tcp_table lookup deamon instances supposed to exit themselves - for every lookup - or can postfix reuse them persistent I'm having a hard time understanding the comment in the bugs section: The client does not hang up when the connection is idle for a long

Re: Problem understanding check_client_access and tcp_table

On 6/10/2014 6:32 PM, uffe wrote: Now I got it working - thanks Are tcp_table lookup deamon instances supposed to exit themselves - for every lookup - or can postfix reuse them persistent I'm having a hard time understanding the comment in the bugs section: The client does not hang

check_client_access doesn't use xforward-IP

Postfix makes lookups just for the localhost source IP 127.0.0.1: Apr 28 16:04:19 host postfix/smtpd[31803]: START Recipient address RESTRICTIONS Apr 28 16:04:19 host postfix/smtpd[31803]: generic_checks: name=check_client_access Apr 28 16:04:19 host postfix/smtpd[31803]: check_namadr_access

Re: check_client_access doesn't use xforward-IP

On Sun, May 04, 2014 at 10:20:23PM +0200, Peer Heinlein wrote: as shown in the log we have a Postfix 2.9.4 with a localhost-connect from Amavis on Port 10025 that uses the xforward-command to give us the source IP address from the real client: XFORWARD is for logging only. Only XCLIENT

Re: check_client_access doesn't use xforward-IP

Peer Heinlein: as shown in the log we have a Postfix 2.9.4 with a localhost-connect from Amavis on Port 10025 that uses the xforward-command to give us the source IP address from the real client: But in the smtpd_recipient_restrictions Postfix makes lookups just for the localhost source IP

Re: check_client_access doesn't use xforward-IP

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 04.05.2014 23:16, schrieb Wietse Venema: @Victor/Wietse: Thus, if you want impersonation use XCLIENT. If you want to have more useful logging from a post-filter MTA. use XFORWARD. Thanks to you both for your explanations. I never realized

check_client_access in smtpd_client_restrictions

I am running postfix 2.6.6 and trying to setup check_client_access using a mysql lookup under the smtpd_client_restrictions, which does not appear to be rejecting clients when the query returns REJECT (which has been confirmed to return REJECT using postmap -q xxx mysql:..). When I change

Re: check_client_access in smtpd_client_restrictions

On 4/15/2014 2:27 PM, List wrote: I am running postfix 2.6.6 and trying to setup check_client_access using a mysql lookup under the smtpd_client_restrictions, which does not appear to be rejecting clients when the query returns REJECT (which has been confirmed to return REJECT using postmap -q

Re: check_client_access in smtpd_client_restrictions

On 4/15/14, 2:50 PM, Noel Jones wrote: On 4/15/2014 2:27 PM, List wrote: I am running postfix 2.6.6 and trying to setup check_client_access using a mysql lookup under the smtpd_client_restrictions, which does not appear to be rejecting clients when the query returns REJECT (which has been

Re: check_client_access in smtpd_client_restrictions

On 4/15/2014 3:02 PM, List wrote: On 4/15/14, 2:50 PM, Noel Jones wrote: On 4/15/2014 2:27 PM, List wrote: I am running postfix 2.6.6 and trying to setup check_client_access using a mysql lookup under the smtpd_client_restrictions, which does not appear to be rejecting clients when the query

Re: check_client_access in smtpd_client_restrictions

On 4/15/14, 3:12 PM, Noel Jones wrote: On 4/15/2014 3:02 PM, List wrote: On 4/15/14, 2:50 PM, Noel Jones wrote: On 4/15/2014 2:27 PM, List wrote: I am running postfix 2.6.6 and trying to setup check_client_access using a mysql lookup under the smtpd_client_restrictions, which does not appear

Re: check_client_access in smtpd_client_restrictions

On 4/15/2014 3:25 PM, List wrote: On 4/15/14, 3:12 PM, Noel Jones wrote: On 4/15/2014 3:02 PM, List wrote: On 4/15/14, 2:50 PM, Noel Jones wrote: On 4/15/2014 2:27 PM, List wrote: I am running postfix 2.6.6 and trying to setup check_client_access using a mysql lookup under

Re: check_client_access in smtpd_client_restrictions

On 4/15/14, 3:33 PM, Noel Jones wrote: On 4/15/2014 3:25 PM, List wrote: On 4/15/14, 3:12 PM, Noel Jones wrote: On 4/15/2014 3:02 PM, List wrote: On 4/15/14, 2:50 PM, Noel Jones wrote: On 4/15/2014 2:27 PM, List wrote: I am running postfix 2.6.6 and trying to setup check_client_access using

Re: domain resolution in check_client_access tables

by using a check_client_access lookup map. It works nice if I use IP addresses. If I use domain names, it stops working for my test environment. My test client doesn't have rDNS set up (I think this is the cause of connect from unknown[x.x.x.x], right?). Do

domain resolution in check_client_access tables

Hello, I wanted to allow certain clients to relay by using a check_client_access lookup map. It works nice if I use IP addresses. If I use domain names, it stops working for my test environment. My test client doesn't have rDNS set up (I think this is the cause of connect from unknown

Re: domain resolution in check_client_access tables

On Sun, Nov 17, 2013 at 07:34:47PM -0500, Wietse Venema wrote: I wanted to allow certain clients to relay by using a check_client_access lookup map. It works nice if I use IP addresses. If I use domain names, it stops working for my test environment. My test client doesn't have rDNS set

Re: check_client_access questions and ordering

Hi, I have a really old system with an early version of postfix on it, but I'm not sure the version really matters for my problem. I'm attempting to use a pop-before-smtp hash as a way of providing authentication prior to being able to use the server to send mail. However, it doesn't appear

Re: check_client_access questions and ordering

supposed to connect to it directly, and trying to convert everyone to SMTP Auth is going to be a challenge. The config for an internal server is pretty simple, something like smtpd_recipient_restrictions = check_client_access hash:/etc/postfix/allowed_clients check_client_access hash:/etc/postfix

Re: check_client_access questions and ordering

to the Internet. No one was ever supposed to connect to it directly, and trying to convert everyone to SMTP Auth is going to be a challenge. The config for an internal server is pretty simple, something like smtpd_recipient_restrictions = check_client_access hash:/etc/postfix

Re: check_client_access questions and ordering

= check_client_access hash:/etc/postfix/allowed_clients check_client_access hash:/etc/postfix/pop-b-smtp # next line optional permit_mynetworks # finally, reject anything not explicitly allowed reject Got it. I will just move the check_client/sender access lists above permit_mynetworks. If I have

Re: check_client_access questions and ordering

= check_client_access hash:/etc/postfix/allowed_clients check_client_access hash:/etc/postfix/pop-b-smtp # next line optional permit_mynetworks # finally, reject anything not explicitly allowed reject I have two different threads going for two different servers (one a relay, one a mail store), so I

Re: check_client_access questions and ordering

smtpd_recipient_restrictions = check_client_access hash:/etc/postfix/allowed_clients check_client_access hash:/etc/postfix/pop-b-smtp # next line optional permit_mynetworks # finally, reject anything not explicitly allowed reject I have two different threads going for two different servers

check_client_access

Hi, I have put line in my main.cf check_client_access = cidr:/etc/postfix/sinokorea.cidr I then restarted postfix, but I can't see it in postconf -n. How come? For reference: my postconf -n output is: [root@vps ~]# postconf -n alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases

Re: check_client_access

Tolga: Hi, I have put line in my main.cf check_client_access = cidr:/etc/postfix/sinokorea.cidr In Postfix 2.9, this will result in a warning: postconf: warning: /etc/postfix/main.cf: unused parameter: check_client_access=cidr:/etc/postfix/sinokorea.cidr And indeed check_client_access

Re: check_client_access

On 07/22/2012 03:12 PM, Wietse Venema wrote: Tolga: Hi, I have put line in my main.cf check_client_access = cidr:/etc/postfix/sinokorea.cidr In Postfix 2.9, this will result in a warning: postconf: warning: /etc/postfix/main.cf: unused parameter: check_client_access=cidr:/etc/postfix

Re: check_client_access using smtp auth usernames

Thank you Noel, After searching for a while, I found your info/solutions were complete and accurate. Locking sender addresses with authenticated users appears to be a good practice, anyway. Here, I have two questions about reject_sender_login_mismatch: 1. If sender is in the form

Re: check_client_access using smtp auth usernames

Am 11.02.2011 10:08, schrieb Nikolaos Milas: Thank you Noel, After searching for a while, I found your info/solutions were complete and accurate. Locking sender addresses with authenticated users appears to be a good practice, anyway. Here, I have two questions about

Re: check_client_access using smtp auth usernames

Thank you Harald, Please, let me ask for some clarifications, cause I'm confused: If we have (SASL) UNauthenticated clients (who are allowed to send emails from mynetworks) AND (SASL) authenticated clients (in mynetworks or anywhere), what will happen to our UNauthenticated clients (in

Re: check_client_access using smtp auth usernames

On 2/11/2011 6:08 AM, Nikolaos Milas wrote: Thank you Harald, Please, let me ask for some clarifications, cause I'm confused: If we have (SASL) UNauthenticated clients (who are allowed to send emails from mynetworks) AND (SASL) authenticated clients (in mynetworks or anywhere), what will

Re: check_client_access using smtp auth usernames

Thanks Noel, for the detailed info. In the meantime, I had already tested, and here are the test results, for reference (tested by removing ownership of f...@example.com by foo and logging in (in scenario II) as user foo): I.  1 ---a

Re: check_client_access using smtp auth usernames

(I'm sending again, because by mistake the message I sent before was in html form.) Thanks Noel, for the detailed info. In the meantime, I had already tested, and here are the test results, for reference (tested by removing ownership of f...@example.com by foo and logging in (in scenario II)

Re: check_client_access using smtp auth usernames

Sorry, Noel, Now that I re-read your last post, I can see there is no discrepancy at all between my findings and your description in the two cases I mentioned. In fact, what happens is exactly what you describe. The email message is rejected because the client specifies a MAIL FROM listed in

Re: check_client_access using smtp auth usernames

Thanks Jeroen, I checked the documentation and I think smtpd_sender_login_maps might do the trick. Does anyone know if a many-to-many (M-to-M) mapping is allowed in these maps? That is, the following example is valid (a hash file)? ma...@example.com user1 ma...@example.com

Re: check_client_access using smtp auth usernames

* Nikolaos Milas nmi...@noa.gr: Thanks Jeroen, I checked the documentation and I think smtpd_sender_login_maps might do the trick. Does anyone know if a many-to-many (M-to-M) mapping is allowed in these maps? That is, the following example is valid (a hash file)? No

Re: check_client_access using smtp auth usernames

Thanks Ralf, That means that the following format should be OK? ma...@example.com user1,user2,user3 ma...@example.com user1,user2 ma...@example.com user1,user3 This is still a M-to-M mapping (many mail addresses are mapped to many SASL login usernames), it's just

Re: check_client_access using smtp auth usernames

* Nikolaos Milas nmi...@noa.gr: Thanks Ralf, That means that the following format should be OK? ma...@example.com user1,user2,user3 ma...@example.com user1,user2 ma...@example.com user1,user3 This is still a M-to-M mapping (many mail addresses are mapped to

check_client_access using smtp auth usernames

on authenticated usernames (for example a check_client_access lookup table with entries of the form: userx OK, where userx is a successfully authenticated SMTP username and not the sender's mail address username)? Is there direct or indirect way to accomplish this? Is there a way to retrieve

Re: check_client_access using smtp auth usernames

setup some smtp_restriction_classes based on authenticated usernames (for example a check_client_access lookup table with entries of the form: userx OK, where userx is a successfully authenticated SMTP username and not the sender's mail address username)? Is there direct or indirect way

Re: serious bug with check_client_access

Le 05/11/2010 10:03, Vincent Lefevre a écrit : [hash/cdb/...] - if parent_domain_matches_subdomains contains smtpd_access: here, the search list is S = ( lab1.lab2.lab3.example.com, lab2.lab3.example.com, lab3.example.com ..., com, 1.2.3.4, 1.2.3, 1.2, 1 ) so postfix will search for each

Re: serious bug with check_client_access

Le 05/11/2010 09:48, Vincent Lefevre a écrit : On 2010-11-04 23:36:04 -0300, Reinaldo de Carvalho wrote: On Thu, Nov 4, 2010 at 11:13 PM, Vincent Lefevrevinc...@vinc17.net wrote: Yes, it will generate *some* lookups, but it doesn't say exactly *which* lookups. That was precisely my question.

Re: serious bug with check_client_access

On 2010-11-04 23:36:04 -0300, Reinaldo de Carvalho wrote: On Thu, Nov 4, 2010 at 11:13 PM, Vincent Lefevre vinc...@vinc17.net wrote: Yes, it will generate *some* lookups, but it doesn't say exactly *which* lookups. That was precisely my question. - client hostname (reverse dns hostname) -

Re: serious bug with check_client_access

On 2010-11-05 06:21:20 +0100, mouss wrote: in short, for each map, you have multiple parameters: - the map type - the search context (check_client_access, check_sender_acces, ... transport, virtual_alias_maps, ... etc) - the list of search keys [...] Thanks a lot for this very detailed

Re: serious bug with check_client_access

extension) or is it intentional? If you want to block rDNS TLDs this PCRE works with check_client_access: /^.*?(info|kr|jp|sg|qa)$/i 550 We do not accept mail from .$1 domains You could also use this for check_sender_access, check_helo_access, etc--it should work with any check that passes

Re: serious bug with check_client_access

В Срд, 03/11/2010 в 22:16 -0500, Noel Jones пишет: On 11/3/2010 10:00 PM, Vincent Lefevre wrote: On 2010-11-03 21:40:54 -0500, Noel Jones wrote: .domain.tld only works if parent_domain_matches_subdomains does NOT include smtpd_access maps. The man page says nothing like that. So, the

Re: serious bug with check_client_access

Le 04/11/2010 05:24, Noel Jones a écrit : On 11/3/2010 11:07 PM, Vincent Lefevre wrote: BTW, so, there is no way to match only subdomains (by that, I mean all possible subdomains, but not the domain itself) without changing parent_domain_matches_subdomains? That's correct with indexed tables.

Re: serious bug with check_client_access

Zitat von Покотиленко Костик cas...@meteor.dp.ua: В Срд, 03/11/2010 в 22:16 -0500, Noel Jones пишет: On 11/3/2010 10:00 PM, Vincent Lefevre wrote: On 2010-11-03 21:40:54 -0500, Noel Jones wrote: .domain.tld only works if parent_domain_matches_subdomains does NOT include smtpd_access maps.

Re: serious bug with check_client_access

В Чтв, 04/11/2010 в 10:44 +0100, lst_ho...@kwsoft.de пишет: Zitat von Покотиленко Костик cas...@meteor.dp.ua: В Срд, 03/11/2010 в 22:16 -0500, Noel Jones пишет: On 11/3/2010 10:00 PM, Vincent Lefevre wrote: On 2010-11-03 21:40:54 -0500, Noel Jones wrote: .domain.tld only works if

Re: serious bug with check_client_access

On 2010-11-04 10:44:34 +0100, lst_ho...@kwsoft.de wrote: The access(5) man page says: domain.tld Matches domain.tld. The pattern domain.tld also matches subdomains, but only when the string smtpd_access_maps is listed in the Postfix

Documentation (was: serious bug with check_client_access)

Vincent Lefevre: On 2010-11-04 10:44:34 +0100, lst_ho...@kwsoft.de wrote: The access(5) man page says: domain.tld Matches domain.tld. The pattern domain.tld also matches subdomains, but only when the string smtpd_access_maps is listed in

Re: Documentation (was: serious bug with check_client_access)

On Thu, Nov 04, 2010 at 10:56:57AM -0400, Wietse Venema wrote: Vincent Lefevre: On 2010-11-04 10:44:34 +0100, lst_ho...@kwsoft.de wrote: The access(5) man page says: domain.tld Matches domain.tld. The pattern domain.tld also matches subdomains,

Re: Documentation (was: serious bug with check_client_access)

On 2010-11-04 10:28:00 -0500, /dev/rob0 wrote: On Thu, Nov 04, 2010 at 10:56:57AM -0400, Wietse Venema wrote: I can replace that Otherwise... sentence by a separate list item. domain.tld Matches domain.tld. The pattern domain.tld also matches

Re: serious bug with check_client_access

Le 04/11/2010 05:07, Vincent Lefevre a écrit : On 2010-11-03 22:55:59 -0500, Noel Jones wrote: I'm so sorry you lost your twitter post. Actually I might have lost other mail (though this is a bit unlikely) since I was generally using an initial dot. a good idea is to include both dotted and

  1   2   >