On 8/4/2013 10:13 PM, Ronald F. Guilmette wrote:
> In message <51ff13eb.8090...@megan.vbhcs.org>, 
> Noel Jones <njo...@megan.vbhcs.org> wrote:
> 
>> On 8/4/2013 8:06 PM, Ronald F. Guilmette wrote:
>>> Does reject_non_fqdn_helo_hostname, when placed in the
>>> smtpd_helo_restrictions, permit clients to HELO/EHLO
>>> with a square-bracket enclosed dotted quad IPv4 address?
>>
>> Yes.
> 
> The documentatation should probably be adjusted to make that more clear.
> Right now it reads:
> 
>      Reject the request when the HELO or EHLO hostname is not in fully-
>      qualified domain form, as required by the RFC. 

You'll find elsewhere in the Postfix documentation and in RFC that
address literals must be accepted.

>>> If so, is the dotted quad checked to see that it properly
>>> represents the actual IP address of the actual current client?
>>
>> No.
> 
> Is there any restriction verb that would cause a HELO/EHLO which specifies
> a square-bracketed dotted quad IPv4 address to be rejected when & if the
> dotted quad does not match the actual current client IP address?

No.  You would need to use a policy daemon for something like this.

> Would reject_unknown_helo_hostname do it?  

No.  This rejects when no DNS A or MX record exists for the HELO string.
 This test is skipped for address literals.

> If not maybe a new restriction
> verb would be useful to perform this exact check.

Maybe you should explain why you're having a problem rejecting spamware
that HELO's with an IP literal.  If rejecting based on a HELO string is
your last line of defense you're in trouble Ron.  Surely a spamfighter
of your experience isn't pinning his hopes on HELO. ;)

If your IP literal HELO problem is indeed bot ware, then using
Postscreen will stop these clients, before they have a chance to HELO.

>>> Certainly, some spam
>>> that I believe should have been rejected on the basis of one or another
>>> of the above RHS filters I am instead seeing (in my maillog file) being
>>> rejected instead by one or another of the subsequent reject_rbl_client
>>> filters.   What could I be doing wrong?
>>
>> Doing RBL client checks in postscreen?
> 
> I am not using postscreen at the present time.
> 
> Do I need to use that if I want to perform RHSBL checks?

No, they are independent of one another.  But if you want to easily stop
bots Postscreen is the way to go.  DNSBL checks in Postscreen are
feature creep, they are not required.  I.e. you can setup default
Postscreen to stop bots and still do your reject_rbl_* checks in
smtpd_client_restrictions.

With your current setup and described problem you could simply remark
all of your reject_rbl_client statements temporarily and see if your
reject_rhsbl_* statements catch anything.

-- 
Stan

Reply via email to