Formatting problems for smptd_recipient_restrictions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
56 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: spf configuration woes

Benny Pedersen
On Fri, 4 Nov 2011 07:45:47 -0700, David Southwell wrote:
>  policyd-spf unix -       n       n       -       0       spawn
>           user=nobody argv=/usr/local/sbin/postfix-policyd-spf-perl

nobody have no write permissions in postfix private socket dir

> Nov  4 07:37:50 dns1 postfix/smtpd[26676]: warning: connect to
> private/policyd-spf: Connection refused

since sockert is missing
Reply | Threaded
Open this post in threaded view
|

Re: spf configuration woes

Wietse Venema
Benny Pedersen:
> On Fri, 4 Nov 2011 07:45:47 -0700, David Southwell wrote:
> >  policyd-spf unix -       n       n       -       0       spawn
> >           user=nobody argv=/usr/local/sbin/postfix-policyd-spf-perl
>
> nobody have no write permissions in postfix private socket dir

No, the Postfix master daemon creates the socket. it runs with
system privileges.

> > Nov  4 07:37:50 dns1 postfix/smtpd[26676]: warning: connect to
> > private/policyd-spf: Connection refused
>
> since sockert is missing

Yes, because of a master.cf configuration error.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: spf configuration woes

David Southwell
On Friday 04 November 2011 14:07:36 Wietse Venema wrote:

> Benny Pedersen:
> > On Fri, 4 Nov 2011 07:45:47 -0700, David Southwell wrote:
> > >  policyd-spf unix -       n       n       -       0       spawn
> > >  
> > >           user=nobody argv=/usr/local/sbin/postfix-policyd-spf-perl
> >
> > nobody have no write permissions in postfix private socket dir
>
> No, the Postfix master daemon creates the socket. it runs with
> system privileges.
>
> > > Nov  4 07:37:50 dns1 postfix/smtpd[26676]: warning: connect to
> > > private/policyd-spf: Connection refused
> >
> > since sockert is missing
>
> Yes, because of a master.cf configuration error.
>
> Wietse

Lets assume that is the case. If so can anyone please help me identify the
error? Grey listing is working. Relevant are:
1.master.cf &
2. main.cf are below. (main.cf is shown with the spf lines commented out.)

There are two versions of postconf -n:

3. Version 1 is when spf lines in main.cf are commented out.
4. Version 2 is when those lines are active.
5. Extracts from maillog showing results with the spf lines are turned on and
then when they are turned off

Search for '*****' to page down successively to each of the 5 relevant
extracts.

******master.cf****************************************
# Postfix master process configuration file.  For details on the format
# of the file, see the master(5) manual page (command: "man 5 master").
#
# Do not forget to execute "postfix reload" after editing this file.
#
# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================
smtp      inet  n       -       n       -       -       smtpd
#smtp      inet  n       -       n       -       1       postscreen
#smtpd     pass  -       -       n       -       -       smtpd
#dnsblog   unix  -       -       n       -       0       dnsblog
#tlsproxy  unix  -       -       n       -       0       tlsproxy
#submission inet n       -       n       -       -       smtpd
#  -o smtpd_tls_security_level=encrypt
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING
#smtps     inet  n       -       n       -       -       smtpd
#  -o smtpd_tls_wrappermode=yes
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING
#628       inet  n       -       n       -       -       qmqpd
pickup    fifo  n       -       n       60      1       pickup
cleanup   unix  n       -       n       -       0       cleanup
qmgr      fifo  n       -       n       300     1       qmgr
#qmgr     fifo  n       -       n       300     1       oqmgr
tlsmgr    unix  -       -       n       1000?   1       tlsmgr
rewrite   unix  -       -       n       -       -       trivial-rewrite
bounce    unix  -       -       n       -       0       bounce
defer     unix  -       -       n       -       0       bounce
trace     unix  -       -       n       -       0       bounce
verify    unix  -       -       n       -       1       verify
flush     unix  n       -       n       1000?   0       flush
proxymap  unix  -       -       n       -       -       proxymap
proxywrite unix -       -       n       -       1       proxymap
smtp      unix  -       -       n       -       -       smtp
# When relaying mail as backup MX, disable fallback_relay to avoid MX loops
relay     unix  -       -       n       -       -       smtp
        -o smtp_fallback_relay=
#       -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
showq     unix  n       -       n       -       -       showq
error     unix  -       -       n       -       -       error
retry     unix  -       -       n       -       -       error
discard   unix  -       -       n       -       -       discard
local     unix  -       n       n       -       -       local
virtual   unix  -       n       n       -       -       virtual
lmtp      unix  -       -       n       -       -       lmtp
anvil     unix  -       -       n       -       1       anvil
scache    unix  -       -       n       -       1       scache
#
# ====================================================================
# Interfaces to non-Postfix software. Be sure to examine the manual
# pages of the non-Postfix software to find out what options it wants.
#
# Many of the following services use the Postfix pipe(8) delivery
# agent.  See the pipe(8) man page for information about ${recipient}
# and other message envelope options.
# ====================================================================
#
# maildrop. See the Postfix MAILDROP_README file for details.
# Also specify in main.cf: maildrop_destination_recipient_limit=1
#
#maildrop  unix  -       n       n       -       -       pipe
#  flags=DRhu user=vmail argv=/usr/local/bin/maildrop -d ${recipient}
#
# ====================================================================
#
# Recent Cyrus versions can use the existing "lmtp" master.cf entry.
#
# Specify in cyrus.conf:
#   lmtp    cmd="lmtpd -a" listen="localhost:lmtp" proto=tcp4
#
# Specify in main.cf one or more of the following:
#  mailbox_transport = lmtp:inet:localhost
#  virtual_transport = lmtp:inet:localhost
#
# ====================================================================
#
# Cyrus 2.1.5 (Amos Gouaux)
# Also specify in main.cf: cyrus_destination_recipient_limit=1
#
#cyrus     unix  -       n       n       -       -       pipe
#  user=cyrus argv=/cyrus/bin/deliver -e -r ${sender} -m ${extension} ${user}
#
# ====================================================================
#
# Old example of delivery via Cyrus.
#
#old-cyrus unix  -       n       n       -       -       pipe
#  flags=R user=cyrus argv=/cyrus/bin/deliver -e -m ${extension} ${user}
#
# ====================================================================
#
# See the Postfix UUCP_README file for configuration details.
#
#uucp      unix  -       n       n       -       -       pipe
#  flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail
($recipient)
#
# ====================================================================
#
# Other external delivery methods.
#
#ifmail    unix  -       n       n       -       -       pipe
#  flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
#
#bsmtp     unix  -       n       n       -       -       pipe
#  flags=Fq. user=bsmtp argv=/usr/local/sbin/bsmtp -f $sender $nexthop
$recipient
#
#scalemail-backend unix -       n       n       -       2       pipe
#  flags=R user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store
#  ${nexthop} ${user} ${extension}
#
#mailman   unix  -       n       n       -       -       pipe
#  flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py
#  ${nexthop} ${user}

