On 02/12/2014 09:43 AM, li...@rhsoft.net wrote:
Am 12.02.2014 15:26, schrieb L. D. James:
On 02/12/2014 09:01 AM, li...@rhsoft.net wrote:
Am 12.02.2014 14:53, schrieb L. D. James:
On 02/12/2014 08:02 AM, Wietse Venema wrote:
L. D. James:
I have this in the log:
-----------------------------------------
Feb 11 21:42:41 hera5 postfix/smtpd[4802]: connect from
localhost.localdomain[127.0.0.1]
Feb 11 21:42:41 hera5 postfix/smtpd[4802]: 05AAE155460:
client=localhost.localdomain[127.0.0.1]
This is a connection from your content filter.
You need to look at the logging for connections from remote systems.
Hi, Wietse. Actually that isn't a connection from my content filter.
That is a log of how the remote system
answered my helo request.
The information (as per the topic header) is a lie
It's bogus information. The remote
system is lying to the request saying they are me
if this is *your* logfile, "hera5" is your machine then [127.0.0.1]
can't be a lie, can't come from a remote systemd and this connection
is coming *for sure* from whatever service on *your machine*
"smtpd" is *not* talking to a remote system and not saying "helo"
to a remote system
Hi. hera5 in my machine. It is the host. My host machine, hera5 is reporting
the information to the log. You
quoted the part where hera5 (the host machine) reported what the click said
when hera5 gave a helo request. The
client lied. The client said they were "localhost.localdomain
*damned* read the other answers and stop to claim technical nonsense about
a "lying client" in case of [127.0.0.1] which is a IP-ADDRESS, yours, your
loopback device, a service running *on your machine* FOR SURE
your problem is long before *that service on localhost* accepts the message
from where you are showing logs, you must not accept the message at the MX
The client machine is lying to hera5 because the spammers knows that,
by default a machine will accept relaying messages from itself
*not by default it does NOT*
only the ones configured careless, dangerous and wrong
and the documentation states clearly you *must not* accept a message
by "check_helo_access" and have to have *other sane* restrictions
which reject *before* "check_helo_access" has the chance to say "permit"
in that case (a sane configuration) "check_helo_access" is the last
instance who could say *reject* but never override other restrictions
and accept the message
_______________________________________________
http://www.postfix.org/SMTPD_ACCESS_README.html
The problem with this configuration is that smtpd_recipient_restrictions
evaluates to PERMIT for EVERY host that
announces itself as "localhost.localdomain", making Postfix an open relay for
all such hosts.
With Postfix before version 2.10 you should place non-recipient restrictions
AFTER the reject_unauth_destination
restriction, not before. In the above example, the HELO based restrictions
should be placed AFTER
reject_unauth_destination, or better, the HELO based restrictions should be
placed under smtpd_helo_restrictions
where they can do no harm.
I appreciate that you have done some investigating and are starting to
realize the messages are not coming from my host smtp server, hera5. I
also appreciate all the input and concerns. Your message this time,
being more familiar with the problem, if very informative. You'll
actually starting to touch upon the solution that I had discovered... as
what I have already mentioned that I'm organizing to post back to the
list for others with the problem to be able to easily understand and fix.
I didn't understand the details of the order that you posted before. I
learned it thought trial an error. The examples I had found and had
been using didn't make it clear.
Thanks again for the input. When I post how I resolved the issue, I'll
also appreciate any assistance in fine tunning it. Again, the gist of
the problem is the the remote system is lying to the host server and my
question was how to handle that instant. Your current message (and
Noel's first message which referenced fixing the functionality of the
helo_access entry).
-- L. James
--
L. D. James
lja...@apollo3.com
www.apollo3.com/~ljames
