On Thursday, January 31, 2013 03:29:31 PM John Allen wrote:
> On 31/01/2013 6:59 AM, Muhammad Yousuf Khan wrote:
> > i wanted to have an experienced suggestion from Pros. i have been
> > going through from different steps deploying clamav and spamassassin,
> > one is "mailscanner" and seccond one is "clamd with clamsmtp"
> > in your expert opinion which one is the right track to choose. like
> > which one is efficient in perspective of hardware utilization /
> > resources utilization , complexity and more appropriate approach
> > towards stable deployment.
> >
> > Thanks
>
> Why not use Amavis-new as the mail scanner. It will handle the hand off
> to spamassassin and clamav and the return of scanned mail to postfix and
> there are several very good "How to"s on setting it up.

Personally, I use clamsmtp for virus scanning only and amavisd-new if the
requirement is for both virus and spam scanning.  They all have their
advantages.

It also depends a bit on what O/S distribution you're using.  In
Debian/Ubuntu, none of the people who maintain clamav use the milter so it
gets very light testing at the distribution level.

Scott K

Charles Marcus:
> Hello all,
>
> We finally ditched postini for MailDistiller for our anti-spam service,
> and are mostly happy, but we're having a problem receiving certain
> emails from a site affiliated with our Bank of America accounts...

Looking at mail that *is delivered* won't tell you what happened
with mail that is lost.

You need to find out which messages disappear down a black hole.

First, make sure local mail handling is sound: analyze Postfix logs
and find out if any received mail is not logged as delivered or
returned.

Second, mail may be lost up-stream. Set up a cron job that sends
one message each hour through your mail security provider, and look
at their arrival pattern: how much delay, how much never delivered.

	 Wietse

This was right on.  Thanks Wietse.

The rsyslogd service had rate limiting enabled by default and the log
lines were getting dropped.

I fixed it by adding the following line to /etc/rsyslog.conf

$SystemLogRateLimitInterval 0 # turn off rate limiting


________________________________________
Asa Gage
Senior Systems Engineer, NOC | Next Jump, Inc.
One Kendall Square, STE B2401, Cambridge, MA 02139
P: 617.682.4660 x5574 24/7: 617-682-4665
agage@... | oo.com

"BETTER Me+You=Us"
Check out our culture video http://nxj.me/nextjump


-----Original Message-----
From: wietse@... [mailto:wietse@...]
Sent: Wednesday, January 30, 2013 5:27 PM
To: Asa Gage
Cc: postfix-users@...
Subject: Re: Missing smtp delivery log event with smtp_tls_loglevel = 3

Asa Gage:
> I seem to be missing smtp log events regarding delivery status for TLS

> enabled mail when smtp_tls_loglevel = 3.  I see a ton of TLS data as
> expected, but the actual smtp result is no longer present.  Is there
> any explanation for this behavior?

syslog uses a connection-less transport.  The more logging you turn on,
the more events will be lost.

	 Wietse

On Fri, Feb 01, 2013 at 10:39:31AM -0500, Asa Gage wrote:

> This was right on.  Thanks Wietse.
>
> The rsyslogd service had rate limiting enabled by default and the log
> lines were getting dropped.
>
> I fixed it by adding the following line to /etc/rsyslog.conf
>
> $SystemLogRateLimitInterval 0 # turn off rate limiting

Still you never need a tls log level greater than 2 when doing
trouble-shoots or 1 in production. Log levels 3 and 4 are for
packet-level SSL traffic debugging by Postfix developers, to
diagnose potential issues in the SSL I/O plumbing, not for
general use. If you want to capture traffic, it is better
to use tcpdump not syslog.

While you may not want to have rate limits on syslog for other
reasons, the fix for this problem is to not set a tls log level of
3 or more in either the SMTP client or server.

--
	 Viktor.

On Sat, Feb 02, 2013 at 08:00:28AM +0400, arsen.shnurkov wrote:
> When I try to start, it writes "ok":
>
> |  # /etc/init.d/postfix start
>  * Starting postfix  ...
[ ok ]

That's the distro's init script. See what you get with "postfix -v
start". (But you'll probably need to use the init script in general;
consult your distributor's documentation for their Postfix package.)