# Applied #1 postfix refereshed ok
 policyd-spf unix -       n       n       -       0       spawn
           user=nobody argv=/usr/local/sbin/postfix-policyd-spf-perl



____________________________________________________
****** For main.cf all comment lines have been removed except the two lines
****** for turning on spf
***********main.cf******************


soft_bounce = yes

queue_directory = /var/spool/postfix


command_directory = /usr/local/sbin


daemon_directory = /usr/local/libexec/postfix


mail_owner = postfix


myhostname = dns1.vizion2000.net

mydomain = vizion2000.net


myorigin = $mydomain


inet_interfaces = all

proxy_interfaces = dns1.vizion2000.net

mydestination = $mydomain, $myhostname, dns1.$mydomain, dns1


smtpd_recipient_restrictions = permit_mynetworks,reject_unauth_destination
# check_policy_service unix:private/policyd-spf
# spf-policy_time_limit = 3600s
 check_policy_service inet:127.0.0.1:10023

smtpd_sender_restrictions = reject_unknown_sender_domain
smtpd_sender_restrictions = reject_non_fqdn_sender

smtpd_helo_restrictions = reject_invalid_hostname

relay_domains = $mydestination

mynetworks_style = subnet

mynetworks = 62.49.197.48/28, 127.0.0.0/8

virtual_alias_domains = workplacemassage.co.uk, atf4.com,
methuselaproject.org, methuselaproject.com, tiptogo.com,
virtual_alias_maps= hash:/usr/local/etc/postfix/virtual,


alias_maps = hash:/etc/aliases

mail_spool_directory = /var/mail
 
mailbox_size_limit = 512000000

smtpd_banner = $myhostname ESMTP $mail_name ($mail_version)


debug_peer_level = 2


debugger_command =
         PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
         xxgdb $daemon_directory/$process_name $process_id & sleep 5



sendmail_path = /usr/local/sbin/sendmail


newaliases_path = /usr/local/bin/newaliases


mailq_path = /usr/local/bin/mailq


setgid_group = maildrop


html_directory = /usr/local/share/doc/postfix


manpage_directory = /usr/local/man


sample_directory = /usr/local/etc/postfix


readme_directory = /usr/local/share/doc/postfix
data_directory = /var/db/postfix
************
End of main.cf_______________________________________________________________



******postconf -n Version 1***************
alias_maps = hash:/etc/aliases
command_directory = /usr/local/sbin
config_directory = /usr/local/etc/postfix
daemon_directory = /usr/local/libexec/postfix
data_directory = /var/db/postfix
debug_peer_level = 2
html_directory = /usr/local/share/doc/postfix
inet_interfaces = all
mail_owner = postfix
mail_spool_directory = /var/mail
mailbox_size_limit = 512000000
mailq_path = /usr/local/bin/mailq
manpage_directory = /usr/local/man
mydestination = $mydomain, $myhostname, dns1.$mydomain, dns1
mydomain = vizion2000.net
myhostname = dns1.vizion2000.net
mynetworks = 62.49.197.48/28, 127.0.0.0/8
mynetworks_style = subnet
myorigin = $mydomain
newaliases_path = /usr/local/bin/newaliases
proxy_interfaces = dns1.vizion2000.net
queue_directory = /var/spool/postfix
readme_directory = /usr/local/share/doc/postfix
relay_domains = $mydestination
sample_directory = /usr/local/etc/postfix
sendmail_path = /usr/local/sbin/sendmail
setgid_group = maildrop
smtpd_banner = $myhostname ESMTP $mail_name ($mail_version)
smtpd_helo_restrictions = reject_invalid_hostname
smtpd_recipient_restrictions = permit_mynetworks,reject_unauth_destination
check_policy_service inet:127.0.0.1:10023
smtpd_sender_restrictions = reject_non_fqdn_sender
soft_bounce = yes
unknown_local_recipient_reject_code = 550
virtual_alias_domains = workplacemassage.co.uk, atf4.com,
methuselaproject.org, methuselaproject.com, tiptogo.com,
virtual_alias_maps = hash:/usr/local/etc/postfix/virtual,


