Robert Lopez wrote:
> My understanding of client and sender are these:
> Client: An application used to send, receive e-mail messages.
No. the client is the IP node. so it's either the IP of the reverse DNS
of the host that is trying to send mail. regarding reverse dns, if it is
not "confirmed", then it is "unknown". a name is confirmed if
IP -> name -> IP
returns the original IP.
> Sender: The from or sender "name" in the header that shows who (is
> claimed to have) sent the email.
>
The sender in smtp is the address in the MAIL FROM command. This is
generally the address you seee in the Return-Path header, but this not
guaranteed (depends on the MTA). in "simple" cases, this also the
address that people use as From: or Reply-To: in their mailers, but
anybody can set whatever headers they want.
> 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
it is recommended to put the right check_foo_access, instead of relying
of the old implicit mode. here
check_client_access 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
it depends on your site, but in general, five-ten is way too aggressive.
> 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
>
avoid DISCARD. use REJECT instead.
> Does it also work correctly if that same files also has terms such as
> 64.94.244 DISCARD
no. check_sender_access applies to a sender address, which is something
like j...@example.com.
> where the intent is to block any of
> 64.94.244.xxx
> ?
for this, use check_client_access.
check_client_access hash:/etc/postfix/access_client
>
> 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.
>
whatever they were doing, use different checks for different goals.
while you can use a single file for both check_sender_access and
check_client_access, this is ugly at best.
note that you can put a check_sender_access under
smtpd_client_restrictions and a check_client_access under
smtpd_sender_restrictions. which brings you back to what Rob said: it
may be a good idea to put all your anti-spam checks under a single
smtpd_foo_restrictions.
