On 2/12/2014 8:48 AM, L. D. James wrote:
>
> On 02/12/2014 09:26 AM, Viktor Dukhovni wrote:
>> On Wed, Feb 12, 2014 at 02:21:04PM +0000, Viktor Dukhovni wrote:
>>
>>>> 127.0.0.1 is YOUR MACHINE NOT A REMOTE CLIENT.
>>> Perhaps the OP's amavis is misconfigured to accept remote SMTP
>>> clients
>>> without access control:
>>>
>>> Feb 11 16:40:42 hera5 amavis[32622]: (32622-04) Passed CLEAN
>>> {RelayedOpenRelay}, [72.9.103.50]:5850 [72.9.103.50]
>>>
>>> <bounce+a=ACCOUNT2-c=021114CHRISFAULKNERE-e=criterion=apollo3....@am0.net>
>>>
>>> -> <[email protected]>, Queue-ID: 886561514D8,
>>> Message-ID:
>>> <[email protected]>,
>>> mail_id: mf2_uVscaH5z, Hits: -1.901, size: 7991,
>>> queued_as: 174F71553D7, 2445 ms
>>>
>>> If 72.9.103.50 is a remote IP address, then the OP has misconfigured
>>> amavis to listen on remotely visible IP addresses and to accept
>>> mail from remote SMTP clients.
>>>
>>> Perhaps that's what the "RelayedOpenRelay" bit is about in the log
>>> entry. The fact that Amavis then uses a local "HELO" name is not
>>> surprising.
>>>
>>> The fix is to not aim the amavis shotgun at foot.
>> Except that in this case (sorry about noise), the message origin
>> was local:
>>
>> Feb 11 16:40:42 hera5 postfix/smtp[4726]: 886561514D8:
>> to=<[email protected]>, relay=127.0.0.1[127.0.0.1]:10024,
>> delay=3.5, delays=1.1/0.01/0/2.4, dsn=2.0.0, status=sent
>> (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025):
>> 250 2.0.0 Ok: queued as 174F71553D7)
>>
>> So the OP has to track down the origin of queue-id 886561514D8.
>>
> Hi, Viktor the tracking information you questioned is all in the
> log. The message origin is *216.244.76.231*. That is a remote
> machine. THe remote machine is answering the "helo" request, saying
> they are "localhost.localdomain". They are lying.
Possible, but you haven't shown any evidence of this.
> Avis is
> configured correctly. Avis recognize the email is coming from a
> remote machine and reporting to the log that postfix is an openrelay
> in this case because it's letting that message get thought.
No, that's not how the amavis openrelay warning works.
>
> The message had gotten though because the remote machine reported
> they were me. That is a lie. Avis did it's job and checked for
> spam, but is telling me that I'm allowing local machine to relay
> messages, making the host appear to be an openrelay.
No, that's not how amavis checks mail.
>
> I'm glad to help you and the others understand what is happening.
> But I'll mention that I have resolved this current issue and will be
> posting the resolution after I have organized it well enough so that
> anyone else with this problem won't have such a hard time in using
> the "helo_access" feature.
Your evidence posted does not support your statements. That's likely
why you're having such trouble getting check_helo_access to work.
>
> If you do a quick Google search of "helo_access" it might become
> clearer to you what is happening. The messages are not coming from
> localhost.localdomain. The remote system is lying about who they are.
>
> Will you take a moment to look at:
>
> http://www.unixwiz.net/techtips/postfix-HELO.html
Ok, pretty straightforward. I've posted similar recipes here in the
past.
>
> It's very clear to me what is happening. I was just trying to
> figure out the best way of handling the problem. You seem to have
> the impression that because the remote machine told hera5 it was me
> (localhost.localdomain), the messages are from me, hera5. But they
> are not from hera5. Hera5 is just telling the log what is being
> exchanged between the machines.
Note that postfix *does not* log the HELO name for accepted mail.
What you see in the log is the client FCrDNS hostname and IP.
>
> Also, hera5 was accepting and delivering the mail as if it were
> originating from localhost.localdomain. That's the whole point of
> the spammer's scam.
No, that's not how postfix nor amavis work. Access is controlled by
the client IP -- very difficult to spoof -- and never by the HELO
hostname.
-- Noel Jones
>
> Look at the message in the link above. This should help you to
> understand what is happening. Again, I mentioned before that it's
> not forbidden by SMTP. Look at how the author of the link explains it:
>
> Text from link above:
> -------------------------------------------
> Even though it's "lying", it's not really forbidden by the SMTP
> protocol because it's not used for authentication. But because these
> lies are so easily detectable, we can ask the Postfix to turn away
> these spammer connections with very low risk of false positive.
> --------------------------------------------
>
> -- L. James
>