************postconf -n Version 2 ***********
alias_maps = hash:/etc/aliases
command_directory = /usr/local/sbin
config_directory = /usr/local/etc/postfix
daemon_directory = /usr/local/libexec/postfix
data_directory = /var/db/postfix
debug_peer_level = 2
html_directory = /usr/local/share/doc/postfix
inet_interfaces = all
mail_owner = postfix
mail_spool_directory = /var/mail
mailbox_size_limit = 512000000
mailq_path = /usr/local/bin/mailq
manpage_directory = /usr/local/man
mydestination = $mydomain, $myhostname, dns1.$mydomain, dns1
mydomain = vizion2000.net
myhostname = dns1.vizion2000.net
mynetworks = 62.49.197.48/28, 127.0.0.0/8
mynetworks_style = subnet
myorigin = $mydomain
newaliases_path = /usr/local/bin/newaliases
proxy_interfaces = dns1.vizion2000.net
queue_directory = /var/spool/postfix
readme_directory = /usr/local/share/doc/postfix
relay_domains = $mydestination
sample_directory = /usr/local/etc/postfix
sendmail_path = /usr/local/sbin/sendmail
setgid_group = maildrop
smtpd_banner = $myhostname ESMTP $mail_name ($mail_version)
smtpd_helo_restrictions = reject_invalid_hostname
smtpd_recipient_restrictions = permit_mynetworks,reject_unauth_destination
check_policy_service unix:private/policyd-spf spf-policy_time_limit = 3600s
check_policy_service inet:127.0.0.1:10023
smtpd_sender_restrictions = reject_non_fqdn_sender
soft_bounce = yes
unknown_local_recipient_reject_code = 550
virtual_alias_domains = workplacemassage.co.uk, atf4.com,
methuselaproject.org, methuselaproject.com, tiptogo.com,
virtual_alias_maps = hash:/usr/local/etc/postfix/virtual,

**********maillog***********
**********turning on spf lines produces:
Nov  5 03:05:31 dns1 postfix/postfix-script[27976]: refreshing the Postfix
mail system
Nov  5 03:05:31 dns1 postfix/master[1324]: reload -- version 2.8.5,
configuration /usr/local/etc/postfix
Nov  5 03:05:31 dns1 postfix/anvil[27956]: statistics: max connection rate
1/60s for (smtp:209.85.213.58) at Nov  5 03:02:30
Nov  5 03:05:31 dns1 postfix/anvil[27956]: statistics: max connection count 1
for (smtp:209.85.213.58) at Nov  5 03:02:30
Nov  5 03:05:31 dns1 postfix/anvil[27956]: statistics: max cache size 2 at Nov  
5 03:03:51
Nov  5 03:06:49 dns1 postfix/smtpd[27987]: connect from mail-vx0-
f186.google.com[209.85.220.186]
Nov  5 03:06:49 dns1 postfix/smtpd[27987]: warning: connect to
private/policyd-spf: Connection refused
Nov  5 03:06:49 dns1 postfix/smtpd[27987]: warning: problem talking to server
private/policyd-spf: Connection refused
Nov  5 03:06:50 dns1 postfix/smtpd[27987]: warning: connect to
private/policyd-spf: Connection refused
Nov  5 03:06:50 dns1 postfix/smtpd[27987]: warning: problem talking to server
private/policyd-spf: Connection refused
Nov  5 03:06:50 dns1 postfix/smtpd[27987]: NOQUEUE: reject: RCPT from mail-
vx0-f186.google.com[209.85.220.186]: 451 4.3.5 Server configuration problem;
from=<[hidden email]>
to=<[hidden email]> proto=ESMTP helo=<mail-vx0-f186.google.com>
Nov  5 03:06:50 dns1 postfix/smtpd[27987]: disconnect from mail-vx0-
f186.google.com[209.85.220.186]

*********Turning off spf lines produces:

Nov  5 03:09:53 dns1 postfix/postfix-script[28136]: refreshing the Postfix
mail system
Nov  5 03:09:53 dns1 postfix/master[1324]: reload -- version 2.8.5,
configuration /usr/local/etc/postfix
Nov  5 03:09:53 dns1 postfix/anvil[27989]: statistics: max connection rate
1/60s for (smtp:209.85.220.186) at Nov  5 03:06:49
Nov  5 03:09:53 dns1 postfix/anvil[27989]: statistics: max connection count 1
for (smtp:209.85.220.186) at Nov  5 03:06:49
Nov  5 03:09:53 dns1 postfix/anvil[27989]: statistics: max cache size 1 at Nov  
5 03:06:49
Nov  5 03:12:06 dns1 postfix/smtpd[28166]: connect from f1.mail.ci-
net.com[195.72.167.30]
Nov  5 03:12:06 dns1 postfix/smtpd[28166]: NOQUEUE: reject: RCPT from
f1.mail.ci-net.com[195.72.167.30]: 454 4.7.1 <[hidden email]>: Relay access
denied; from=<[hidden email]> to=<[hidden email]> proto=ESMTP
helo=<f3.mail.ci-net.com>
Nov  5 03:12:06 dns1 postfix/smtpd[28166]: disconnect from f1.mail.ci-
net.com[195.72.167.30]
Nov  5 03:12:12 dns1 postfix/smtpd[28166]: connect from
mail.mariposacounty.org[64.118.106.46]
Nov  5 03:12:12 dns1 postgrey[1235]: action=pass, reason=triplet found,
client_name=mail.mariposacounty.org, client_address=64.118.106.46,
sender=[hidden email],
recipient=[hidden email]
Nov  5 03:12:12 dns1 postfix/smtpd[28166]: NOQUEUE: reject: RCPT from
mail.mariposacounty.org[64.118.106.46]: 450 4.1.1
<[hidden email]>: Recipient address rejected: User
unknown in local recipient table; from=<[hidden email]>
to=<[hidden email]> proto=ESMTP
helo=<mail.mariposacounty.org>
Nov  5 03:12:13 dns1 postfix/smtpd[28166]: disconnect from
mail.mariposacounty.org[64.118.106.46]
Nov  5 03:15:37 dns1 postfix/anvil[28168]: statistics: max connection rate
1/60s for (smtp:195.72.167.30) at Nov  5 03:12:06
Nov  5 03:15:37 dns1 postfix/anvil[28168]: statistics: max connection count 1
for (smtp:195.72.167.30) at Nov  5 03:12:06
Nov  5 03:15:37 dns1 postfix/anvil[28168]: statistics: max cache size 2 at Nov  
5 03:12:12
Nov  5 03:17:32 dns1 postfix/smtpd[28183]: connect from mail-vw0-
f58.google.com[209.85.212.58]
Nov  5 03:17:33 dns1 postgrey[1235]: action=pass, reason=client whitelist,
client_name=mail-vw0-f58.google.com, client_address=209.85.212.58,
sender=[hidden email],
recipient=[hidden email]
Nov  5 03:17:33 dns1 postfix/smtpd[28183]: 4D6F4119C3F: client=mail-vw0-
f58.google.com[209.85.212.58]
Nov  5 03:17:33 dns1 postfix/cleanup[28187]: 4D6F4119C3F: message-
id=<CADQqhMe6d5skk3efjf6yAzxO_xtUwC8W6f67n17u0g8wFK=[hidden email]>
Nov  5 03:17:33 dns1 postfix/qmgr[28141]: 4D6F4119C3F: from=<rubyonrails-
[hidden email]>, size=5231, nrcpt=1
(queue active)
Nov  5 03:17:33 dns1 postfix/local[28188]: 4D6F4119C3F:
to=<[hidden email]>, orig_to=<[hidden email]>, relay=local, delay=0.37,
delays=0.36/0.01/0/0, dsn=2.0.0, status=sent (delivered to mailbox)
Reply | Threaded
Open this post in threaded view
|

