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.
How are you doing, Noel. You're very right about my being a novice with
some of these concepts and not fully understanding all the inter
workings of postfix. That is why I posted what I have and asked for
suggestions.
Some of my explanations and interpretations may not be the most
technical definitive. However, it's very clear to me that the logs make
it appear that spam messages that are coming from somewhere else are
originating from my machine and because of that, the messages were being
delivered to my users.
I have used helo_access to block the emails and now those messages are
not coming to my users. My use of helo_access might be crude, but it
works. I asked for support and assistance, and appreciate the
feedback. I primarily appreciate your original message which appeared
to me to have suggested that I was on the right track. I followed that
track and now my inbox is so clean I had to spend a lot of time sending
email from various accounts and have my users do the same, to make sure
the service was still working.
I'm grateful for the input.
-- L. James
--
L. D. James
lja...@apollo3.com
www.apollo3.com/~ljames