> but 25-th port is not opened:
>
> |# ss -4l
> State      Recv-Q Send-Q                                             Local
Address:Port                                                 Peer Address:Port
> LISTEN     0      50                                                    
127.0.0.1:mysql                                                           *:*
> LISTEN     0      128
*:pop3                                                            *:*
> LISTEN     0      128
*:imap                                                            *:*
> LISTEN     0      128
*:http                                                            *:*
> LISTEN     0      128
*:ssh                                                             *:*
> LISTEN     0      128
*:https                                                           *:*
> |
>
> |I allowed all interfaces:
>
> # postconf -n | grep inet
> inet_interfaces = all
> inet_protocols = ipv4
> |
>
> # grep «smtp» /etc/postfix/master.cf
>
> |smtp      inet  n       -       n       -       -       smtpd -v
   ^
1. Is this pipe character really there? It should not be.
2. You do NOT want verbose logs. Remove the -v.

> smtp      unix  -       -       n       -       -       smtp
> relay     unix  -       -       n       -       -       smtp
>         -o smtp_fallback_relay=
> |
>
> Logs are empty, here is my syslog-ng setup:

This is what you must fix first.

> |# grep "mail" /etc/syslog-ng/syslog-ng.conf | grep -v "#"
> destination mail { file("/var/log/mail/mail.log"); };

Looks like /var/log/mail/mail.log is the file that should have your
mail.* syslog facility.priority logs. Did you delete it? Try
restarting the syslogd.

> destination mailinfo { file("/var/log/mail/mail.info"); };
> destination mailwarn { file("/var/log/mail/mail.warn"); };
> destination mailerr { file("/var/log/mail/mail.err"); };
> filter f_mail { facility(mail); };
> log { source(src); filter(f_mail); destination(mail); };
> log { source(src); filter(f_mail); filter(f_info); destination(mailinfo); };
> log { source(src); filter(f_mail); filter(f_warn); destination(mailwarn); };
> log { source(src); filter(f_mail); filter(f_err); destination(mailerr); };
> |
>
> my /etc/postfix/main.cf contains following:
>
> |# grep "my" /etc/postfix/main.cf

"postconf -n" is strongly preferred here.

> virtual_mailbox_domains=mysql:/etc/postfix/mysql/mysql-virtual-domains.cf
> virtual_mailbox_maps = mysql:/etc/postfix/mysql/mysql-virtual-maps.cf
> virtual_uid_maps = mysql:/etc/postfix/mysql/mysql-virtual-uid.cf
> virtual_gid_maps = mysql:/etc/postfix/mysql/mysql-virtual-gid.cf
> myhostname = mydomain.ru
> mydomain = mydomain.ru
> mydestination = localhost
> mynetworks = 192.168.9.0/24, 192.168.8.0/24, 192.168.7.0/24, 192.168.6.0/24,
127.0.0.0/8
> |
>
> What I should check in the first place?

Until you get the logs working there is little else we can say here.
--
   http://rob0.nodns4.us/ -- system administration and consulting
   Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

* arsen.shnurkov <arsen.shnurkov@...> [2013-02-02 08:00:28 +0400]:

> When I try to start, it writes "ok":
>
> |  # /etc/init.d/postfix start
>  * Starting postfix  ...
[ ok ]
> |
>
> but 25-th port is not opened:
>
> |# ss -4l
> State      Recv-Q Send-Q                                             Local
Address:Port                                                 Peer Address:Port
> LISTEN     0      50                                                    
127.0.0.1:mysql                                                           *:*
> LISTEN     0      128
*:pop3                                                            *:*
> LISTEN     0      128
*:imap                                                            *:*
> LISTEN     0      128
*:http                                                            *:*
> LISTEN     0      128
*:ssh                                                             *:*
> LISTEN     0      128
*:https                                                           *:*
> |
>
> |I allowed all interfaces:
>
> # postconf -n | grep inet
> inet_interfaces = all
> inet_protocols = ipv4
> |
>
> # grep «smtp» /etc/postfix/master.cf
>
> |smtp      inet  n       -       n       -       -       smtpd -v
> smtp      unix  -       -       n       -       -       smtp
> relay     unix  -       -       n       -       -       smtp
>         -o smtp_fallback_relay=

Have you enabled the "smtpd" line in the master.cf file - for incoming
connections:

smtp inet n - n - - smtpd

This is what enables the smtpd(8) daemon to listen for incoming tcp/25
connections

What I should check in the first place?

On Wed, 2013-01-30 at 14:23:19 -0500, Mike. wrote:

> I made some changes to the script based upon the excellent feedback I
> received here.
>
> The script no longer wanders beyond the postscreen log records in
> order to gather the information needed to determine the postscreen
> rejection rate.  So that removes the problems caused by
> multiple-recipient messages.
> ...