Re: spf configuration woes

Kamil Raczyński
On 2011-11-05 11:27, David Southwell wrote:

 > Lets assume that is the case. If so can anyone please help me
identify the
 > error?

[...]

 >   policyd-spf unix -       n       n       -       0       spawn


Is there whitespace at the beginning of this line? You have to remove it.

man 5 master.cf says:

SYNTAX
        The general format of the master.cf file is as follows:
[...]
A logical line starts with non-whitespace text. A line that starts with
whitespace continues a logical line.

So it has to start with: "policyd-spf" instead of: " policyd-spf".

Best Regards
--
Kamil
Reply | Threaded
Open this post in threaded view
|

Re: spf configuration woes

David Southwell-3
On Saturday 05 November 2011 04:13:17 Kamil Raczyński wrote:

> On 2011-11-05 11:27, David Southwell wrote:
>  > Lets assume that is the case. If so can anyone please help me
>
> identify the
>
>  > error?
>
> [...]
>
>  >   policyd-spf unix -       n       n       -       0       spawn
>
> Is there whitespace at the beginning of this line? You have to remove it.
>
> man 5 master.cf says:
>
> SYNTAX
>         The general format of the master.cf file is as follows:
> [...]
> A logical line starts with non-whitespace text. A line that starts with
> whitespace continues a logical line.
>
> So it has to start with: "policyd-spf" instead of: " policyd-spf".
>
> Best Regards

Thank you Kamil

Great observation .. this has moved it on a long way. But there is still one
problem. You will see in the extract from maillog that spf does not like "spf-
policy_time_limit" and there is still a report of server configuration error.

Where can I find a definitive list of the correct commands and syntax for
these commands (running postfix-policyd-spf-perl-2.007). (Currently the web
site for openspf.org is down.)

Hopefully this may be the last obstacle!

David

