Robert Lopez put forth on 10/1/2009 11:47 AM:
> My understanding of client and sender are these:
> Client: An application used to send, receive e-mail messages.

In the context of Postfix client restrictions, the _client_ is the
remote SMTP server that is sending email to your Postfix server.  It is
defined as a client because it is initiating a connection to your
server.  (When your Postfix connects to a remote MTA to deliver mail,
your Postfix is the _client_).  Thus, any client restrictions you
implement are going to scrutinize the IP address and dns parameters
(mainly FQrDNS name) of the machine connecting to yours.  In short, any
machine connecting to your Postfix to deliver email is called a _client_.

Don't feel bad for misunderstanding this "client server" thing.  Many IT
folks suffer the same confusion when dealing with real MTAs for the
first time (and I don't mean M$ Exchange ;)).  Myself included.

--
Stan


> The context of the use that has me concerned are these:
> smtpd_client_restrictions and smtpd_sender_restrictions
> 
> I currently have these lines in main.cf:
> 
> check_client_access=hash:/etc/postfix/access
> smtpd_client_restrictions =
>       permit_mynetworks
>       hash:/etc/postfix/whitelist
>       reject_rbl_client zen.spamhaus.org
>       reject_rbl_client bl.spamcop.net
>       reject_rbl_client dnsbl.njabl.org
>       reject_rbl_client blackholes.five-ten-sg.com=127.0.0.4
>       reject_rbl_client blackholes.five-ten-sg.com=127.0.0.5
>       reject_rbl_client blackholes.five-ten-sg.com=127.0.0.6
>       reject_rbl_client blackholes.five-ten-sg.com=127.0.0.7
>       reject_rbl_client blackholes.five-ten-sg.com=127.0.0.8
>       reject_rbl_client blackholes.five-ten-sg.com=127.0.0.9
>       reject_rbl_client blackholes.five-ten-sg.com=127.0.0.10
>       reject_rbl_client blackholes.five-ten-sg.com=127.0.0.11
>       reject_rbl_client blackholes.five-ten-sg.com=127.0.0.13
>         permit
> 
> smtpd_sender_restrictions =
>       check_sender_access hash:/etc/postfix/greylist
>       check_sender_access hash:/etc/postfix/sender_access
>       permit_mynetworks
>       reject_unknown_sender_domain
> 
> To me the content of the sender_access hash makes sense if it contains
> terms such as
> luck...@yaha.com      DISCARD
> 
> Does it also work correctly if that same files also has terms such as
> 64.94.244                       DISCARD
> where the intent is to block any of
> 64.94.244.xxx
> ?
> 
> Right now that ip address example shown above (64.94.244) is in the
> sender_access file (and the sender_access.db) but the log file shows
> events such as this:
> 
> Sep 27 17:56:19 mgxx postfix/cleanup[22432]: 596A81FFCD: hold: header
> Received: from av7.experience.com (unknown [64.94.244.50])??by
> mgxx.cnm.edu (Postfix) with SMTP id 596A81FFCD??for <gle...@cnm.edu>;
> Sun, 27 Sep 2009 17:56:16 -0600 (MDT) from unknown[64.94.244.50];
> from=<no_re...@experience.com> to=<xx...@cnm.edu> proto=SMTP
> helo=<av7.experience.com>
> 
> Sep 27 17:56:19 mgxx postfix/cleanup[22432]: 596A81FFCD: message-
> id=<27390832.651.1254095751632.javamail.r...@av7.experience.com>
> 
> Sep 27 17:56:19 mgxx postfix/cleanup[22432]: 596A81FFCD: warning:
> header Subject: eRecruiting Saved Search - Abq-Lots from
> unknown[64.94.244.50]; from=<no_re...@experience.com>
> to=<xx...@cnm.edu> proto=SMTP helo=<av7.experience.com>
> 
> Sep 27 7:56:22 mgxx MailScanner[9931]: Requeue: 596A81FFCD.2D1A1 to C98C42016A
> 
> Sep 27 17:56:22 mgxx postfix/qmgr[24665]: C98C42016A:
> from=<no_re...@experience.com>, size=33955, nrcpt=1 (queue active)
> 
> Sep 27 17:56:22 mgxx postfix/smtp[23167]: C98C42016A:
> to=<gle...@tvimail.cnm.edu>, orig_to=<gle...@cnm.edu>,
> relay=tvimail.cnm.edu[198.133.181.119]:25, delay=5.7,
> delays=5.6/0/0/0.03, dsn=2.5.0, status=sent (250 2.5.0 Ok.) Sep 27
> 17:56:22 mg05 postfix/qmgr[24665]: C98C42016A: removed
> 
> Based upon my understanding of the definitions of the terms I have
> always been uncertain about putting ip blocks in the same file. I have
> been told it has been working practice at this college for years
> before I got here. I need to be certain we are doing the right things.
> 

Reply via email to