Be careful with grep(1) patterns.  You overstate CONNECTs by including
'NOQUEUE: reject: CONNECT' in the count.  Meanwhile, the script
understates total DNSBL rejections, which you measure with:

| grep -c "DNSBL rank [3-99]"

That bracket expression matches on a _single_ character, and does not
capture double-digit ranks.  A similar mistake occurs in the attempt to
aggregate 9+ ranks:

| grep -c "DNSBL rank [9-99] "

This only counts appearances of "DNSBL rank 9" in the log, as
illustrated below:

| % grep -c "DNSBL rank [9-99] " maillog
| 4494

| % grep -c "DNSBL rank 9 " maillog
| 4494

Review the re_format(7) and grep(1) manuals to improve understanding of
regular expressions.  In case it helps you, last year I had cobbled
together a slower (it is Python rather than a set of grep(1)
expressions) script[1] to collect similar statistics.  No promises that
it is error-free.

[1] http://people.freebsd.org/~sahil/scripts/mailstats.py.txt

--
Sahil Tandon

# postfix -v start
postfix: name_mask: ipv4
postfix: inet_addr_local: configured 5 IPv4 addresses
# ps -e | grep master
#
> Is this pipe character really there? It should not be.
no, it's artefact from mail, there is no such pipe characted in config
> You do NOT want verbose logs. Remove the -v.
ok, will do that later
>> Logs are empty
> This is what you must fix first.
What should I check? I tried to write test messages and they go to log without troubles:
# logger -p mail.warn "Mail warining"
# logger -p mail.info "Mail info"
# logger -p mail.error "Mail error"
# cat /var/log/mail/mail.log
Feb 2 20:08:25 test154 nobody: Mail warining
Feb 2 20:08:32 test154 nobody: Mail info
Feb 2 20:08:39 test154 nobody: Mail error

> Did you delete it?
No
> Try restarting the syslogd.
Did that before.
> "postconf -n" is strongly preferred here.
# postconf -n
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/lib64/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5
default_destination_concurrency_limit = 10
home_mailbox = .maildir/
html_directory = /usr/share/doc/postfix-2.6.5/html
inet_interfaces = all
inet_protocols = ipv4
local_destination_concurrency_limit = 2
mail_owner = postfix
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
mydestination = localhost
mydomain = mydomain.ru
myhostname = mydomain.ru
mynetworks = 192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24, 127.0.0.0/8
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.6.5/readme
sample_directory = /etc/postfix
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
unknown_local_recipient_reject_code = 550
virtual_gid_maps = mysql:/etc/postfix/mysql/mysql-virtual-gid.cf
virtual_mailbox_base = /home/vmail
virtual_mailbox_domains = mysql:/etc/postfix/mysql/mysql-virtual-domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql/mysql-virtual-maps.cf
virtual_uid_maps = mysql:/etc/postfix/mysql/mysql-virtual-uid.cf
> Until you get the logs working there is little else we can say here.
I think that syslog-ng works properly. It's postfix who doesn't start.
> How about a simple test to see if it running, ps  -A | grep master
no, it isn't running:
# ps  -A | grep master
#
> have you checked the mail log, and or the syslog to see if there is a problem with postfix.
nothing new in these logs

I have set up my smtpd restrictions as follows:

smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated
check_sender_access hash:/etc/postfix/whitelist reject_rbl_client
zen.spamhaus.org permit
smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks 
reject_unauth_destination check_policy_service unix:private/policy permit

Now, when some larger institutions, like Facebook and Amazon try to send mail,
it fails. For Amazon, they react to a 4xx error as to a 5xx error, they never
try to resend. Facebook presents me with another problem,

Feb  2 16:59:40 vanroodewierda postfix/smtpd[17722]: connect from
outmail023.snc4.facebook.com[66.220.144.157]
Feb  2 16:59:41 vanroodewierda postfix/smtpd[17722]: NOQUEUE: reject: RCPT from
outmail023.snc4.facebook.com[66.220.144.157]: 450 4.7.1
<facebook@...>: Recipient address rejected: Service is
unavailable; from=<password+kjdph3k_-7jd@...>
to=<facebook@...> proto=ESMTP helo=<mx-out.facebook.com>
Feb  2 16:59:46 vanroodewierda postfix/smtpd[17722]: disconnect from
outmail023.snc4.facebook.com[66.220.144.157]
Feb  2 17:06:56 vanroodewierda postfix/smtpd[18015]: connect from
outmail016.snc4.facebook.com[66.220.144.150]
Feb  2 17:06:57 vanroodewierda postfix/smtpd[18015]: NOQUEUE: reject: RCPT from
outmail016.snc4.facebook.com[66.220.144.150]: 450 4.7.1
<facebook@...>: Recipient address rejected: Service is
unavailable; from=<password+kjdph3k_-7jd@...>
to=<facebook@...> proto=ESMTP helo=<mx-out.facebook.com>
Feb  2 17:07:02 vanroodewierda postfix/smtpd[18015]: disconnect from
outmail016.snc4.facebook.com[66.220.144.150]

