On Thursday 01 October 2009 11:47:47 Robert Lopez wrote:
> My understanding of client and sender are these:
> Client: An application used to send, receive e-mail messages.
In the context of check_client_access it means the IP address and/or
forward-confirmed reverse DNS name of the client application which
connects to smtpd(8) to send mail.
> Sender: The from or sender "name" in the header that shows who
> (is claimed to have) sent the email.
Header is irrelevant. Sender (for check_sender_access) is the address
used in the SMTP "MAIL FROM:" command. This message, for example, is
purportedly from me, but if you look at the header which your Postfix
added, you'll see it was not:
Return-Path: <owner-postfix-us...@postfix.org>
Oops, I see that you're probably reading the list from gmail, not
from your own Postfix, but likewise, the gmail MTA probably prepends
the Return-Path: header too.
> 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
Irrelevant, ignored. This is an example of why the list welcome
message asks for "postconf -n" and not lines from main.cf.
check_client_access is a restriction that can be used in any of the
various smtpd_*_restrictions stages. It does nothing where you put
that.
See http://www.postfix.org/SMTPD_ACCESS_README.html for an overview
of how access(5) restrictions work.
> smtpd_client_restrictions =
It's often recommended for simplicity to keep restrictions in a
single stage, and that stage would have to be
smtpd_recipient_restrictions, because that is where mandatory relay
control occurs.
When so doing, one must be careful about whitelisting. The README
aforementioned contains a warning. Whitelisting entries can be done
safely either after reject_unauth_destination, or using a
permit_auth_destination lookup result (rather than "OK" or permit.)
> permit_mynetworks
> hash:/etc/postfix/whitelist
Don't do this. You seem to be following some outdated tutorial. I see
that Brian has beat me to this explanation, so I'll leave it at what
he had to say about it.
> 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
Yikes. That DNSBL doesn't have a very solid reputation. I do hope you
know what you're doing! You should only use DNSBLs with which you are
familiar. (Personally, I do not use reject_rbl_client bl.spamcop.net
either, but many sites probably do.)
> 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
Two hash: maps doing the same type of lookup at the same point in
your restrictions does not make sense. I would either consolidate
these, or (more likely, given your confusion) reconsider the lookup
types.
> permit_mynetworks
> reject_unknown_sender_domain
I would reverse these. There's no point in accepting mail from your
users when these conditions exist:
1. No other site will accept it from you
2. You have no way to send a bounce to the sender
YMMV. If your DNS is fragile, a sender domain lookup might fail on
occasion, and you might prefer not to get calls from your confused
and/or upset users.
(To be precise, "permit_mynetworks" at the end of
smtpd_sender_restrictions is meaningless, since the default is to
permit anyway. It makes sense the way you have it; I just disagree.)
> To me the content of the sender_access hash makes sense if it
> contains terms such as
> luck...@yaha.com DISCARD
That's an email address, such as might be used as a sender address.
BTW, check_sender_access is not generally a very safe or useful tool
to use against spam. Most spam sender addresses are forged, and many
of those are real sender addresses: the "joe job". See
http://en.wikipedia.org/wiki/Joe_job - I don't like to help spammers
destroy the usability of email.
Also, DISCARD is a strange choice. Why not REJECT?
> 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
> ?
Seems to be confusion of your basic definitions, as per $SUBJECT. :)
> 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>
A check_sender_access lookup only looked up "no_re...@experience.com"
and "experience.com" in that example.
BTW the use of MailScanner with Postfix is not recommended and will
not be supported on this list. It uses direct access to the Postfix
queue, an undocumented and unsupported interface. There are other
content filter choices which do it properly; my recommendation is
amavisd-new.
> 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.
Perhaps the person who told you that would work (had been working)
was wrong. See access.5.html , "EMAIL ADDRESS PATTERNS", to see what
is looked up for check_sender_access.
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