Extract from maillog:
Nov  5 04:20:29 dns1 postfix/postfix-script[28619]: refreshing the Postfix
mail system
Nov  5 04:20:29 dns1 postfix/master[1324]: reload -- version 2.8.5,
configuration /usr/local/etc/postfix
Nov  5 04:20:48 dns1 postfix/smtpd[28626]: connect from mail-bw0-
f58.google.com[209.85.214.58]
Nov  5 04:20:49 dns1 postfix/policy-spf[28631]: : SPF pass (Mechanism
'ip4:209.85.128.0/17' matched): Envelope-from: rubyonrails-talk+bncCPHKr-
[hidden email]
Nov  5 04:20:49 dns1 postfix/policy-spf[28631]: handler
sender_policy_framework: is decisive.
Nov  5 04:20:49 dns1 postfix/policy-spf[28631]: : Policy action=PREPEND
Received-SPF: pass (googlegroups.com ... _spf.google.com: 209.85.214.58 is
authorized to use 'rubyonrails-talk+bncCPHKr-
[hidden email]' in 'mfrom' identity (mechanism
'ip4:209.85.128.0/17' matched)) receiver=dns1.vizion2000.net;
identity=mailfrom; envelope-from="rubyonrails-talk+bncCPHKr-
[hidden email]"; helo=mail-bw0-f58.google.com; client-
ip=209.85.214.58
Nov  5 04:20:49 dns1 postfix/smtpd[28626]: warning: unknown smtpd restriction:
"spf-policy_time_limit"
Nov  5 04:20:49 dns1 postfix/smtpd[28626]: NOQUEUE: reject: RCPT from mail-
bw0-f58.google.com[209.85.214.58]: 451 4.3.5 Server configuration error;
from=<[hidden email]>
to=<[hidden email]> proto=ESMTP helo=<mail-bw0-f58.google.com>
Nov  5 04:20:49 dns1 postfix/cleanup[28632]: D32BA119C4B: message-
id=<[hidden email]>
Nov  5 04:20:49 dns1 postfix/smtpd[28626]: disconnect from mail-bw0-
f58.google.com[209.85.214.58]
Nov  5 04:20:49 dns1 postfix/qmgr[28625]: D32BA119C4B: from=<double-
[hidden email]>, size=967, nrcpt=1 (queue active)
Nov  5 04:20:49 dns1 postfix/local[28633]: D32BA119C4B:
to=<[hidden email]>, orig_to=<postmaster>, relay=local, delay=0.03,
delays=0.01/0.01/0/0.02, dsn=2.0.0, status=sent (delivered to mailbox)
Nov  5 04:20:49 dns1 postfix/qmgr[28625]: D32BA119C4B: removed
Nov  5 04:21:50 dns1 postfix/smtpd[28626]: connect from
unusquinquenovem.phi.ec-cluster.com[195.140.184.159]
Nov  5 04:21:51 dns1 postfix/policy-spf[28631]: : SPF pass (Mechanism
'ip4:195.140.184.0/22' matched): Envelope-from:
[hidden email]
Nov  5 04:21:51 dns1 postfix/policy-spf[28631]: handler
sender_policy_framework: is decisive.
Nov  5 04:21:51 dns1 postfix/policy-spf[28631]: : Policy action=PREPEND
Received-SPF: pass (bounce.youraccount.mbna.co.uk ... _spf.muc.ec-
messenger.com: 195.140.184.159 is authorized to use
'[hidden email]'
in 'mfrom' identity (mechanism 'ip4:195.140.184.0/22' matched))
receiver=dns1.vizion2000.net; identity=mailfrom; envelope-
from="[hidden email]";
helo=unusquinquenovem.phi.ec-cluster.com; client-ip=195.140.184.159
Nov  5 04:21:51 dns1 postfix/smtpd[28626]: warning: unknown smtpd restriction:
"spf-policy_time_limit"
Nov  5 04:21:51 dns1 postfix/smtpd[28626]: NOQUEUE: reject: RCPT from
unusquinquenovem.phi.ec-cluster.com[195.140.184.159]: 451 4.3.5 Server
configuration error;
from=<[hidden email]>
to=<[hidden email]> proto=ESMTP helo=<unusquinquenovem.phi.ec-
cluster.com>
Nov  5 04:21:51 dns1 postfix/cleanup[28632]: 5ABAA119C4B: message-
id=<[hidden email]>
Nov  5 04:21:51 dns1 postfix/smtpd[28626]: disconnect from
unusquinquenovem.phi.ec-cluster.com[195.140.184.159]
Nov  5 04:21:51 dns1 postfix/qmgr[28625]: 5ABAA119C4B: from=<double-
[hidden email]>, size=1152, nrcpt=1 (queue active)
Nov  5 04:21:51 dns1 postfix/local[28633]: 5ABAA119C4B:
to=<[hidden email]>, orig_to=<postmaster>, relay=local, delay=0,
delays=0/0/0/0, dsn=2.0.0, status=sent (delivered to mailbox)
Nov  5 04:21:51 dns1 postfix/qmgr[28625]: 5ABAA119C4B: removed
Nov  5 04:22:56 dns1 postfix/postfix-script[28656]: refreshing the Postfix
mail system
Nov  5 04:22:56 dns1 postfix/master[1324]: reload -- version 2.8.5,
configuration /usr/local/etc/postfix
Nov  5 04:22:56 dns1 postfix/anvil[28628]: statistics: max connection rate
1/60s for (smtp:209.85.214.58) at Nov  5 04:20:48
Nov  5 04:22:56 dns1 postfix/anvil[28628]: statistics: max connection count 1
for (smtp:209.85.214.58) at Nov  5 04:20:48
Nov  5 04:22:56 dns1 postfix/anvil[28628]: statistics: max cache size 1 at Nov  
5 04:20:48
Reply | Threaded
Open this post in threaded view
|

Re: spf configuration woes

Wietse Venema
In reply to this post by David Southwell
David Southwell:
> > Yes, because of a master.cf configuration error.
>
> Lets assume that is the case. If so can anyone please help me identify the

Have you run lsof or netstat already, to find out if
postfix is listening on the policyd-spf socket?

Do you prefer to debate the number of legs on a beetle, instead
of simply going out and counting them.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: spf configuration woes

David Southwell-3
On Saturday 05 November 2011 04:57:26 Wietse Venema wrote:

> David Southwell:
> > > Yes, because of a master.cf configuration error.
> >
> > Lets assume that is the case. If so can anyone please help me identify
> > the
>
> Have you run lsof or netstat already, to find out if
> postfix is listening on the policyd-spf socket?
>
> Do you prefer to debate the number of legs on a beetle, instead
> of simply going out and counting them.
>
> Wietse
Did you read the original posting and the reply from Kamil. He spotted the
primary cause. It was he who spotted the extra  " " before policyd-spf in
master.cf which was in the part of the post you cut out.

So you were right it was an error in the master.cf but noone else spotted it
before Kamil made his contribution.

Would you prefer the value of your wonderful contributions over many years to
postfix to be warmly appreciated or prefer to ignore the opportunity
toidentify the cause of a problem by turning your attention to unnecessarily
lacing your comments with seemingly trite & shallow gibes?

Take care
David
Reply | Threaded
Open this post in threaded view
|

Re: spf configuration woes

David Southwell-3
In reply to this post by David Southwell-3
On Saturday 05 November 2011 04:33:27 David Southwell wrote:

> On Saturday 05 November 2011 04:13:17 Kamil Raczyński wrote:
> > On 2011-11-05 11:27, David Southwell wrote:
> >  > Lets assume that is the case. If so can anyone please help me
> >
> > identify the
> >
> >  > error?
> >
> > [...]
> >
> >  >   policyd-spf unix -       n       n       -       0       spawn
> >
> > Is there whitespace at the beginning of this line? You have to remove it.
> >
> > man 5 master.cf says:
> >
> > SYNTAX
> >
> >         The general format of the master.cf file is as follows:
> > [...]
> > A logical line starts with non-whitespace text. A line that starts with
> > whitespace continues a logical line.
> >
> > So it has to start with: "policyd-spf" instead of: " policyd-spf".
> >
> > Best Regards
>
> Thank you Kamil
>
> Great observation .. this has moved it on a long way. But there is still
> one problem. You will see in the extract from maillog that spf does not
> like "spf- policy_time_limit" and there is still a report of server
> configuration error.
>
> Where can I find a definitive list of the correct commands and syntax for
> these commands (running postfix-policyd-spf-perl-2.007). (Currently the web
> site for openspf.org is down.)
>
> Hopefully this may be the last obstacle!
>
> David