Every next time the attempt is made, it is made from a different server, so
until I have they whole farm of facebook in my DB it will not pass.

So, I need a whitelist. But how?

I tried adding something to client restrictions, but that does not work. I
obviously need something in the list of recipient restrictions. How can I tell
postfix to accept mail from facebook (above example) or Amazon (in general),
preferably with some form of regular expressions?

Thanks,

G

Gerben Wierda:
> smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks 
reject_unauth_destination check_policy_service unix:private/policy permit
>

To exclude some site from greylist checks, use an access table
*after* reject_unauth_destination and before the check_policy_service.

/etc/postfix/main.cf:
     smtpd_recipient_restrictions =
	 ...
	 reject_unauth_destination
	 check_client_access hash:/etc/postfix/client_access
	 check_policy_service unix:private/policy

/etc/postfix/client_access:
     amazon.com permit
     ...

The reason for having the whitelist after reject_unauth_destination
is that it is safe to use "permit" without becoming an open relay
(to avoid the latter problem, Postfix 2.10 recomments using
smtpd_relay_restrictions for the mail relay policy, and
smtpd_recipient_restrictions for the spam policy).

	 Wietse

On 2/2/2013 at 9:52 AM Sahil Tandon wrote:

|On Wed, 2013-01-30 at 14:23:19 -0500, Mike. wrote:
|
|> I made some changes to the script based upon the excellent feedback
I
|> received here.
|>
|> The script no longer wanders beyond the postscreen log records in
|> order to gather the information needed to determine the postscreen
|> rejection rate.  So that removes the problems caused by
|> multiple-recipient messages.
|> ...
|
|Be careful with grep(1) patterns.  You overstate CONNECTs by including
|'NOQUEUE: reject: CONNECT' in the count.  Meanwhile, the script
|understates total DNSBL rejections, which you measure with:
|
|| grep -c "DNSBL rank [3-99]"
|
|That bracket expression matches on a _single_ character, and does not
|capture double-digit ranks.  A similar mistake occurs in the attempt
to
|aggregate 9+ ranks:
|
|| grep -c "DNSBL rank [9-99] "
|
|This only counts appearances of "DNSBL rank 9" in the log, as
|illustrated below:
|
|| % grep -c "DNSBL rank [9-99] " maillog
|| 4494
|
|| % grep -c "DNSBL rank 9 " maillog
|| 4494
|
|Review the re_format(7) and grep(1) manuals to improve understanding
of
|regular expressions.  In case it helps you, last year I had cobbled
|together a slower (it is Python rather than a set of grep(1)
|expressions) script[1] to collect similar statistics.  No promises
that
|it is error-free.
|
|[1] http://people.freebsd.org/~sahil/scripts/mailstats.py.txt
|
|--
|Sahil Tandon

  =============


Thanks for the feedback.

Dag & Dank Wietse,

Can I do perl regex, e.g.

outmail\d\d\d.snc\d.facebook.com permit

or globbing like

outmail*.snc4*.facebook.com

And secondly, I also get mail I want to leave through where the sender is an
operation like messagelabs, but I want to accept only certain senders using
messagelabs, e.g. apg.nl or apg-am.nl. So not so much the client but the from,
e.g.

@apg.nl permit

how do I do that?

G

On 2 Feb 2013, at 17:48, Wietse Venema wrote:

> Gerben Wierda:
>> smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks 
reject_unauth_destination check_policy_service unix:private/policy permit
>>
>
> To exclude some site from greylist checks, use an access table
> *after* reject_unauth_destination and before the check_policy_service.
>
> /etc/postfix/main.cf:
>    smtpd_recipient_restrictions =
>  ...
>  reject_unauth_destination
>  check_client_access hash:/etc/postfix/client_access
>  check_policy_service unix:private/policy
>
> /etc/postfix/client_access:
>    amazon.com permit
>    ...
>
> The reason for having the whitelist after reject_unauth_destination
> is that it is safe to use "permit" without becoming an open relay
> (to avoid the latter problem, Postfix 2.10 recomments using
> smtpd_relay_restrictions for the mail relay policy, and
> smtpd_recipient_restrictions for the spam policy).
>
>  Wietse

