A Question About "check_client_access"

[Rich Shepard]

I have a restriction map of IP addresses I want rejected. They are invoked
within /etc/postfix/main.cf with 'check_client_access
hash:/etc/postfix/badip'. Over the past couple of days, spam has made it into
my inbox despite having an IP address in a block listed in that file. The
address is always the one from which my MTA received it, not earlier in the
transmission sequence.

Not all checks on this file fail, only some do. I'd like to understand why
some messages are not rejected when the address falls within a block that's
an entry in the file.

All ideas appreciated.

Rich

[mouss]

Post by Rich Shepard
I have a restriction map of IP addresses I want rejected. They are invoked
within /etc/postfix/main.cf with 'check_client_access
hash:/etc/postfix/badip'. Over the past couple of days, spam has made it into
my inbox despite having an IP address in a block listed in that file. The
address is always the one from which my MTA received it, not earlier in the
transmission sequence.
Not all checks on this file fail, only some do. I'd like to
understand why
some messages are not rejected when the address falls within a block that's
an entry in the file.
All ideas appreciated.

In general, if a client is not blocked, this is because no reject rule
was applied to it, and in particular, it didn't match a client_access
rule that rejects it.

if you want more precise ideas, provide more precise informations.

- where is postconf -n?
- do all entries in badip have "REJECT" as the right hand side (the
result field) or do you use different results?
- what is the format of the IPs that don't get caught?
post a full line of this (replace digits by 'd' if you want, but keep
dots and other chars).

[/dev/rob0]

Post by Rich Shepard
I have a restriction map of IP addresses I want rejected. They are
invoked within /etc/postfix/main.cf with 'check_client_access
hash:/etc/postfix/badip'. Over the past couple of days, spam has made
it into my inbox despite having an IP address in a block listed in
that file. The address is always the one from which my MTA received

"postmap -q ip.add.re.ss hash:/etc/postfix/badip" tells you whether
"ip.add.re.ss" is found in the hash table "/etc/postfix/badip".
postmap.1.html has details. access.5.html explains the format of access
table lookups. For a list of IP addresses you might also want to
consider the cidr format: cidr_table(5), cidr_table.5.html.

But wait, Rich, there's more ... I am going to lead you to The Fountain
of Postfix Knowledge. When you installed your Postfix did you enter a
value for html_directory ? You should have. For Slackware
"/usr/share/postfix" would be an appropriate choice, or put that under
"/usr/local". Make a symlink from that into your apache DocumentRoot
("/var/www/htdocs" in Slackware.) Bookmark it (http://yourhost/postfix)
in your browser, refer to it often.

It gets better! Well, no, not really. But I want to tell you about the
one document which helped me start to put all the pieces together in my
mind: http://jimsun.linxnet.com/misc/postfix-anti-UCE.txt

Good luck, have fun.

[Rich Shepard]

In general, if a client is not blocked, this is because no reject rule was
applied to it, and in particular, it didn't match a client_access rule that
rejects it.

I guess I was not sufficiently clear.

The first 16 bits in the IP address are listed in the client_access rule,
and 'reject' is the action to be taken.

- do all entries in badip have "REJECT" as the right hand side (the result
field) or do you use different results?

Yes.

- what is the format of the IPs that don't get caught? post a full line of
this (replace digits by 'd' if you want, but keep dots and other chars).

It is analagous to

Received: from <some_domain_name> (IP address unknown[xx.yyy.z.ddd])

My understanding of the postfix restrictions is that 1) the
'reject_unknown_sender_domain' checked the IP address and rejected it if it
was unknown and 2) the entry in 'check_client_access hash:/etc/postfix/badip'
would also catch it if xx.yyy was listed in that map file.

Rich

[mouss]

Post by Rich Shepard

In general, if a client is not blocked, this is because no reject rule was
applied to it, and in particular, it didn't match a client_access rule that
rejects it.

I guess I was not sufficiently clear.

happy to read you say so, but you still don't provide your postconf -n.
now, don't. just check that no other restrictions allowed the mails in
question. we'll trust until next step:)

Post by Rich Shepard
The first 16 bits in the IP address are listed in the client_access rule,
and 'reject' is the action to be taken.

so you mean you have
a.b REJECT
in your file, and you say below that only "REJECT" is used. no other action.

now, do you have lines starting with space?

Post by Rich Shepard

- do all entries in badip have "REJECT" as the right hand side (the
result field) or do you use different results?

