Are my basic definitions wrong? ip blocks in hash for check_sender_access

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Are my basic definitions wrong? ip blocks in hash for check_sender_access

Robert Lopez
My understanding of client and sender are these:
Client: An application used to send, receive e-mail messages.
Sender: The from or sender "name" in the header that shows who (is
claimed to have) sent the email.

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
[hidden email] 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 <[hidden email]>;
Sun, 27 Sep 2009 17:56:16 -0600 (MDT) from unknown[64.94.244.50];
from=<[hidden email]> to=<[hidden email]> proto=SMTP
helo=<av7.experience.com>

Sep 27 17:56:19 mgxx postfix/cleanup[22432]: 596A81FFCD: message-
id=<[hidden email]>

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=<[hidden email]>
to=<[hidden email]> 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=<[hidden email]>, size=33955, nrcpt=1 (queue active)

Sep 27 17:56:22 mgxx postfix/smtp[23167]: C98C42016A:
to=<[hidden email]>, orig_to=<[hidden email]>,
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.

--
Robert Lopez
Unix Systems Administrator
Central New Mexico Community College (CNM)
525 Buena Vista SE
Albuquerque, New Mexico 87106
Reply | Threaded
Open this post in threaded view
|

Re: Are my basic definitions wrong? ip blocks in hash for check_sender_access

Brian Evans - Postfix List
Robert Lopez wrote:
> My understanding of client and sender are these:
> Client: An application used to send, receive e-mail messages.
> Sender: The from or sender "name" in the header that shows who (is
> claimed to have) sent the email.
>
>  

Indeed.

> 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
>  
This is depreciated syntax equivalent to "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
>         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
> [hidden email] 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:
>  

You  are explicitly asking postfix to check a sender for the file
hash:/etc/postfix/sender_access.
This will never match an IP.
> 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
You may put check_client_access to point to the same map in order to
check for an IP.
This is discouraged as that map may be abused in the future. People love
putting all their eggs in one basket.
Abuse can occur if placed in recipient restriction before
reject_unauth_destination with an OK result.
The check_client_access can be placed in sender_restrictions if you like.
Reply | Threaded
Open this post in threaded view
|

Re: Are my basic definitions wrong? ip blocks in hash for check_sender_access

Robert Lopez
On Thu, Oct 1, 2009 at 11:02 AM, Brian Evans - Postfix List
<[hidden email]> wrote:
> Robert Lopez wrote:
<snip>
>> check_client_access=hash:/etc/postfix/access
>> smtpd_client_restrictions =
>>       permit_mynetworks
>>       hash:/etc/postfix/whitelist
>>
> This is depreciated syntax equivalent to "check_client_access
> hash:/etc/postfix/whitelist"

Brian which line is depreciated syntax?

>>       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
<snip>
>> 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:
>>
>
> You  are explicitly asking postfix to check a sender for the file
> hash:/etc/postfix/sender_access.


"...check a sender for the file..."
Are you confirming postfix looks only for a sender-name found in the
Reply-To: in the /etc/postfix/sender_access file?


> This will never match an IP.

Thank you for confirming that point.

>> 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
> You may put check_client_access to point to the same map in order to
> check for an IP.
> This is discouraged as that map may be abused in the future. People love
> putting all their eggs in one basket.
> Abuse can occur if placed in recipient restriction before
> reject_unauth_destination with an OK result.
> The check_client_access can be placed in sender_restrictions if you like.
>

I am not clear who you suggest may do the abuse, but I understand your
point is it is best to use separate files, each for a single purpose.

So is this the implementation you would suggest...
check_client_access=hash:/etc/postfix/access_domain
check_client_access=hash:/etc/postfix/access_ip

where the access_domain file has domain names and the access_ip file
has ip addresses?