Hi Kamil

I solved this one -based on your observation- it was another example of an
excessive " " this time before the time_limit entry. Once that was eliminated
sspf works! You set me on the right track.

Thank you

David
Reply | Threaded
Open this post in threaded view
|

Re: spf configuration woes

Wietse Venema
In reply to this post by David Southwell-3
David Southwell:
> Did you read the original posting and the reply from Kamil. He spotted the
> primary cause. It was he who spotted the extra  " " before policyd-spf in
> master.cf which was in the part of the post you cut out.
>
> So you were right it was an error in the master.cf but noone else spotted it
> before Kamil made his contribution.

You could have spotted it days ago with lsof/netstat which would
have told you immediately that postfix was not listening on the
socket.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: spf configuration woes

David Southwell-3
On Saturday 05 November 2011 05:13:22 Wietse Venema wrote:

> David Southwell:
> > Did you read the original posting and the reply from Kamil. He spotted
> > the primary cause. It was he who spotted the extra  " " before
> > policyd-spf in master.cf which was in the part of the post you cut out.
> >
> > So you were right it was an error in the master.cf but noone else spotted
> > it before Kamil made his contribution.
>
> You could have spotted it days ago with lsof/netstat which would
> have told you immediately that postfix was not listening on the
> socket.
>
> Wietse

Typical Wietse response. Everyone could see postfix was not listening but it
took Kamil's careful scrutiny and knowledge to identify why - knowing why was
what led to the solution.

Diagnosis is valuable but without the ability to define the treatment the
diagnosis is merely a matter of record.

Clearly postfix is  need of an intelligent parser that will to pinpoint errors
such as this in master.cf and main.cf. That is because stupid computers are
better at parsing chores than human beings.

David
Reply | Threaded
Open this post in threaded view
|

Re: spf configuration woes

Simon Brereton-2
On 5 November 2011 08:21, David Southwell <[hidden email]> wrote:

> On Saturday 05 November 2011 05:13:22 Wietse Venema wrote:
>> David Southwell:
>> > Did you read the original posting and the reply from Kamil. He spotted
>> > the primary cause. It was he who spotted the extra  " " before
>> > policyd-spf in master.cf which was in the part of the post you cut out.
>> >
>> > So you were right it was an error in the master.cf but noone else spotted
>> > it before Kamil made his contribution.
>>
>> You could have spotted it days ago with lsof/netstat which would
>> have told you immediately that postfix was not listening on the
>> socket.
>>
>>       Wietse
>
> Typical Wietse response. Everyone could see postfix was not listening but it

And Wietse was trying to get you to find out why - instead of making
random changes.  He asked you at least twice to run netstat - did you
do it?  It would have saved you 18 hours and at least 3 long mails if
you had.  Typically ungrateful response to Wietse's help is more like
it.  People come on here, expect it him not only to write it, but keep
it secure and spot typgraphical errors in their own configs because
they're too lazy to look (and that laziness is exemplified by a
laziness to follow a simple diagnostic instruction).

> took Kamil's careful scrutiny and knowledge to identify why - knowing why was
> what led to the solution.

Which you'd have had much much earlier without the hand-holding had
you followed Wietse's first request to run netstat.

> Diagnosis is valuable but without the ability to define the treatment the
> diagnosis is merely a matter of record.

Only valuable if you follow the steps you're asked to perform.
Spoonfeeding and proof-reading your errors in your config files is not
diagnosis.

> Clearly postfix is  need of an intelligent parser that will to pinpoint errors
> such as this in master.cf and main.cf. That is because stupid computers are
> better at parsing chores than human beings.

Postfix has such a parser - which is why the documentation points out
that lines should not start with a white-space.  RTFM.

Simon
Reply | Threaded
Open this post in threaded view
|

Re: spf configuration woes

David Southwell-3
On Saturday 05 November 2011 06:42:12 Simon Brereton wrote:

> On 5 November 2011 08:21, David Southwell <[hidden email]> wrote:
> > On Saturday 05 November 2011 05:13:22 Wietse Venema wrote:
> >> David Southwell:
> >> > Did you read the original posting and the reply from Kamil. He spotted
> >> > the primary cause. It was he who spotted the extra  " " before
> >> > policyd-spf in master.cf which was in the part of the post you cut
> >> > out.
> >> >
> >> > So you were right it was an error in the master.cf but noone else
> >> > spotted it before Kamil made his contribution.
> >>
> >> You could have spotted it days ago with lsof/netstat which would
> >> have told you immediately that postfix was not listening on the
> >> socket.
> >>
> >>       Wietse
> >
> > Typical Wietse response. Everyone could see postfix was not listening but
> > it
>
> And Wietse was trying to get you to find out why - instead of making
> random changes.  He asked you at least twice to run netstat - did you
> do it?  
yes - I had done it before wietse asked - it was too blindingly obvious
everyone knew it was not starting. Wietse is too fond of being downright rude.

> It would have saved you 18 hours and at least 3 long mails if
> you had.  Typically ungrateful response to Wietse's help is more like
> it.  People come on here, expect it him not only to write it, but keep
> it secure and spot typgraphical errors in their own configs because
> they're too lazy to look (and that laziness is exemplified by a
> laziness to follow a simple diagnostic instruction).
>
Misplaced critique. Like wietse you are jumping to conclusions. Assuming the
worst rather than the best of people. The recomendation came after not before
the act.
> > took Kamil's careful scrutiny and knowledge to identify why - knowing why
> > was what led to the solution.
>
> Which you'd have had much much earlier without the hand-holding had
> you followed Wietse's first request to run netstat.