On 02/02/2013 11:25 AM, Gerben Wierda wrote:
> So, I need a whitelist. But how?
>
If you are using postgrey then you can add something to the white list
which can be found in/etc/postgrey (debian).
Might help
John A

Am 02.02.2013 18:45, schrieb John Allen:
>>> How about a simple test to see if it running, ps  -A | grep master
>>no, it isn't running:
>
> There is not much point in looking anywhere for a solution for problems, until
you have Postfix running.
> Try         "service postfix start"      what happens?

if you would have read the thread you would have
seen that sysvinit believes it is started and say OK

/usr/sbin/postfix -c /etc/postfix start
or maybe on older systems before UsrMove
/sbin/postfix -c /etc/postfix start

would be a better chance to get REALLY output

Actually, I'm still on

  /usr/libexec/postfix/greylist.pl

as I am using Mac OS X Server 10.6.8 and I haven't dared to upgrade to a higher
version of OS X Server as they were busy crippling it in many respects.

G

On 2 Feb 2013, at 18:51, John Allen wrote:

> On 02/02/2013 11:25 AM, Gerben Wierda wrote:
>> So, I need a whitelist. But how?
>>
> If you are using postgrey then you can add something to the white list which
can be found in/etc/postgrey (debian).
> Might help
> John A
>

Am 02.02.2013 19:37, schrieb Gerben Wierda:
> Actually, I'm still on
>
>  /usr/libexec/postfix/greylist.pl
>
> as I am using Mac OS X Server 10.6.8 and I haven't dared to upgrade to a
higher version of OS X Server as they were busy crippling it in many respects.

you are aware that OSX 10.6 does no longer get ANY SECURITY update
because 10.8 is out? why the hell do people run OSX for a server
and not care having one of the most insecure platforms connected
to the internet AS SERVER????

On 02/02/2013 1:16 PM, Reindl Harald wrote:
>
> Am 02.02.2013 18:45, schrieb John Allen:
>>>> How about a simple test to see if it running, ps  -A | grep master
>>> no, it isn't running:
>> There is not much point in looking anywhere for a solution for problems,
until you have Postfix running.
>> Try         "service postfix start"      what happens?
> if you would have read the thread you would have
> seen that sysvinit believes it is started and say OK
>
> /usr/sbin/postfix -c /etc/postfix start
> or maybe on older systems before UsrMove
> /sbin/postfix -c /etc/postfix start
>
> would be a better chance to get REALLY output
>
I agree, but it might be a nice idea to see what happens with manual
start. After all there is nothing in the logs that we have been told
about that say it  ever started, no matter what sysvint says.

What we have is :
      nothing listening on port 25, 465(?), 587.
      master does not appear in the output of ps, if Postfix is running I
would assume we should see it
      if you run "ps -A | grep master"

So what evidence is there that it was ever started, has it been added to
the init.
At the moment we have no evidence that it started, and certainly none
that it started successfully.

--> Gerben Wierda <gerben.wierda@...> [2013-02-02 19:37:41 +0100]:

> Actually, I'm still on /usr/libexec/postfix/greylist.pl
> as I am using Mac OS X Server 10.6.8 and I haven't dared to upgrade
> to a higher version of OS X Server as they were busy crippling it
> in many respects.

It's actually very easy to upgrade your Postfix installation by
compiling the source code. I have needed to do it numerous times,
it's worth getting into the habit of upgrading in this way if you're
using internet servers.

You can also use the Macports system. It will provide a way for you
to use the newer Macports Postfix and stop the Apple installed
Postfix using launchctl. It's all automated and practically idiot
proof.


--
Primary Key: 4096R/1D31DC38 2011-12-03
Key Fingerprint: A4B9 E875 A18C 6E11 F46D  B788 BEE6 1251 1D31 DC38