This (from http://www.postfix.org/postconf.5.html) suggests a single
file can have multiple uses:
"check_client_access type:table
    Search the specified access database for the client hostname,
parent domains, client IP address, or networks obtained by stripping
least significant octets. See the access(5) manual page for details."
--
Robert Lopez
Unix Systems Administrator
Central New Mexico Community College (CNM)
525 Buena Vista SE
Albuquerque, New Mexico 87106
Reply | Threaded
Open this post in threaded view
|

Re: Are my basic definitions wrong? ip blocks in hash for check_sender_access

/dev/rob0
In reply to this post by Robert Lopez
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: <[hidden email]>

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
> [hidden email] 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 <[hidden email]>;
> Sun, 27 Sep 2009 17:56:16 -0600 (MDT) from unknown[64.94.244.50];
> from=<[hidden email]> to=<[hidden email]> proto=SMTP
> helo=<av7.experience.com>

A check_sender_access lookup only looked up "[hidden email]"
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
Reply | Threaded
Open this post in threaded view
|

Re: Are my basic definitions wrong? ip blocks in hash for check_sender_access

mouss-4
In reply to this post by Robert Lopez
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
> [hidden email] 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 [hidden email].

> 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 <[hidden email]>;
> Sun, 27 Sep 2009 17:56:16 -0600 (MDT) from unknown[64.94.244.50];
> from=<[hidden email]> to=<[hidden email]> proto=SMTP
> helo=<av7.experience.com>
>
> Sep 27 17:56:19 mgxx postfix/cleanup[22432]: 596A81FFCD: message-
> id=<[hidden email]>
>
> 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=<[hidden email]>
> to=<[hidden email]> 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=<[hidden email]>, size=33955, nrcpt=1 (queue active)
>
> Sep 27 17:56:22 mgxx postfix/smtp[23167]: C98C42016A:
> to=<[hidden email]>, orig_to=<[hidden email]>,
> 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.

Reply | Threaded
Open this post in threaded view
|

Are my basic definitions wrong? ip blocks in hash for check_sender_access

Stan Hoeppner
In reply to this post by Robert Lopez
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
> [hidden email] 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 <[hidden email]>;
> Sun, 27 Sep 2009 17:56:16 -0600 (MDT) from unknown[64.94.244.50];
> from=<[hidden email]> to=<[hidden email]> proto=SMTP
> helo=<av7.experience.com>
>
> Sep 27 17:56:19 mgxx postfix/cleanup[22432]: 596A81FFCD: message-
> id=<[hidden email]>
>
> 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=<[hidden email]>
> to=<[hidden email]> 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=<[hidden email]>, size=33955, nrcpt=1 (queue active)
>
> Sep 27 17:56:22 mgxx postfix/smtp[23167]: C98C42016A:
> to=<[hidden email]>, orig_to=<[hidden email]>,
> 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 | Threaded
Open this post in threaded view
|

Re: Are my basic definitions wrong? ip blocks in hash for check_sender_access

Robert Lopez
Thank you everyone for the excellent information.

> Don't do this. You seem to be following some outdated tutorial.

Old hardware running email gateways needed to be retired and replaced.
I was to keep the same functionality as was on the servers when I
arrived on this job. So, between not having prior knowledge about or
experience with any of the software (postfix, etc.), and being told to
minimize the performance changes to the systems I thought the safest
path was to just copy the master.cf and the main.cf. I ran into the
problem that I also had to replace created here "glue scripts" with
MailScanner. That forced me to make some changes, some which I
obviously did not fully understand. So, I appreciate the corrections.

> >       reject_rbl_client blackholes.five-ten-sg.com=127.0.0.4
> Yikes. That DNSBL doesn't have a very solid reputation.

I know. I know. I know. And I understand why. I am a member of a team
in which I am the junior member and the senior members all have an
attachment to five-ten because it stops so much spam. I do have to
deal with the over aggressive effects on a weekly basics. I loose on
this point.

> Also, DISCARD is a strange choice. Why not REJECT?

I am told there is a logging difference and a program written here is
looking at log files for those events. I will revisit this point.

>> 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.

root:/var/log# postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = yes
biff = no
bounce_size_limit = 1
config_directory = /etc/postfix
default_process_limit = 400
header_checks = regexp:/etc/postfix/header_checks
inet_interfaces = all
mailbox_size_limit = 0
masquerade_domains = $mydomain, cnm.edu, nmvc.org, nmvirtualcollege.org
max_use = 100
message_size_limit = 16777216
mydestination = $myhostname, $mydomain, localhost.localdomain,
cnm.edu, mail.cnm.edu, mg01.cnm.edu, mg02.cnm.edu, mg03.cnm.edu,
mg04.cnm.edu, mg05.cnm.edu, nmvc.org, mail.nmvc.org, mg01.nmvc.org,
mg02.nmvc.org, mg03.nmvc.org, mg04.nmvc.org, mg05.nmvc.org,
nmvirtualcollege.org, mail.nmvirtualcollege.org,
mg01.nmvirtualcollege.org, mg02.nmvirtualcollege.org,
mg03.nmvirtualcollege.org, mg04.nmvirtualcollege.org,
mg05.nmvirtualcollege.org, nmln.net, ideal-nm.org, ideal-nm.net,
idealnm.org, idealnm.net
myhostname = mg05.cnm.edu
mynetworks = 198.133.182.0/24, 198.133.181.0/24, 198.133.180.0/24,
172.16.0.0/12, 192.168.0.0/16, 10.0.0.0/8, 127.0.0.0/8
[::ffff:127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
notify_classes = resource,software
readme_directory = no
recipient_delimiter = +
relay_domains = $mydestination
relayhost =
smtp_host_lookup = dns, native
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = cnm.edu
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_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, reject_invalid_hostname
smtpd_recipient_restrictions = check_recipient_access
hash:/etc/postfix/overquota reject_non_fqdn_sender reject_unknown_sender_domain reject_non_fqdn_recipient reject_unknown_recipient_domain reject_unlisted_recipient permit_mynetworks reject_unauth_destination reject_unauth_pipeliningreject_invalid_helo_hostname
        reject_non_fqdn_helo_hostname reject_rbl_client zen.spamhaus.org
smtpd_sender_restrictions = check_sender_access
hash:/etc/postfix/greylist check_sender_access
hash:/etc/postfix/sender_access permit_mynetworks
        reject_unknown_sender_domain
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
virtual_alias_maps = hash:/etc/postfix/virtualaliases
root:/var/log#

> 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.

My understanding is that "uses direct access to the Postfix queue" is
an old issue that is no longer the case. In any event, I do not select
what we use.

--
Robert Lopez
Unix Systems Administrator
Central New Mexico Community College (CNM)
525 Buena Vista SE
Albuquerque, New Mexico 87106