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, and
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.
>
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 th
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 Receive
>> 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 oth
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
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 tagged_
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 does
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 se
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
> > > parent_domain_matches_subdomai
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 genera
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
> > > parent_domain_matches_sub
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
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 h
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 fi
ck_sender_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 c
nderaccess
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
conne
format and use 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://ex
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 to be
rmit_mynetworks,
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
> 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 Service unavailable;
> **
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
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 ": /
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.
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.
>
> B
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 simplifie
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
> >
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 tho
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 an
> 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... it was a lot)
>
> You're
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.
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 be
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 the
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
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 describ
can see my 'smtpd_client_restrictions' block
>> > bellow:
>> >
>> > smtpd_client_restrictions =
>> > permit_mynetworks,
>> > check_client_access hash:/etc/postfix/access
>> &g
block
> > bellow:
> >
> > smtpd_client_restrictions =
> > permit_mynetworks,
> > check_client_access hash:/etc/postfix/access
> > reject_unknown_client_hostname,
> >
gt; permit_mynetworks,
> check_client_access hash:/etc/postfix/access
> reject_unknown_client_hostname,
> reject_unauth_destination,
> reject_invalid_hostname,
>
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,
chec
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 acces
s,
>> reject_non_fqdn_recipient,
>> 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 "chec
s,
>> reject_non_fqdn_recipient,
>> 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 lo
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]:
,
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=p
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
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 l
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
delive
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
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
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
The
-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 th
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 sourc
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 cha
in the smtpd_recipient_restrictions 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
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
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 c
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
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
>>>
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"
(whic
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
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:
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
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 c
E.B.:
> 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 thi
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 fro
o 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_acce
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/pop-b-smtp
>&g
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/pop-b-smtp
> # next line optional
> permit_mynetworks
> # finally, re
. 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/allowed_clients
Just t
This is a typical setup for an internet-facing mail server.
>
> It's somewhat of an internal server, despite being connected 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
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'
ostfix.org/postconf.5.html#reject_rbl_client
If your postfix is so old that it doesn't have reject_rbl_client,
your support contract is terminated until you upgrade.
> smtpd_recipient_restrictions = reject_non_fqdn_sender
> reject_non_fqdn_recipient check_client_access
> hash:/etc
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
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.c
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/al
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
(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)
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 (mes
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 happen
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
mynetw
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 reject
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 "f...@e
* Nikolaos Milas :
> 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 SA
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 format
* Nikolaos Milas :
> 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
>ma...@example.com
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 u
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 i
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
uot; 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 to accomplis
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 Lefevre wrote:
Yes, it will generate *some* lookups, but it doesn't say exactly
*which* lookups. That was precisely my question.
- client hostname
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
instead, like in Section "Email address 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_ac
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 thi
On 2010-11-04 23:36:04 -0300, Reinaldo de Carvalho wrote:
> On Thu, Nov 4, 2010 at 11:13 PM, Vincent Lefevre 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)
> - client IP
:
- the map type
- the search context (check_client_access, check_sender_acces, ...
transport, virtual_alias_maps, ... etc)
- the list of search keys
for each combination, a "search list" is derived: for each key, sub-keys
are derived (whether this occurs and how depends on th
things like
smtpd_foo_restrictions.
For instance, check_client_access is going to pass both a hostname and
an IP address to your pcre table, but not an email address.
check_sender_access is going to pass only an email address to your pcre.
Please don't get frustrated. I had difficulty with some of
On Thu, Nov 4, 2010 at 11:13 PM, Vincent Lefevre wrote:
> On 2010-11-04 23:06:17 -0300, Reinaldo de Carvalho wrote:
>> On Thu, Nov 4, 2010 at 10:42 PM, Reinaldo de Carvalho
>> wrote:
>> >
>> > check_client_access type:table
>> > Search the specifi
On 2010-11-04 23:06:17 -0300, Reinaldo de Carvalho wrote:
> On Thu, Nov 4, 2010 at 10:42 PM, Reinaldo de Carvalho
> wrote:
> >
> > check_client_access type:table
> > Search the specified access database for the client hostname,
> > parent domains, client IP ad
Vincent Lefevre put forth on 11/4/2010 7:49 PM:
> On 2010-11-04 20:33:11 -0400, Wietse Venema wrote:
>> check_client_access searches the address and domain with ALL lookup
>> table types. It just doesn't do the substring lookups with PCRE,
>> REGEXP and CIDR.
>
On Thu, Nov 4, 2010 at 10:42 PM, Reinaldo de Carvalho
wrote:
>
> check_client_access type:table
> Search the specified access database for the client hostname,
> parent domains, client IP address, or networks obtained by stripping
> least significant octets. See the access(5)
1 - 100 of 180 matches
Mail list logo