Yes.

- what is the format of the IPs that don't get caught? post a full line of
this (replace digits by 'd' if you want, but keep dots and other chars).

It is analagous to
Received: from <some_domain_name> (IP address unknown[xx.yyy.z.ddd])

I trust you to know what is an IP block. I was looking for the other
stuff (spaces, '#', commas, ... etc).
for instance
---------------------
1.2 REJECT
3.4 REJECT
---------------------
is incorrect (see the space before 3.4).

Post by Rich Shepard
My understanding of the postfix restrictions is that 1) the
'reject_unknown_sender_domain' checked the IP address and rejected it if it
was unknown and 2) the entry in 'check_client_access
hash:/etc/postfix/badip'
would also catch it if xx.yyy was listed in that map file.

it is supposed to do so unless
- another check in your restrictions allows the mail
- there is an error in your file.
for instance


As suggested by Rob, use postmap -q to check that the IP really match an
entry in your hash.
(the IP need not be present in the hash, but it should match one of your
blocks if it is supposed to be blocked).

[Rich Shepard]

Post by /dev/rob0
"postmap -q ip.add.re.ss hash:/etc/postfix/badip" tells you whether

Rob0,

In badip I have the equivalent of the first two bytes, ip.add; I don't have
all the re.ss within that block. This works 99% of the time, but occasionally
fails. I'm trying to understand the failures.

Post by /dev/rob0
postmap.1.html has details. access.5.html explains the format of access
table lookups. For a list of IP addresses you might also want to
consider the cidr format: cidr_table(5), cidr_table.5.html.

I've considered converting the whole file to a cidr table, but that's a lot
of work.

Post by /dev/rob0
But wait, Rich, there's more ... I am going to lead you to The Fountain of
Postfix Knowledge. When you installed your Postfix did you enter a value
for html_directory ? You should have. For Slackware "/usr/share/postfix"
would be an appropriate choice, or put that under "/usr/local". Make a
symlink from that into your apache DocumentRoot ("/var/www/htdocs" in
Slackware.) Bookmark it (http://yourhost/postfix) in your browser, refer to
it often.

No, no html_directory. I much prefer dead tree versions of docs, or pdf
files.

Post by /dev/rob0
It gets better! Well, no, not really. But I want to tell you about the one
http://jimsun.linxnet.com/misc/postfix-anti-UCE.txt

I've had restrictions working for several years now, but I'm gaining
greater insight from "The Book of Postfix". So far, I've read the first 10
chapters. I've tuned the smtp restrictions based on what I've learned; the
badip map has been in place a long time.

Thanks,

Rich

[/dev/rob0]

Post by Rich Shepard

Post by /dev/rob0
"postmap -q ip.add.re.ss hash:/etc/postfix/badip" tells you whether

In badip I have the equivalent of the first two bytes, ip.add; I
don't have all the re.ss within that block. This works 99% of the
time, but occasionally fails. I'm trying to understand the failures.

Find one that got through and check it with the postmap command as
shown. It won't match. Double-check the syntax of the line you think
should have matched. If you can't figure it out post again with the
Received header and the line that should have matched.

[Noel Jones]

Post by Rich Shepard
I've considered converting the whole file to a
cidr table, but that's a lot
of work.

And unnecessary. A hash table is fine if it suits
your needs. There's nothing inherently "better" about
a cidr table, they just give you a way to express
subnets that are not class A/B/C networks, which are
all you can specify in a hash.

Post by Rich Shepard
...
I've had restrictions working for several years
now, but I'm gaining
greater insight from "The Book of Postfix". So far,
I've read the first 10
chapters. I've tuned the smtp restrictions based on
what I've learned; the
badip map has been in place a long time.

Choices:
- the IP doesn't match the table.
- the /24 or /32 address was matched in the table with
something other than REJECT.
- the client hostname was matched in the table with
something other than REJECT (name lookups are done
first).
- the message was allowed/whitelisted prior to the
badip table lookup.
- The message was addressed to <postmaster> or
<postmaster@$myorigin>. These addresses bypass usual
restrictions.

without complete information, we're just speculating.

[Rich Shepard]

- the /24 or /32 address was matched in the table with something other than REJECT.

Noel,

This brings up a question I've had for a long time, but for which I have
not yet found the answer.

Can I specify an address with the slash notation in a hashed map? That is,
can my 'badip' file contain entries such as '10.0/16' rather than just
'10.0'? IIRC, in postfix-1.x days it could not, but I've not read where it
can in postfix-2.x. FWIW, I'm running postfix-2.2.5-i486-1stb (installed via
the Slackware package).