Just so there is no misunderstanding: I am unhappy running an older version that
is not updated with security fixes anymore and I had planned to upgrade before
now (but not immediately when 10.8 came out as 10.8.0 Server was not what you
say trustworthy. I skipped 10.7 server altogether because it is a disaster area.

I plan to upgrade asap to 10.8 server.

For now, I came up with:

smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated
check_client_access hash:/etc/postfix/whitelist_mtaclientdomains
reject_rbl_client zen.spamhaus.org permit
smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks
reject_unauth_destination check_client_access
hash:/etc/postfix/whitelist_mtaclientdomains check_policy_service
unix:private/policy permit

Which makes sure some clients are permitted before they end up in either RBL or
Policy. Just for you more experienced people: is this OK?

Does macports overwrite what Apple has provided or does it have its own separate
tree (like fink used to have, which means you get another job that is: keeping
the second tree up to date)?

G


On 2 Feb 2013, at 20:36, James Griffin wrote:

> --> Gerben Wierda <gerben.wierda@...> [2013-02-02 19:37:41 +0100]:
>
>> Actually, I'm still on /usr/libexec/postfix/greylist.pl
>> as I am using Mac OS X Server 10.6.8 and I haven't dared to upgrade
>> to a higher version of OS X Server as they were busy crippling it
>> in many respects.
>
> It's actually very easy to upgrade your Postfix installation by
> compiling the source code. I have needed to do it numerous times,
> it's worth getting into the habit of upgrading in this way if you're
> using internet servers.
>
> You can also use the Macports system. It will provide a way for you
> to use the newer Macports Postfix and stop the Apple installed
> Postfix using launchctl. It's all automated and practically idiot
> proof.
>
>
> --
> Primary Key: 4096R/1D31DC38 2011-12-03
> Key Fingerprint: A4B9 E875 A18C 6E11 F46D  B788 BEE6 1251 1D31 DC38

On 2/2/2013 11:10 AM, Gerben Wierda wrote:
> Dag & Dank Wietse,
>
> Can I do perl regex, e.g.
>
> outmail\d\d\d.snc\d.facebook.com permit
>
> or globbing like
>
> outmail*.snc4*.facebook.com

/etc/postfix/main.cf:
     smtpd_recipient_restrictions =
	 ...
         reject_unauth_destination
      -> check_client_access pcre:/etc/postfix/client_access
         check_policy_service unix:private/policy

/etc/postfix/client_access:
     /.*facebook\.com$/  permit
     ...

You may want to be more specific.  I made my example very generic as
your expression above seems to miss some of their outbound host rdns,
such as:  outappmail004.snc4.facebook.com

> And secondly, I also get mail I want to leave through where the sender is an
operation like messagelabs, but I want to accept only certain senders using
messagelabs, e.g. apg.nl or apg-am.nl. So not so much the client but the from,
e.g.
>
> @apg.nl permit
>
> how do I do that?

You can also do this with a PCRE table.  If by "from" you mean MAIL
FROM, then check_sender_access is what you want:

http://www.postfix.org/postconf.5.html#check_sender_access

So in the example above, directly after check_client_access, you'd have:

         check_sender_access pcre:/etc/postfix/sender_access

and a file with expressions something like:

/etc/postfix/sender_access
     /.*@apg\.nl$/  permit
     ...

--
Stan

On 2/2/2013 1:55 PM, Gerben Wierda wrote:
> Just so there is no misunderstanding: I am unhappy running an older version
that is not updated with security fixes anymore and I had planned to upgrade
before now (but not immediately when 10.8 came out as 10.8.0 Server was not what
you say trustworthy. I skipped 10.7 server altogether because it is a disaster
area.
>
> I plan to upgrade asap to 10.8 server.
>
> For now, I came up with:
>
> smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated
check_client_access hash:/etc/postfix/whitelist_mtaclientdomains
reject_rbl_client zen.spamhaus.org permit
> smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks
reject_unauth_destination check_client_access
hash:/etc/postfix/whitelist_mtaclientdomains check_policy_service
unix:private/policy permit

That's awfully difficult to read.  Try putting each on its own line as
in the examples we've given you.  Also, put everything under

smtpd_recipient_restrictions

and eliminate smtpd_client_restrictions altogether.  Now you no longer
have to duplicate restrictions between them.  More importantly, you have
fine grained control over evaluation order.  Thus, this would be much
better:

smtpd_recipient_restrictions =
    permit_mynetworks
    permit_sasl_authenticated
    reject_unauth_destination
    check_client_access pcre:/etc/postfix/client_access
    check_sender_access pcre:/etc/postfix/sender_access
    reject_rbl_client zen.spamhaus.org
    check_policy_service unix:private/policy
    ...

/etc/postfix/client_access:
     /.*facebook\.com$/  permit
     ...

/etc/postfix/sender_access
     /.*@apg\.nl$/  permit
     ...

> Which makes sure some clients are permitted before they end up in either RBL
or Policy. Just for you more experienced people: is this OK?

When using separate client and recipient restrictions, as you have
above, your rbl check against Zen can trigger before your whitelist
checks, causing a rejection.  Using the method I've detailed above
avoids this situation.  Because Postfix performs delayed rejection by
default, you can put all of your restrictions under
smtpd_recipient_restrictions and carefully control the order of
restriction evaluations.  I'd guess that every experienced OP on this
list does it this way.  It just doesn't make any sense to do otherwise.

> Does macports overwrite what Apple has provided or does it have its own
separate tree (like fink used to have, which means you get another job that is:
keeping the second tree up to date)?

I have zero experience with MacOS.  Sorry.

--
Stan

On Sat, Feb 02, 2013 at 03:34:30PM -0600, Stan Hoeppner wrote:

>    check_client_access pcre:/etc/postfix/client_access
>    ...
>
> /etc/postfix/client_access:
>     /.*facebook\.com$/  permit

This is not robust for two reasons, the first is a simple oversight,
replace:

	 /.*facebook\.com$/  permit

with

	 /\.facebook\.com$/  permit

since "notfacebook.com" is not "facebook.com" and any SMTP client
in the real facebook.com domain would be a proper sub-domain.

The second issue is not easy to fix, transient DNS lookup errors
(timeouts, ...) may result in a client hostname of "unknown" rather
than <mumble>.facebook.com. In such cases the whitelist entry will
not apply. Generally this is a problem as messages may be erroneously
rejected due to a transient error.  In this case, provided the whitelist
entry is solely to avoid greylisting, this is OK, since greylisting
is responds with temporary (4XX) error codes.

--
	 Viktor.

On 2/2/2013 3:50 PM, Viktor Dukhovni wrote:
> On Sat, Feb 02, 2013 at 03:34:30PM -0600, Stan Hoeppner wrote:
>
>>    check_client_access pcre:/etc/postfix/client_access
>>    ...
>>
>> /etc/postfix/client_access:
>>     /.*facebook\.com$/  permit
>
> This is not robust for two reasons, the first is a simple oversight,
> replace:

It wasn't intended to be robust Viktor, but quite the opposite.

>  /.*facebook\.com$/  permit
>
> with
>
>  /\.facebook\.com$/  permit
>
> since "notfacebook.com" is not "facebook.com" and any SMTP client
> in the real facebook.com domain would be a proper sub-domain.

I guess you missed what came directly after that...

On 2/2/2013 3:08 PM, Stan Hoeppner wrote:
> You may want to be more specific.  I made my example very generic as
> your expression above seems to miss some of their outbound host rdns,
> such as:  outappmail004.snc4.facebook.com

Sometimes, when a kid asks for an apple, it's better to give him a
rotten one, so as to teach him to pick his own fresh apples from the
tree.  I.e. I gave him a rotten example of a regex hoping/assuming he'd
do some legwork and create his own set of fully qualified expressions to
meet his needs.

--
Stan

> What we have is :
>     nothing listening on port 25, 465(?), 587.
>     master does not appear in the output of ps, if Postfix is running
> I would assume we should see it
>     if you run "ps -A | grep master"
>
> So what evidence is there that it was ever started, has it been added
> to the init.
> At the moment we have no evidence that it started, and certainly none
> that it started successfully.

The source of error was the old configuration script.
I found this with strace log file - http://bpaste.net/show/74653/

line 229:

execve("/usr/lib64/postfix/postfix-script",
["/usr/lib64/postfix/postfix-script", "start"], [/* 18 vars */]) = -1
ENOEXEC (Exec format error)


Distribution maintainers move directory, but I didn't update script
properly.

Old script has
daemon_directory = /usr/lib64/postfix
now it is
daemon_directory = /usr/libexec/postfix

--> Gerben Wierda <gerben.wierda@...> [2013-02-02 20:55:42 +0100]:

> Just so there is no misunderstanding: I am unhappy running an
> older version that is not updated with security fixes anymore and
> I had planned to upgrade before now (but not immediately when 10.8
> came out as 10.8.0 Server was not what you say trustworthy. I skipped
> 10.7 server altogether because it is a disaster area. I plan
> to upgrade asap to 10.8 server.

Sure, I can understand that.

> Does macports overwrite what Apple has provided or does it have
> ts own separate tree (like fink used to have, which means you get
> another job that is: keeping the second tree up to date)?

No, Macports does not overwrite what Apple has installed and yes,
it does use its own separate filesystem as Fink does; it's under
/opt/local. However, they do specify that have programs installed
in /usr/local (i.e. manually installed or otherwise) causes issues
when using Macports. Totally OT, sorry about that.

It does provide you a way of keeping installed programs up-to-date
which is why I suggested it. You simply use launctl/Launchd to
select which MTA you use; i.e. the Macports installed version or
the Apple preinstalled version.

On 2/2/2013 at 9:52 AM Sahil Tandon wrote:

|Be careful with grep(1) patterns.  You overstate CONNECTs by
|including 'NOQUEUE: reject: CONNECT' in the count.

I tightened up that regex to include only the CONNECT occurrences I
want.



| Meanwhile, the script
| understates total DNSBL rejections,...
|
|A similar mistake occurs in the attempt to
|aggregate 9+ ranks:
  =============

I fixed both of those.


Version 1.4 of the pslogscan.sh script, incorporating the above fixes,
is available at:
http://archive.mgm51.com/sources/pslogscan.html


Thanks again for your feedback.

Hi folks,

I ran across a problem when installing postfix 2.9.5 on Solaris 10 and
11. If there is a pre-existing main.cf on the system then the "make
install" step will re-use this, instead of using the settings
contained in the new 2.9.5 code tree.

It makes installing a new version problematic as you don't expect that
sort of behaviour, old configs polluting new code. It's billed as a
"transition aid" but it's annoying when you go out of your way to
configure the postfix source tree to use other settings.

Thanks,
Mark.

postfix-install:
CONFIG_PARAMS="command_directory daemon_directory data_directory \
html_directory mail_owner mailq_path  manpage_directory newaliases_path \
queue_directory readme_directory sendmail_path setgid_group"

# Extract parameter settings from the installed main.cf file.

test -f $CONFIG_DIRECTORY/main.cf && {
     for name in $CONFIG_PARAMS sample_directory
     do
     eval junk=\$$name
     case "$junk" in
     "") eval unset $name;;
     esac
     eval : \${$name=\`bin/postconf -c $CONFIG_DIRECTORY -h $name\`} ||
         exit 1
     done
}

host:/var/tmp/postfix-2.9.5 root# sh -x postfix-install
+ umask 022
+
PATH=/bin:/usr/bin:/usr/sbin:/usr/etc:/sbin:/etc:/usr/contrib/bin:/usr/gnu/bin:/\
usr/ucb:/usr/bsd
+ SHELL=/bin/sh
[...]
+ echo Please specify the final destination directory for installed
Postfix configuration files.
Please specify the final destination directory for installed Postfix
configuration files.
+ eval echo '$n' 'config_directory: [$config_directory]\  $c'
+ echo config_directory: '[/usr/local/etc/postfix] ' '\c'
config_directory: [/usr/local/etc/postfix]  + read ans
+ break
+ install_root=''
+ test -z ''
+ CONFIG_DIRECTORY=/usr/local/etc/postfix
+ grep setgid_group /usr/local/etc/postfix/main.cf
+ 1> /dev/null 2>& 1
+ CONFIG_PARAMS='command_directory daemon_directory data_directory
html_directory mail_owner mailq_path  manpage_directory
newaliases_path queue_directory readme_directory sendmail_path
setgid_group'
+ test -f /usr/local/etc/postfix/main.cf
+ eval junk='$command_directory'
+ junk=''
+ eval unset command_directory
+ unset command_directory
+ eval : '${command_directory=`bin/postconf' -c /usr/local/etc/postfix
-h 'command_directory`}'
+ bin/postconf -c /usr/local/etc/postfix -h command_directory
+ : /usr/local/sbin
+ eval junk='$daemon_directory'
+ junk=''
+ eval unset daemon_directory
+ unset daemon_directory
+ eval : '${daemon_directory=`bin/postconf' -c /usr/local/etc/postfix
-h 'daemon_directory`}'
+ bin/postconf -c /usr/local/etc/postfix -h daemon_directory
+ : sourced_from_legacy_file
+ eval junk='$data_directory'
+ junk=''
+ eval unset data_directory
+ unset data_directory
+ eval : '${data_directory=`bin/postconf' -c /usr/local/etc/postfix -h
'data_directory`}'
+ bin/postconf -c /usr/local/etc/postfix -h data_directory
+ : /usr/local/var/postfix
+ eval junk='$html_directory'
+ junk=''
+ eval unset html_directory
+ unset html_directory
+ eval : '${html_directory=`bin/postconf' -c /usr/local/etc/postfix -h
'html_directory`}'
+ bin/postconf -c /usr/local/etc/postfix -h html_directory