[OpenIndiana-discuss] Qmail-to-go on openindiana?

[Gary Gendel]

On 4/26/12 11:54 AM, låzaro wrote:
>
> Thread name: "Re: [OpenIndiana-discuss] Qmail-to-go on openindiana?"
> Mail number: 33
> Date: Thu, Apr 26, 2012
> In reply to: Gary Gendel<gary at genashor.com>
>> Chris, I'm still unclear on how to do this.  How could you write a
>> regular express to check to see if the connecting ip address is
>> buried in the reverse dns lookup.
>>
>> In my example, spamdyke would reject
>> customer.208.001_48.3.sample.com, but
>> customer.108.001_48.3.sample.com would not be rejected because it
>> doesn't match the ip address of the sending MTA.  This prevents
>> rejecting reverse dns names with strings of arbitrary numbers in
>> them.
>>
>> Gary
> Gary, is very simple, is maked, you don have to do nothing, just tell
> postfix "do this"
>
> add this to you main.cf
>
> smtpd_recipient_restrictions =
>      reject_unknow_sender_domain
>
> Postfix will make a reverse lookup and if the domain not found, it will
> not allow get the mail.
This is a completely different check.  In spamdyke this would be a 
poor-man's reject-missing-sender-mx option.  I'm talking about the 
spamdyke ip-in-rdns-keyword-whitelist-file and 
ip-in-rdns-keyword-blacklist-file options which allow you to specify 
which domains you will or will not allow the connecting MTA's ip address 
to be embedded in.  This catches a LOT of bot spam from ISPs that return 
this format for all the ip addresses that have no domain assigned.  For 
example a bot in the comcast network may resolve to this:

c-98-221-123-33.hsl1.nj.comcast.net

So I can just add ".comcast.net" to my ip-in-rdns-keyword-blacklist-file 
file and any bot from the comcast.net domain will be rejected.  It's a 
very directed search as it won't reject an arbitrary number string in 
the sequence and deals with comcast's use of various "dot" levels in the 
domain returned based upon the subnet.
>
> Also you can tell postfix who request to the remote server if that
> sender is a valid user, if it not exist i the remote server, the mail
> will not pass.
This is a problematic thing to do as many servers do not support this 
functionality.  I gave that approach up years ago because it adds delays 
for non-deterministic benefits.

Gary