- the client hostname was matched in the table with something other than
REJECT (name lookups are done first).

Not at all likely. My whitelist is very short and not in that IP address
block.

I know I've not posted the real IP address so it's difficult to be precise
in answering. Be assured, however, that the first restriction encountered by
the message was supposed to be in that list of undesired IP addresses. I
suspect that if I can use the slash notation these occasional misses will
disappear.

Many thanks,

Rich

[/dev/rob0]

not read where it can in postfix-2.x. FWIW, I'm running
postfix-2.2.5-i486-1stb (installed via the Slackware package).

You're probably aware of this, but to split hairs here, technically
there is no Slackware package of Postfix. You probably got that one
from Linuxpackages.net.

[Noel Jones]

Post by Rich Shepard
I know I've not posted the real IP address so it's
difficult to be precise
in answering. Be assured, however, that the first
restriction encountered by
the message was supposed to be in that list of
undesired IP addresses. I
suspect that if I can use the slash notation these
occasional misses will
disappear.

Slash notation is valid in a cidr table, and not valid
in a hash or other indexed table.
And no, converting your badip list to a cidr table
won't fix this problem.

Investigate each of the choices I listed
earlier. One key point is to verify that
postmap -q aa.bb hash:/path/to/badip
returns the expected REJECT message.

[Rich Shepard]

Slash notation is valid in a cidr table, and not valid in a hash or other
indexed table.

Noel,

That's what I thought. Thank you for confirming it.

And no, converting your badip list to a cidr table won't fix this problem.

OK.

Investigate each of the choices I listed earlier. One key point is to
verify that
postmap -q aa.bb hash:/path/to/badip
returns the expected REJECT message.

Yes, it does. That's why I'm puzzled.

Well, I'll wait for the next one and post the headers with the results of
the postmap query.

Many thanks,

Rich

[Noel Jones]

Post by Rich Shepard
Well, I'll wait for the next one and post the
headers with the results of
the postmap query.

Showing us that the IP is listed in your hash is of
limited value; I don't doubt that it is. Very likely
the mail is bypassing that map for some reason that
only complete configuration information will show.
If you need more help, be sure to include postconf -n
output and log entries concerning the mail in
question.
Unaltered would be best.

[Rich Shepard]

Post by mouss
so you mean you have
a.b REJECT
in your file, and you say below that only "REJECT" is used. no other action.

This is correct.

Post by mouss
now, do you have lines starting with space?

No. They all begin at the left margin.

Post by mouss
I trust you to know what is an IP block. I was looking for the other stuff
(spaces, '#', commas, ... etc).
for instance
---------------------
1.2 REJECT
3.4 REJECT
---------------------
is incorrect (see the space before 3.4).

Here are a couple of entries with the actual numbers removed:

aa.bb 550 Rejected IP address.

xxx.yyy.zz 550 Rejected IP address.

I use [Tab] to space the smtp result code and the following message.

Post by mouss
As suggested by Rob, use postmap -q to check that the IP really match an
entry in your hash. (the IP need not be present in the hash, but it should
match one of your blocks if it is supposed to be blocked).

The specific address does not match the hash, but the first two bytes do
match.

Thanks,

Rich

[mouss]

Post by Rich Shepard

Post by mouss
so you mean you have
a.b REJECT
in your file, and you say below that only "REJECT" is used. no other action.

This is correct.

Post by mouss
now, do you have lines starting with space?

No. They all begin at the left margin.

Post by mouss
I trust you to know what is an IP block. I was looking for the other
stuff (spaces, '#', commas, ... etc).
for instance
---------------------
1.2 REJECT
3.4 REJECT
---------------------
is incorrect (see the space before 3.4).

aa.bb 550 Rejected IP address.
xxx.yyy.zz 550 Rejected IP address.
I use [Tab] to space the smtp result code and the following message.

Post by mouss
As suggested by Rob, use postmap -q to check that the IP really match an
entry in your hash. (the IP need not be present in the hash, but it should
match one of your blocks if it is supposed to be blocked).

The specific address does not match the hash, but the first two bytes do
match.

then you should look at your other checks. unless you post your
smtpd_mumble_restrictions, it's hard to tell.