Sorry but that is B******t! The information about the excess space was there
--  Wietse just didn't see it unless he was deliberately concealing the fact
that he knew the excess space was there. That could not be true because he
would have known that netstat would not have revealed the fact theat there was
an excess space in the file. What would therefore have been the purpose of
running netstat?

>
> > Diagnosis is valuable but without the ability to define the treatment the
> > diagnosis is merely a matter of record.
>
> Only valuable if you follow the steps you're asked to perform.
> Spoonfeeding and proof-reading your errors in your config files is not
> diagnosis.
>
> > Clearly postfix is  need of an intelligent parser that will to pinpoint
> > errors such as this in master.cf and main.cf. That is because stupid
> > computers are better at parsing chores than human beings.
>
> Postfix has such a parser - which is why the documentation points out
> that lines should not start with a white-space.
Humble humans acknowledge we make errors. Wise humans use stupid computers to
perform tasks that people are not good at. Stupid humans tell other people
they are stupid when they make mistakes and tell them RTFM!

You are failing to distinguish between a diagnostic parser and an executive
parser. An executive parser rejects incorrectly configured lines at runtime.
A diagnostic parser would tell you that there is an excess space at a specific
location. A really good executive parser would also log the location of
incorrectly configured lines to facilitate the work of an administrator.

I do not expect anyone to solve my problems. On the other hand I do not expect
them to be gratuitously rude rather than helpfully constructive. IF Wietse is
unable to restrain himself from repeated bouts of arrogant rudeness then,
IMHO, he needs counselling.

In this case Kemil spotted the error. That helped me spot other errors. Kemil
was constructive IMHPO Wietse was plain rude.
Reply | Threaded
Open this post in threaded view
|

Re: spf configuration woes

Gerard E. Seibert
On Sat, 5 Nov 2011 07:03:18 -0700
David Southwell articulated:

> In this case Kemil spotted the error. That helped me spot other
> errors. Kemil was constructive IMHPO Wietse was plain rude.

In that case, cross Wietse off your Christmas card list and add Kemil.

The users of this list are offering their services sans monetary
compensation. If you don't like their advice/suggestions, that is your
prerogative. However, it does not give you the right to degrade someone
simple because they did not supply the answer you wanted.

The problem was in your configuration. It was not Wietse's fault or a
bug with Postfix. You created the problem. Now, I don't think Wietse
would have any problem with you creating a custom configuration parser
that would be more suitable to task for your needs. Perhaps if you
spent more time on creating such an applications and less time on
assailing Wietse your time would be better spent.

--
Jerry ♔
[hidden email]
_____________________________________________________________________
TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail
TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html

Reply | Threaded
Open this post in threaded view
|

executive parser (was: Re: spf configuration woes)

/dev/rob0
In reply to this post by David Southwell-3
I have cut all the irrelevant and whiny crap from the quotes, and I
ask that others please not continue that off-topic and useless
discussion. One part of this, q.v., deserves to be addressed.

On Saturday 05 November 2011 09:03:18 David Southwell wrote:
> On Saturday 05 November 2011 06:42:12 Simon Brereton wrote:
> > On 5 November 2011 08:21, David Southwell
> > <[hidden email]> wrote:
snip
> > > Clearly postfix is  need of an intelligent parser that will to
> > > pinpoint errors such as this in master.cf and main.cf. That is
> > > because stupid computers are better at parsing chores than
> > > human beings.
> >
> > Postfix has such a parser - which is why the documentation points
> > out that lines should not start with a white-space.
snip

> You are failing to distinguish between a diagnostic parser and an
> executive parser. An executive parser rejects incorrectly
> configured lines at runtime. A diagnostic parser would tell you
> that there is an excess space at a specific location. A really
> good executive parser would also log the location of incorrectly
> configured lines to facilitate the work of an administrator.

And that would be far more difficult than you imagine. How is this
parser to know that the administrator did not intend to continue the
logical line? It needs a DWIM filter.

# a master.cf logical line
submission inet n - n - - smtpd
        -o smtpd_tls_auth_only=yes
        -o smtpd_sasl_auth_enable=yes
        -o smtpd_recipient_restrictions=$submission_rcpt_restrictions
        -o milter_macro_daemon_name=ORIGINATING
        -o syslog_name=postfix-587
# a master.cf typo
 pickup fifo n - n 60 1 pickup

In this case we have a Postfix daemon, smtpd(8), which obviously
should not have "pickup fifo ..." as a command argument. This one is
potentially detectable by an automated parser.

# a master.cf logical line
dovecot unix - n n - - pipe
        flags=DRhu user=vmail:vmail
        argv=/usr/local/libexec/dovecot/dovecot-lda
        -f ${sender} -d ${recipient}
# a master.cf typo
 mailman unix - n n - - pipe
        flags=FR user=list
        argv=/usr/lib/mailman/bin/postfix-to-mailman.py
        ${nexthop} ${user}

How is your executive parser going to know that dovecot-lda is not
expecting "mailman unix ..." on its command line?

It's easy to fuss and point fingers at inadequacies in software, but
to address those shortcomings takes quite a bit of work.

Wietse has said many times here that his time to spend on Postfix is
limited. His approach was to provide clear and complete documentation
of postconf(5) and master(5) files. The sample files in the source
tarball include the syntax instructions as comments at the top.

The fact is: if you follow directions carefully, you will not be
bitten by mistakes of this nature. There is exactly one person to
accept the "blame" here, if you want to talk about blame. But this
list is not the place for that.
--
    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: executive parser (was: Re: spf configuration woes)

David Southwell-3
On Saturday 05 November 2011 07:50:58 /dev/rob0 wrote:

> I have cut all the irrelevant and whiny crap from the quotes, and I
> ask that others please not continue that off-topic and useless
> discussion. One part of this, q.v., deserves to be addressed.
>
> On Saturday 05 November 2011 09:03:18 David Southwell wrote:
> > On Saturday 05 November 2011 06:42:12 Simon Brereton wrote:
> > > On 5 November 2011 08:21, David Southwell
>
> > > <[hidden email]> wrote:
> snip
>
> > > > Clearly postfix is  need of an intelligent parser that will to
> > > > pinpoint errors such as this in master.cf and main.cf. That is
> > > > because stupid computers are better at parsing chores than
> > > > human beings.
> > >
> > > Postfix has such a parser - which is why the documentation points
> > > out that lines should not start with a white-space.
>
> snip
>
> > You are failing to distinguish between a diagnostic parser and an
> > executive parser. An executive parser rejects incorrectly
> > configured lines at runtime. A diagnostic parser would tell you
> > that there is an excess space at a specific location. A really
> > good executive parser would also log the location of incorrectly
> > configured lines to facilitate the work of an administrator.
>
> And that would be far more difficult than you imagine.
How do you know how much I imagine. What makes you believe that I do not know
it is difficult!

The problem you identify in subsequent lines, has its roots in postfix's
rather primitive formatting structure.

If it were replace by something like:
{submission (variant,modifier [connector] data )
         (variant = data)
         (variant = data)
end submission
}
This type of formatting structure (it would need a few more symbols to cover
all the current alternatives)  is easier for humans to read, makes clear the  
separation between modules and facilitates the building of diagnostic &  
executive parsers to test, implement and log outcomes.

IMHO the problem caused by retaining the earliest forms of formatting known to
unix is what presents postfix users unnecessary challenges.

It is easier to change the formatting structure than map a parser to the
current idiosyncratic framework. It would not be necessary to reinvent
Postfix's executive parser because it would not be that difficult to build a
diagnostic parser which could also convert a new format into the existing
format.

Idiosyncratic formatting is a curse inflicted on system administrators who are
expected by those who are dedicated to supporting a single application. The
demands they make on administrators are therefore unrealistic.
Reply | Threaded
Open this post in threaded view
|

Re: executive parser (was: Re: spf configuration woes)

David Southwell-3
Just to add weight to my last posting - the use of a " " as a critical symbol
is really quite idiotic. What cannot be seen should never be that significant!
Reply | Threaded
Open this post in threaded view
|

Re: executive parser

Daniele Nicolodi
On 05/11/11 17:40, David Southwell wrote:
> Just to add weight to my last posting - the use of a " " as a critical symbol
> is really quite idiotic. What cannot be seen should never be that significant!

Telling people, member of an affirmed community, that what they are
currently doing is idiotic, is absolutely not an intelligent way of
trying to convince them of your arguments.

On the technical merit, Python is a very well established programming
language where indentation (spaces) is used to delimit code blocks, and
thus is very significant.

From the perception point of view, trailing spaces can be hard to spot,
however leading spaces can absolutely by seen easily by everyone.

Cheers,
--
Daniele
Reply | Threaded
Open this post in threaded view
|

Re: executive parser

Daniele Nicolodi
In reply to this post by David Southwell-3
On 05/11/11 17:30, David Southwell wrote:

> The problem you identify in subsequent lines, has its roots in postfix's
> rather primitive formatting structure.
>
> If it were replace by something like:
> {submission (variant,modifier [connector] data )
>          (variant = data)
>          (variant = data)
> end submission
> }
> This type of formatting structure (it would need a few more symbols to cover
> all the current alternatives)  is easier for humans to read, makes clear the  
> separation between modules and facilitates the building of diagnostic &  
> executive parsers to test, implement and log outcomes.

Whatever syntax you are going to come up can not be immune to syntax
errors, predicting the effect of those errors is limited to the
computation of all the permutations of the symbols it is composed with.

The fact that a syntax is better than another is matter of taste. I find
the current syntax really obvious and easy to parse. If leading space
used as line continuation marker disturbs you, just do not use it. It is
however very easy to write a simple program (or an emacs mode) that
understands the current syntax and highlights line continuations, making
leading spaces more obvious to see.

> Idiosyncratic formatting is a curse inflicted on system administrators who are
> expected by those who are dedicated to supporting a single application. The
> demands they make on administrators are therefore unrealistic.

Until everyone will agree on a common formatting for representing
whatever information, we will have to come with different syntax for
different purposes and usage domains. XML tried to be such format, and
failed miserably IMHO.

Cheers,
--
Daniele
Reply | Threaded
Open this post in threaded view
|

Re: executive parser

Richard Damon
In reply to this post by David Southwell-3
On 11/5/11 12:40 PM, David Southwell wrote:
> Just to add weight to my last posting - the use of a " " as a critical symbol
> is really quite idiotic. What cannot be seen should never be that significant!
>
Since it is an integral part of the Mail Format RFC (RFC 2822) as the
way to indicate that header lines are continued, it seems very natural
that it would be used in a Mail Transport Agent to have its config file
set up.

--
Richard Damon

Reply | Threaded
Open this post in threaded view
|

RE: executive parser (was: Re: spf configuration woes)

Murray S. Kucherawy-2
In reply to this post by David Southwell-3
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of David Southwell
> Sent: Saturday, November 05, 2011 9:41 AM
> To: [hidden email]
> Cc: /dev/rob0
> Subject: Re: executive parser (was: Re: spf configuration woes)
>
> Just to add weight to my last posting - the use of a " " as a critical symbol
> is really quite idiotic. What cannot be seen should never be that
> significant!

The current RFC defining email message format is RFC5322, and it uses leading whitespace as line continuation in header fields.  Its antecedents, going back as far as RFC733 (1977) and perhaps further, do the same thing.  Thus, your assertion appears to be in conflict with quite a bit of operational history and experience.

123