[Rich Shepard]

Showing us that the IP is listed in your hash is of limited value; I don't
doubt that it is. Very likely the mail is bypassing that map for some
reason that only complete configuration information will show. If you need
more help, be sure to include postconf -n output and log entries concerning
the mail in question. Unaltered would be best.

Fair enough. Here's the message header (up to those added by SpamAssassin):

Return-Path: <***@joinme.com>
X-Original-To: ***@appl-ecosys.com
Delivered-To: ***@appl-ecosys.com
Received: by salmo.appl-ecosys.com (Postfix, from userid 1006)
id 183C5DCE; Tue, 11 Oct 2005 14:56:21 -0700 (PDT)
Received: from 216.99.206.23 (unknown [61.84.170.21])
by salmo.appl-ecosys.com (Postfix) with SMTP id B6FC8DCA
for <***@appl-ecosys.com>; Tue, 11 Oct 2005 14:55:47 -0700 (PDT)
Received: (qmail 55453 invoked from network); Tue, 11 Oct 2005 17:56:15 -0400
Received: from mail.shults.com (HELO exchange-shults.com) (63.247.85.226)
by server-99.celebrant-36.dunedin.com with SMTP; Wed, 12 Oct 2005 00:54:15
+0300
Received: by mail.shults.com with Internet Mail Service (5.5.WOPO.QM)
id <HNJY43VS>; Wed, 12 Oct 2005 03:00:15 +0500
Subject: MAINTAIN your weight loss
To: <***@appl-ecosys.com>
Date: Tue, 11 Oct 2005 20:57:15 -0100
From: "Marylou Latham" <***@joinme.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
Message-Id: <***@salmo.appl-ecosys.com>

And here's the entry from /var/log/maillog:

Oct 11 14:55:46 salmo postfix/smtpd[32521]: connect from unknown[61.84.170.21]
Oct 11 14:55:57 salmo postfix/smtpd[32521]: B6FC8DCA: client=unknown[61.84.170.21]
Oct 11 14:56:00 salmo postfix/smtpd[32521]: disconnect from unknown[61.84.170.21]

The output from 'postconf -n':

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/postfix/aliases, hash:/etc/postfix/major-aliases
body_checks = regexp:/etc/postfix/body_checks
command_directory = /usr/sbin/
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
default_privs = nobody
header_checks = regexp:/etc/postfix/header_checks
html_directory = no
inet_interfaces = all
local_recipient_maps = unix:passwd.byname $alias_maps
mail_owner = postfix
mail_spool_directory = /var/spool/mail
mailbox_command = /usr/bin/procmail
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 30720000
mydestination = $myhostname, mail.$mydomain, localhost.$mydomain, localhost.$mydomain, $mydomain, /etc/postfix/local/localdomains
mydomain = appl-ecosys.com
myhostname = salmo.appl-ecosys.com
mynetworks = 192.168.55.0/24, 127.0.0.0/8
mynetworks_style = subnet
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
readme_directory = /etc/postfix/README_FILES
sample_directory = /etc/postfix/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtpd_recipient_restrictions =
check_client_access hash:/etc/postfix/internal_network
check_sender_access hash:/etc/postfix/not_our_domain_as_sender
reject_non_fqdn_recipient reject_non_fqdn_sender
reject_unknown_sender_domain
reject_unknown_recipient_domain
permit_mynetworks
reject_unauth_destination
check_recipient_access hash:/etc/postfix/roleaccount_exceptions
check_recipient_access hash:/etc/postfix/recipients
check_helo_access pcre:/etc/postfix/helo_checks
reject_non_fqdn_hostname
reject_invalid_hostname
check_sender_mx_access cidr:/etc/postfix/bogus_mx
check_sender_access hash:/etc/postfix/rhsbl_sender_exceptions
reject_rhsbl_sender dsn.rfc-ignorant.org
reject_rbl_client sbl-xbl.spamhaus.org
reject_rbl_client relays.ordb.org
reject_rbl_client bl.spamcop.net
reject_rbl_client list.dsbl.org
check_sender_access hash:/etc/postfix/common_spam_senderdomains
check_client_access hash:/etc/postfix/badip
check_client_access hash:/etc/postfix/badaddr
check_sender_access hash:/etc/postfix/badaddr
permit
smtpd_restriction_classes = has_our_domain_as_sender
unknown_local_recipient_reject_code = 550

And, the entry from /etc/postfix/badip:

61.84 550 Rejected IP address.

I hope this helps.

Thanks,

Rich


Dr. Richard B. Shepard, President | Author of "Quantifying Environmental
Applied Ecosystem Services, Inc. (TM) | Impact Assessments Using Fuzzy Logic"
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: [phone]

[mouss]

Post by Rich Shepard
Oct 11 14:55:46 salmo postfix/smtpd[32521]: connect from
unknown[61.84.170.21]
client=unknown[61.84.170.21]
Oct 11 14:56:00 salmo postfix/smtpd[32521]: disconnect from
unknown[61.84.170.21]

finally!! I thought you'll never do that:) (just kidding of course).

Post by Rich Shepard
smtpd_recipient_restrictions =
check_client_access hash:/etc/postfix/internal_network

make sure this one doesn't allow the cited client.

Post by Rich Shepard
check_sender_access hash:/etc/postfix/not_our_domain_as_sender

verify that this doesn't whitelist anyone

Post by Rich Shepard
reject_non_fqdn_recipient reject_non_fqdn_sender
reject_unknown_sender_domain
reject_unknown_recipient_domain
permit_mynetworks

(of course, 61.81.170.21 isn't in your network)

Post by Rich Shepard
reject_unauth_destination
check_recipient_access hash:/etc/postfix/roleaccount_exceptions

I guess this doesn't whitelist your email address.

Post by Rich Shepard
check_recipient_access hash:/etc/postfix/recipients

nor this

Post by Rich Shepard
check_helo_access pcre:/etc/postfix/helo_checks

check this twice or more. check it with helo=216.99.206.23.
If I were you, I'd just reject naked IP helo's. and since you do
reject_non_fqdn_hostname, I see no reason to accept naked IPs in helo.

Post by Rich Shepard
reject_non_fqdn_hostname
reject_invalid_hostname
check_sender_mx_access cidr:/etc/postfix/bogus_mx

I guess this only returns REJECT (never OK)?

Post by Rich Shepard
check_sender_access hash:/etc/postfix/rhsbl_sender_exceptions

make sure this doesn't allow the spammer.

Post by Rich Shepard
reject_rhsbl_sender dsn.rfc-ignorant.org
reject_rbl_client sbl-xbl.spamhaus.org
reject_rbl_client relays.ordb.org
reject_rbl_client bl.spamcop.net
reject_rbl_client list.dsbl.org
check_sender_access hash:/etc/postfix/common_spam_senderdomains

I guess this only returns REJECT.

Post by Rich Shepard
check_client_access hash:/etc/postfix/badip
check_client_access hash:/etc/postfix/badaddr
check_sender_access hash:/etc/postfix/badaddr
permit
smtpd_restriction_classes = has_our_domain_as_sender

when is this called (which map from the above) and how it is defined?

[Noel Jones]

Post by Rich Shepard
Received: from 216.99.206.23 (unknown [61.84.170.21])
by salmo.appl-ecosys.com (Postfix) with SMTP id
B6FC8DCA
14:55:47 -0700 (PDT)

...

Post by Rich Shepard
smtpd_recipient_restrictions =
check_client_access
hash:/etc/postfix/internal_network
check_sender_access
hash:/etc/postfix/not_our_domain_as_sender
reject_non_fqdn_recipient
reject_non_fqdn_sender
reject_unknown_sender_domain
reject_unknown_recipient_domain
permit_mynetworks
reject_unauth_destination
check_recipient_access
hash:/etc/postfix/roleaccount_exceptions
check_recipient_access
hash:/etc/postfix/recipients
check_helo_access pcre:/etc/postfix/helo_checks
reject_non_fqdn_hostname
reject_invalid_hostname
check_sender_mx_access
cidr:/etc/postfix/bogus_mx
check_sender_access
hash:/etc/postfix/rhsbl_sender_exceptions
reject_rhsbl_sender dsn.rfc-ignorant.org
reject_rbl_client sbl-xbl.spamhaus.org
reject_rbl_client relays.ordb.org
reject_rbl_client bl.spamcop.net
reject_rbl_client list.dsbl.org
check_sender_access
hash:/etc/postfix/common_spam_senderdomains
check_client_access hash:/etc/postfix/badip

It never gets this far. This particular host is
listed in several of the RBLs you use, so the message
is getting whitelisted before it ever gets to the
badip map, before it gets to the RBL checks.

Check all your maps above the RBL checks - one of them
is giving either client/helo/sender/recipient an OK
response. I'd check the pcre: maps first, but that's
just a hunch. Any map that can possibly give an OK
responses is suspect at this point.
Remember about the search order when you test with
postmap -q, check the access(5) man page for a
refresher. Postmap doesn't do recursive queries, so
you have to do them manually as in:
postmap -q ***@host.example.com sender_map
postmap -q host.example.com sender_map
postmap -q example.com sender_map
postmap -q com sender_map
postmap -q sender@ sender_map

[Rich Shepard]

Post by mouss

Post by Rich Shepard
check_client_access hash:/etc/postfix/internal_network

make sure this one doesn't allow the cited client.

It doesn't. Here, at least, internal network is a non-public IP address in
the Class C block of 192.168. Internal network has only 192.168.55.

Post by mouss

Post by Rich Shepard
check_sender_access hash:/etc/postfix/not_our_domain_as_sender

verify that this doesn't whitelist anyone

No, that map has only:
appl-ecosys.com 554 Do not use my domain in your envelope sender.

Post by mouss

Post by Rich Shepard
check_recipient_access hash:/etc/postfix/roleaccount_exceptions

I guess this doesn't whitelist your email address.

Post by Rich Shepard
check_recipient_access hash:/etc/postfix/recipients

nor this

Nope. That checks users against /etc/passwd or /etc/shadow

Post by mouss

Post by Rich Shepard
check_helo_access pcre:/etc/postfix/helo_checks

check this twice or more. check it with helo=216.99.206.23.
If I were you, I'd just reject naked IP helo's. and since you do
reject_non_fqdn_hostname, I see no reason to accept naked IPs in helo.

Well, I do get a positive response here:

[***@salmo /etc/postfix]# postmap -q 216.99.206.23 pcre:/etc/postfix/helo_checks
550 Don't use my IP address.

If I correctly understand the application of helo_checks, this means that
the unknown IP address that tried to spoof my IP address would receive a
rejection with the above additional text. Is this correct?

Post by mouss

Post by Rich Shepard
check_sender_mx_access cidr:/etc/postfix/bogus_mx

I guess this only returns REJECT (never OK)?

Yes. All are return code 550.

Post by mouss

Post by Rich Shepard
check_sender_access hash:/etc/postfix/rhsbl_sender_exceptions

make sure this doesn't allow the spammer.

No, it doesn't have the domain name that's in the return-path line.

Post by mouss

Post by Rich Shepard
check_sender_access hash:/etc/postfix/common_spam_senderdomains

I guess this only returns REJECT.

This map file has four entries; the action for each is:
reject_unverified_sender

Post by mouss

Post by Rich Shepard
smtpd_restriction_classes = has_our_domain_as_sender

when is this called (which map from the above) and how it is defined?

In Chapter 9 of the book smtpd_restriction_classes are called before
smtpd_recipient_restrictions. It is defined as:

smtpd_restriction_classes =
has_our_domain_as_sender
has_our_domain_as_sender =
check_sender_access hash:/etc/postfix/our_domain_as_sender
reject

As noted above, our_domain_as_sender == appl-ecosys.com.

So, I suppose this remains a mystery and I just live with the fact that
sometimes a spam message makes it past the checks for no discernable reason.

Many thanks,

Rich

[Noel Jones]

Post by Rich Shepard

Post by mouss

Post by Rich Shepard
check_helo_access pcre:/etc/postfix/helo_checks

check this twice or more. check it with
helo=216.99.206.23.
If I were you, I'd just reject naked IP helo's. and
since you do reject_non_fqdn_hostname, I see no
reason to accept naked IPs in helo.

pcre:/etc/postfix/helo_checks
550 Don't use my IP address.
If I correctly understand the application of
helo_checks, this means that
the unknown IP address that tried to spoof my IP
address would receive a
rejection with the above additional text. Is this
correct?

The client should have received the whole "550 Don't
use my IP address" message.
This is another good clue. The message is whitelisted
before this check.
So now you know the problem is above this.

You have rather complex restrictions, but I'm sure
that this problem is resolvable if you are willing to
keep at it.
Next step in debugging: Use telnet and XCLIENT to
duplicate the session that got through, use
debug_peer_list to log what's happening.
http://www.postfix.org/XCLIENT_README.html
http://www.postfix.org/postconf.5.html#debug_peer_list