Re: Is postscreen really this good?
o
local_destination_concurrency_limit = 2
local_destination_recipient_limit = 100
local_recipient_maps = unix:passwd.byname $alias_maps
mail_owner = postfix
mailbox_size_limit = 104857600
maildrop_destination_recipient_limit = 1
mailq_path = /usr/local/bin/mailq
manpage_directory = /usr/local/man
maximal_queue_lifetime = 5d
mydestination = $myhostname, localhost.$mydomain, localhost mail.$mydomain,
www.$mydomain, lists.$mydomain, $mydomain
mydomain = stovebolt.com
myhostname = mail.$mydomain
mynetworks = 127.0.0.0/8,216.58.158.170/32
myorigin = $mydomain
newaliases_path = /usr/local/bin/newaliases
owner_request_special = no
postscreen_access_list = permit_mynetworks
postscreen_bare_newline_action = ignore
postscreen_bare_newline_enable = no
postscreen_bare_newline_ttl = 30d
postscreen_blacklist_action = ignore
postscreen_cache_cleanup_interval = 12h
postscreen_cache_map = btree:$data_directory/postscreen_cache
postscreen_cache_retention_time = 7d
postscreen_client_connection_count_limit =
$smtpd_client_connection_count_limit
postscreen_command_count_limit = 20
postscreen_command_filter =
postscreen_command_time_limit = ${stress?10}${stress:300}s
postscreen_disable_vrfy_command = $disable_vrfy_command
postscreen_discard_ehlo_keyword_address_maps =
$smtpd_discard_ehlo_keyword_address_maps
postscreen_discard_ehlo_keywords = $smtpd_discard_ehlo_keywords
postscreen_dnsbl_action = ignore
postscreen_dnsbl_reply_map =
postscreen_dnsbl_sites = bl.spamcop.net, zen.spamhaus.org, dnsbl.sorbs.net
postscreen_dnsbl_threshold = 1
postscreen_dnsbl_ttl = 1h
postscreen_enforce_tls = $smtpd_enforce_tls
postscreen_expansion_filter = $smtpd_expansion_filter
postscreen_forbidden_commands = $smtpd_forbidden_commands
postscreen_greet_action = ignore
postscreen_greet_banner = $smtpd_banner
postscreen_greet_ttl = 1d
postscreen_greet_wait = ${stress?2}${stress:6}s
postscreen_helo_required = $smtpd_helo_required
postscreen_non_smtp_command_action = drop
postscreen_non_smtp_command_enable = no
postscreen_non_smtp_command_ttl = 30d
postscreen_pipelining_action = enforce
postscreen_pipelining_enable = no
postscreen_pipelining_ttl = 30d
postscreen_post_queue_limit = $default_process_limit
postscreen_pre_queue_limit = $default_process_limit
postscreen_reject_footer = $smtpd_reject_footer
postscreen_tls_security_level = $smtpd_tls_security_level
postscreen_use_tls = $smtpd_use_tls
postscreen_watchdog_timeout = 10s
postscreen_whitelist_interfaces = static:all
queue_directory = /var/spool/postfix
readme_directory = /usr/local/share/doc/postfix
recipient_delimiter = +
relay_domains = $mydestination, www.stovebolt.com, server1.stovebolt.com
sample_directory = /usr/local/etc/postfix
sendmail_path = /usr/local/sbin/sendmail
setgid_group = maildrop
smtpd_delay_reject = yes
smtpd_helo_restrictions = permit_mynetworks reject_invalid_hostname
smtpd_junk_command_limit = 5
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated
reject_unauth_destination check_client_access hash:$config_directory/access
reject_unauth_pipelining reject_non_fqdn_sender reject_non_fqdn_recipient
reject_unknown_sender_domain check_recipient_access
hash:$config_directory/policyd_weight_recipient_whitelist
check_client_access hash:$config_directory/policyd_weight_client_whitelist
check_policy_service inet:127.0.0.1:12525 permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_security_options = noanonymous
smtpd_tls_CAfile = /usr/local/etc/postfix/server.pem
smtpd_tls_cert_file = /usr/local/etc/postfix/server.pem
smtpd_tls_key_file = /usr/local/etc/postfix/server.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
soft_bounce = no
tls_random_source = dev:/dev/urandom
unknown_local_recipient_reject_code = 550
virtual_alias_domains = friendshipforest.com fieldoftrees.com
txantimedia.com
virtual_alias_maps = hash:/usr/local/etc/postfix/virtual
--
Paul Schmehl (g...@stovebolt.com)
The Stovebolt Geek
The Net's Oldest and Most Complete
Resource for Antique Chevy and GM Trucks
http://www.stovebolt.com
Re: Is postscreen really this good?
I think I may not what's wrong. Here's the master.cf settings:
# grep -v "#" /usr/local/etc/postfix/master.cf
smtp inet n - n - - smtpd -o
content_filter=filter:dummyr
smtpsinet n - n - - smtpd
-o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes
pickupfifo n - n 60 1 pickup
cleanup unix n - n - 0 cleanup
qmgr fifo n - n 300 1 qmgr
tlsmgrunix - - n 1000? 1 tlsmgr
rewrite unix - - n - - trivial-rewrite
bounceunix - - n - 0 bounce
defer unix - - n - 0 bounce
trace unix - - n - 0 bounce
verifyunix - - n - 1 verify
flush unix n - n 1000? 0 flush
proxymap unix - - n - - proxymap
smtp unix - - n - - smtp
showq unix n - n - - showq
error 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
scacheunix - - n - 1 scache
maildrop unix - n n - - pipe
flags=DRhu user=vmail argv=/usr/local/bin/maildrop -d ${recipient}
uucp unix - n n - - pipe
flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail
($recipient)
ifmailunix - n n - - pipe
flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp unix - n n - - pipe
flags=Fq. user=foo argv=/usr/local/sbin/bsmtp -f $sender $nexthop
$recipient
filterunix - n n - 10 pipe
flags=Rq user=filter argv=/usr/local/bin/filter.sh -f ${sender} --
${recipient}
relay unix - - n - - smtp
retry unix - - n - - error
proxywrite unix - - n - 1 proxymap
smtp inet n - n - 1 postscreen
smtpd pass - - n - - smtpd
dnsblog unix - - n - 0 dnsblog
In reading the docs it says to comment out the smtp line and uncomment the
one that routes to postscreen. I have both uncommented.
# grep -v "#" /usr/local/etc/postfix/master.cf | grep smtp
smtp inet n - n - - smtpd -o
content_filter=filter:dummyr
smtpsinet n - n - - smtpd
-o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes
smtp unix - - n - - smtp
bsmtp unix - n n - - pipe
flags=Fq. user=foo argv=/usr/local/sbin/bsmtp -f $sender $nexthop
$recipient
relay unix - - n - - smtp
smtp inet n - n - 1 postscreen
smtpd pass - - n - - smtpd
The problem is, I also want to route through filter.sh, so how do I do that?
--
Paul Schmehl (g...@stovebolt.com)
The Stovebolt Geek
The Net's Oldest and Most Complete
Resource for Antique Chevy and GM Trucks
http://www.stovebolt.com
Re: Is postscreen really this good?
--On October 10, 2012 10:37:26 AM -0500 Noel Jones wrote: add your -o content_filter override to the new smtpd pass service. Thanks, Brian and Noel. I appreciate the help. I read all the readme files, but some of this stuff is above my pay grade. I get confused and am not sure what to do. -- Paul Schmehl (g...@stovebolt.com) The Stovebolt Geek The Net's Oldest and Most Complete Resource for Antique Chevy and GM Trucks http://www.stovebolt.com
Re: Postfix and Portimail Issues
mynetworks = 127.0.0.0/8,IP.Of.Fortimail.Firewall --On October 11, 2012 1:44:04 PM -0700 BeauSanders wrote: I am attempting to configure a Postfix MTA in CentOS 6.3 for our school. The Postfix server has to send and receive email through a Fortimail firewall. Outgoing email is working fine. Email sent locally using the mail command to a local user on the CentOS/Postfix server works fine. However, all email coming in to the Fortimail firewall addressed to users on the Postfix server is NOT being accepted by Postfix. Inbound mail from Fortimail is being deferred and ultimately rejected by Postfix. It appears the email is being forwarded/relayed from the Fortimail firewall to the Postfix server. There are no errors on the Fortimail firewall. Here is the main.cf file as it is currently configured: [code] queue_directory = /var/spool/postfix command_directory = /usr/sbin daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix mail_owner = postfix myhostname = bps.gvltec.edu inet_interfaces = all inet_protocols = all mydestination = $myhostname, localhost.$mydomain, localhost unknown_local_recipient_reject_code = 550 relayhost = [fortimail.ip.address.here] relay_recipient_maps = hash:/etc/postfix/relay_recipients alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases 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 sendmail_path = /usr/sbin/sendmail.postfix newaliases_path = /usr/bin/newaliases.postfix mailq_path = /usr/bin/mailq.postfix setgid_group = postdrop html_directory = no manpage_directory = /usr/share/man sample_directory = /usr/share/doc/postfix-2.6.6/samples readme_directory = /usr/share/doc/postfix-2.6.6/README_FILES [/code] Please advise me on what I am missing. I have not been able to locate any posts from users with similar problems. I will be happy to answer questions if somewhere will help me correct this issue. Thank you in advance for your help. -Beau -- View this message in context: http://postfix.1071664.n5.nabble.com/Postfix-and-Portimail-Issues-tp51465 .html Sent from the Postfix Users mailing list archive at Nabble.com. -- Paul Schmehl (g...@stovebolt.com) The Stovebolt Geek The Net's Oldest and Most Complete Resource for Antique Chevy and GM Trucks http://www.stovebolt.com
upgrade broke postfix
elimiter = +
relay_domains = $mydestination, www.stovebolt.com, server1.stovebolt.com
sample_directory = /usr/local/etc/postfix
sendmail_path = /usr/local/sbin/sendmail
setgid_group = maildrop
smtpd_delay_reject = yes
smtpd_helo_restrictions = permit_mynetworks reject_invalid_hostname
smtpd_junk_command_limit = 5
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated
reject_unauth_destination check_client_access hash:$config_directory/access
reject_unauth_pipelining reject_non_fqdn_sender reject_non_fqdn_recipient
reject_unknown_sender_domain permit
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
defer_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_security_options = noanonymous
smtpd_tls_CAfile = /usr/local/etc/postfix/server.pem
smtpd_tls_cert_file = /usr/local/etc/postfix/server.pem
smtpd_tls_key_file = /usr/local/etc/postfix/server.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
soft_bounce = no
tls_random_source = dev:/dev/urandom
unknown_local_recipient_reject_code = 550
virtual_alias_domains = friendshipforest.com fieldoftrees.com
txantimedia.com
virtual_alias_maps = hash:/usr/local/etc/postfix/virtual
# cat master.cf | grep -v '#'
smtpsinet n - n - - smtpd
-o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes
pickupfifo n - n 60 1 pickup
cleanup unix n - n - 0 cleanup
qmgr fifo n - n 300 1 qmgr
tlsmgrunix - - n 1000? 1 tlsmgr
rewrite unix - - n - - trivial-rewrite
bounceunix - - n - 0 bounce
defer unix - - n - 0 bounce
trace unix - - n - 0 bounce
verifyunix - - n - 1 verify
flush unix n - n 1000? 0 flush
proxymap unix - - n - - proxymap
smtp unix - - n - - smtp
showq unix n - n - - showq
error 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
scacheunix - - n - 1 scache
maildrop unix - n n - - pipe
flags=DRhu user=vmail argv=/usr/local/bin/maildrop -d ${recipient}
uucp unix - n n - - pipe
flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail
($recipient)
ifmailunix - n n - - pipe
flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp unix - n n - - pipe
flags=Fq. user=foo argv=/usr/local/sbin/bsmtp -f $sender $nexthop
$recipient
flags=Rq user=filter argv=/usr/local/bin/filter.sh -f ${sender} --
${recipient}
relay unix - - n - - smtp
retry unix - - n - - error
proxywrite unix - - n - 1 proxymap
smtp inet n - n - 1 postscreen
smtpd pass - - n - - smtpd -o
content_filter=filter:dummyr
dnsblog unix - - n - 0 dnsblog
tlsproxy unix - - n - 0 tlsproxy
I am lost and frustrated. I went from a working install to a broken
install. Any help spotting problems would be appreciated.
Paul Schmehl (pschm...@tx.rr.com)
Independent Researcher
Re: upgrade broke postfix
Following up on my own post...
I ran this and got the following results. No idea what it means:
# postfix upgrade-configuration set-permissions
Note: the following files or directories still exist but are
no longer part of Postfix:
/usr/local/etc/postfix/access /usr/local/etc/postfix/aliases
/usr/local/etc/postfix/canonical /usr/local/etc/postfix/relocated
/usr/local/etc/postfix/transport /usr/local/etc/postfix/virtual
--On August 19, 2015 at 10:49:35 AM -0500 Paul Schmehl
wrote:
I'm struggling with a broken Postfix and can't figure out what's wrong.
I upgraded the mail server from FreeBSD 8.4-RELEASE to 10.2-RELEASE
yesterday. After upgrading, you have to upgrade all packages, but that
breaks my Postfix install because it doesn't include sasl. So I
uninstalled it and reinstalled from ports.
After reinstalling, I had problems with policyd-weight. I was seeing
these errors in the logs:
postfix/policyd-weight[17306]: warning: child: err: Undefined subroutine
&Net::DNS::Packet::dn_expand called at /u
sr/local/bin/policyd-weight line 3589, line 26.
So I removed policyd-weight from the main.cf file and restarted postfix:
# check_recipient_access
# hash:$config_directory/policyd_weight_recipient_whitelist
# check_client_access
# hash:$config_directory/policyd_weight_client_whitelist
# check_policy_service inet:127.0.0.1:12525
# check_policy_service unix:private/policy
This morning I got up and checked on the server, and the queue was filled
up. I'm seeing transport errors in the logs: status=deferred (mail
transport unavailable)
Initially I didn't change anything in my setup. When I ran into
problems, I removed policyd-weight (which obviously has unresolved
issues). I have since removed the filter, since it was generating errors
too.
Here's my setup:
# postconf -n
alias_database = hash:/usr/local/etc/postfix/aliases
hash:/usr/local/mailman/data/aliases
alias_maps = hash:/usr/local/etc/postfix/aliases
hash:/usr/local/mailman/data/aliases
allow_mail_to_commands = alias,forward
allow_mail_to_files = alias,forward
allow_percent_hack = no
anvil_status_update_time = 1d
biff = no
body_checks = pcre:$config_directory/body-checks.pcre
broken_sasl_auth_clients = yes
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
debug_peer_list = 127.0.0.1
debugger_command = PATH=/usr/bin: xxgdb $daemon_directory/$process_name
$process_id & sleep 5
default_privs = nobody
default_process_limit = 75
delay_warning_time = 1d
header_checks = pcre:$config_directory/header-checks.pcre
home_mailbox = Maildir/
html_directory = /usr/local/share/doc/postfix
inet_interfaces = all
inet_protocols = ipv4
lmtp_destination_recipient_limit = 3000
lmtp_sasl_auth_enable = no
local_destination_concurrency_limit = 2
local_destination_recipient_limit = 100
local_recipient_maps = unix:passwd.byname $alias_maps
mail_owner = postfix
mailbox_size_limit = 104857600
maildrop_destination_recipient_limit = 1
mailq_path = /usr/local/bin/mailq
manpage_directory = /usr/local/man
maximal_queue_lifetime = 5d
mydestination = $myhostname, localhost.$mydomain, localhost
mail.$mydomain, www.$mydomain, lists.$mydomain, $mydomain
mydomain = stovebolt.com
myhostname = mail.$mydomain
mynetworks = 127.0.0.0/8,216.58.158.170/32
myorigin = $mydomain
newaliases_path = /usr/local/bin/newaliases
owner_request_special = no
postscreen_access_list = permit_mynetworks
postscreen_bare_newline_action = ignore
postscreen_bare_newline_enable = no
postscreen_bare_newline_ttl = 30d
postscreen_blacklist_action = enforce
postscreen_cache_cleanup_interval = 12h
postscreen_cache_map = btree:$data_directory/postscreen_cache
postscreen_cache_retention_time = 7d
postscreen_client_connection_count_limit =
$smtpd_client_connection_count_limit
postscreen_command_count_limit = 20
postscreen_command_filter =
postscreen_command_time_limit = ${stress?10}${stress:300}s
postscreen_disable_vrfy_command = $disable_vrfy_command
postscreen_discard_ehlo_keyword_address_maps =
$smtpd_discard_ehlo_keyword_address_maps
postscreen_discard_ehlo_keywords = $smtpd_discard_ehlo_keywords
postscreen_dnsbl_action = enforce
postscreen_dnsbl_reply_map =
postscreen_dnsbl_sites = bl.spamcop.net, zen.spamhaus.org, dnsbl.sorbs.net
postscreen_dnsbl_threshold = 1
postscreen_dnsbl_ttl = 1h
postscreen_enforce_tls = $smtpd_enforce_tls
postscreen_expansion_filter = $smtpd_expansion_filter
postscreen_forbidden_commands = $smtpd_forbidden_commands
postscreen_greet_action = enforce
postscreen_greet_banner = $smtpd_banner
postscreen_greet_ttl = 1d
postscreen_greet_wait = ${stress?2}${stress:6}s
postscreen_helo_required = $smtpd_helo_required
postscreen_non_smtp_command_action = drop
postscreen_non_smtp_command_enable = no
postscreen_non_smtp_command_ttl = 30d
postscreen_pipelining_action
Re: upgrade broke postfix
--On August 19, 2015 at 4:21:52 PM + Viktor Dukhovni
wrote:
On Wed, Aug 19, 2015 at 10:49:35AM -0500, Paul Schmehl wrote:
After reinstalling, I had problems with policyd-weight. I was seeing
these errors in the logs:
postfix/policyd-weight[17306]: warning: child: err: Undefined subroutine
&Net::DNS::Packet::dn_expand called at /u
sr/local/bin/policyd-weight line 3589, line 26.
You don't have Perl's Net::DNS, or you have an incompatible version.
install a compatible Net::DNS, or an updated policyd-weight or both.
I've removed and reinstalled NET:: DNS and policyd-weight several times.
The error remains.
This morning I got up and checked on the server, and the queue was filled
up. I'm seeing transport errors in the logs: status=deferred (mail
transport unavailable)
WHICH TRANSPORT!!! Why are you "summarizing" the log message?!?
I didn't think I was. That was the entire log message. That's why I'm
confused. I don't even know where to start.
Aug 19 16:39:13 mail postfix/qmgr[35355]: warning: connect to transport
private/filter: No such file or directory
Aug 19 16:40:56 mail postfix/error[35377]: 270572F7001:
to=, relay=none, delay=0.06, delays=0.03/0.01/0/0.03,
dsn=4.3.0, status=deferred (mail transport unavailable)
# cat master.cf | grep -v '#'
smtpsinet n - n - - smtpd
-o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes
You should have more overrides above, to only accept mail from
authenticated users, and otherwise apply fewer restrictions.
I'm not sure what you mean here.
bsmtp unix - n n - - pipe
flags=Fq. user=foo argv=/usr/local/sbin/bsmtp -f $sender $nexthop
$recipient
flags=Rq user=filter argv=/usr/local/bin/filter.sh -f ${sender} --
${recipient}
Something is mangled above, looks like a line is missing, that
startst the definition of the "filter" transport.
That's because the line about it was commented out and that one was
indented. I have now commented it out as well.
filter unix - n n - - pipe
flags=Rq user=filter
argv=/usr/local/bin/filter.sh -f ${sender} -- ${recipient}
smtpd pass - - n - - smtpd
-o content_filter=filter:dummyr
Which is definitely needed.
I am lost and frustrated. I went from a working install to a broken
install. Any help spotting problems would be appreciated.
Post full log entries, not what you consider to be a sufficient
summary.
OK. Will do.
Paul Schmehl (pschm...@tx.rr.com)
Independent Researcher
Re: upgrade broke postfix
--On August 19, 2015 at 5:16:03 PM + Viktor Dukhovni
wrote:
On Wed, Aug 19, 2015 at 11:42:36AM -0500, Paul Schmehl wrote:
Well, with the complete log entry (provided in *this* message), we
see that the "filter" transport is the one that's missing.
>># cat master.cf | grep -v '#'
>> smtpsinet n - n - - smtpd
>> -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes
>
> You should have more overrides above, to only accept mail from
> authenticated users, and otherwise apply fewer restrictions.
>
I'm not sure what you mean here.
The port 465 wrapper-mode service is for mail submission, and so
should allow only authenticated users, and let them send outbound
mail. Or perhaps you don't need it at all, if you don't know
what it is for.
No need to be unkind, Victor. I do this on a volunteer basis, and I'm not
an email expert.
I thought that -o smtpd_sasl_auth_enable=yes meant that only authenticated
users could send mail from outside the domain. Is that not true?
No, that line is needed. Because you've configured Postfix to
use the "filter" transport.
>filter unix - n n - - pipe
> flags=Rq user=filter
> argv=/usr/local/bin/filter.sh -f ${sender} -- ${recipient}
Why would you proceed to fully comment it out, when informed to do
the opposite?
I commented out filter, because it wasn't working. You then complained
about the argv line, because I used grep -v "#" to show what was in the
master.cf file, and that apparently confused you. So I commented it out
was well.
Do you want that "filter.sh" script to scan all inbound mail or not?
Of course I do, but it wasn't working, which is why I removed it.
I'm testing now.
Apparently you need either this entry: smtp inet n - n
- - smtpd -o content_filter=filter:dummyr and this entry: smtpd
pass - - n - - smtpd -o
content_filter=filter:dummyr
Or you need this entry: filterunix - n n - 10
pipe
flags=Rq user=filter argv=/usr/local/bin/filter.sh -f ${sender} --
${recipient} and this entry:
smtpd pass - - n - - smtpd -o
content_filter=filter:dummyr
Is that correct?
Paul Schmehl (pschm...@tx.rr.com)
Independent Researcher
I'm lost (was Re: upgrade broke postfix
I do this once in a blue moon, so troubleshooting problems requires me to
dive back into man pages and try to understand what's going on. The error
that I think is telling me what the problem is is: Aug 19 18:31:43 mail
postfix/qmgr[41135]: warning: connect to transport private/filter:
Connection refused
After that I see tons of these:
status=deferred (mail transport unavailable)
So I think filter is what the problem is. Here is what I have NOW in
master.cf: (I tried changing from the filter.sh script to running mail
directory through the spamassassin daemon.)
smtp inet n - - - - smtpd
-o content_filter=spamassassin
spamassassin unix - n n - - pipe
user=root argv=/usr/local/bin/spamc -f -e
/usr/sbin/sendmail -oi -f ${sender) $(recipient}
smtpsinet n - n - - smtpd
-o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes
-o smtpd_relay_restrictions=permit_sasl_authenticated,reject
pickupfifo n - n 60 1 pickup
cleanup unix n - n - 0 cleanup
qmgr fifo n - n 300 1 qmgr
tlsmgrunix - - n 1000? 1 tlsmgr
rewrite unix - - n - - trivial-rewrite
bounceunix - - n - 0 bounce
defer unix - - n - 0 bounce
trace unix - - n - 0 bounce
verifyunix - - n - 1 verify
flush unix n - n 1000? 0 flush
proxymap unix - - n - - proxymap
smtp unix - - n - - smtp
showq unix n - n - - showq
error 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
scacheunix - - n - 1 scache
maildrop unix - n n - - pipe
flags=DRhu user=vmail argv=/usr/local/bin/maildrop -d ${recipient}
uucp unix - n n - - pipe
flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail
($recipient)
ifmailunix - n n - - pipe
flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp unix - n n - - pipe
flags=Fq. user=foo argv=/usr/local/sbin/bsmtp -f $sender $nexthop
$recipient
relay unix - - n - - smtp
retry unix - - n - - error
proxywrite unix - - n - 1 proxymap
smtp inet n - n - 1 postscreen
smtpd pass - - n - - smtpd -o
content_filter=spamassassin
dnsblog unix - - n - 0 dnsblog
tlsproxy unix - - n - 0 tlsproxy
There's obviously something wrong in here, but what is is escapes me. I
need help.
Paul Schmehl (pschm...@tx.rr.com)
Independent Researcher
Re: I'm lost (was Re: upgrade broke postfix
--On August 19, 2015 at 7:10:00 PM + Viktor Dukhovni
wrote:
On Wed, Aug 19, 2015 at 01:38:34PM -0500, Paul Schmehl wrote:
I do this once in a blue moon, so troubleshooting problems requires me to
dive back into man pages and try to understand what's going on. The
error that I think is telling me what the problem is is: Aug 19 18:31:43
mail postfix/qmgr[41135]: warning: connect to transport private/filter:
Connection refused
If you're still seeing that, you've not read the FILTER_README
reference closely enough.
http://www.postfix.org/FILTER_README.html#simple_turnoff
Turning off the simple content filter
To turn off "simple" content filtering:
It's not that easy to grasp. However, I think I have it working correctly
now. Why the simple filter script no longer works is a complete mystery,
because no changes were made to that or the postfix config. I'm now piping
the mail into spamassassin directly.
smtp inet n - - - - smtpd
-o content_filter=spamassassin
spamassassin unix - n n - - pipe
user=spamd argv=/usr/local/bin/spamc -f -e
/usr/sbin/sendmail -oi -f ${sender} ${recipient}
smtpd pass - - n - - smtpd -o
content_filter=spamassassin:dummy
Paul Schmehl (pschm...@tx.rr.com)
Independent Researcher
Re: upgrade broke postfix
--On August 19, 2015 at 5:47:44 PM + Viktor Dukhovni wrote: On Wed, Aug 19, 2015 at 12:30:55PM -0500, Paul Schmehl wrote: When it is broken, you need to fix it, not comment it out, *and* when commenting out multi-line entries in master.cf, you have to comment out *each* line, not just the first. Normally that's what I try to do. In this case I was stumped. After I got the server working properly again, I began sifting through logs trying to see if there were any clues. I found this in the messages log: /var/log/messages:Aug 19 14:43:21 mail postfix/pipe[17690]: fatal: get_service_attr: unknown username: filter Very weird. That user was created in 2012: /var/log/userlog:2012-09-27 22:46:45 [root:groupadd] filter(1004) /var/log/userlog:2012-09-27 22:46:45 [root:useradd] filter(1004):filter(1004):User &:/home/filter:/bin/bash /var/log/userlog:2012-09-27 22:46:45 [root:useradd] filter(1004) home /home/filter made /var/log/userlog:2012-09-27 22:47:22 [root:usermod] filter(1004):filter(1004):User &:/home/filter:/bin/sh And still exists: # grep filter /etc/passwd filter:*:1004:1004:User &:/home/filter:/bin/sh So why postfix thought the user didn't exist is a mystery, but that's why the filter was no longer working. > Do you want that "filter.sh" script to scan all inbound mail or not? Of course I do, but it wasn't working, which is why I removed it. Well, that can't work, because you're configured to use it. Yes, I wanted spam filtering. And I didn't understand why something that had "just worked" for 3 years suddenly failed. The answer is because Postfix thought the user no longer existed, but I can't tell you why Postfix thinks that. It works now piping directly through spamd. Paul Schmehl (pschm...@tx.rr.com) Independent Researcher
Re: upgrade broke postfix
--On August 20, 2015 at 1:51:11 AM + Viktor Dukhovni wrote: On Wed, Aug 19, 2015 at 06:11:09PM -0500, Paul Schmehl wrote: After I got the server working properly again, I began sifting through logs trying to see if there were any clues. I found this in the messages log: /var/log/messages:Aug 19 14:43:21 mail postfix/pipe[17690]: fatal: get_service_attr: unknown username: filter And still exists: # grep filter /etc/passwd filter:*:1004:1004:User &:/home/filter:/bin/sh This is not the right test. Try: $ getent passwd filter That returns nothing. It does return the line for my account. So what would be the cause of that? So why postfix thought the user didn't exist is a mystery, but that's why the filter was no longer working. Well, your nsswitch.conf might not use /etc/passwd for user lookups, or some nsswitch module might not be installed, ... If you're using "db", you might need something like (example for Debian): # cd /var/lib/misc; make # cat /etc/nsswitch.conf # # nsswitch.conf(5) - name service switch configuration file # $FreeBSD: releng/10.2/etc/nsswitch.conf 224765 2011-08-10 20:52:02Z dougb $ # group: compat group_compat: nis hosts: files dns networks: files passwd: compat passwd_compat: nis shells: files services: compat services_compat: nis protocols: files rpc: files Paul Schmehl (pschm...@tx.rr.com) Independent Researcher
Re: upgrade broke postfix
--On August 20, 2015 at 3:36:45 AM + Viktor Dukhovni wrote: On Wed, Aug 19, 2015 at 10:21:54PM -0500, Paul Schmehl wrote: > This is not the right test. Try: > >$ getent passwd filter That returns nothing. It does return the line for my account. So what would be the cause of that? Missing from the "passwd" sources as listed in nsswitch.conf, ... # cat /etc/nsswitch.conf # # nsswitch.conf(5) - name service switch configuration file # $FreeBSD: releng/10.2/etc/nsswitch.conf 224765 2011-08-10 20:52:02Z # dougb $ # group: compat group_compat: nis hosts: files dns networks: files passwd: compat passwd_compat: nis So looks like you're using "nis" only. Read up on nsswitch.conf and "passwd_compat". At this point you really should be following the evidence where it leads you without hints at every step. The problems are not Postfix-specific. I managed to fix it using the following process: 1) pwd_mkdb -C /etc/password - Inappropriate file format 2) cp /etc/passwd /etc/passwd.bak 3) pwd_mkdb -C /etc/master.passwd (checked out OK) 4) cp /etc/master.passwd /etc/passwd 5) pwd_mkdb -u filter /etc/passwd After that, getent passwd filter returned the line. So I assume it will now work, although I won't test it until later. Paul Schmehl (pschm...@tx.rr.com) Independent Researcher
Re: Can Postscreen and Smapassassin be used together
--On September 10, 2015 at 7:37:09 AM +0100 Robert Chalmers
wrote:
I’m currently running postscreen, and am wondering how I would add
spamassassin to the main.cf configuration, or are they mutually exclusive?
After reading all the answers (I confess I was amazed by some of them), I
can assure you that you can run the two together. I have been for years.
You don't add spamassassin filtering to main.cf, however. You add it to
master.cf.
Here's the relevant sections in my master.cf, but you need to read the
FILTER_README docs and understand them before implementing this:
DO NOT JUST COPY THIS STUFF WITHOUT READING THE DOCS:
# grep filter /usr/local/etc/postfix/master.cf
smtp inet n - n - - smtpd -o
content_filter=filter:dummyr
filterunix - n n - 10 pipe
flags=Rq user=filter argv=/usr/local/bin/filter.sh -f ${sender} --
${recipient}
smtpd pass - - n - - smtpd -o
content_filter=filter:dummy
If you want to run mail through spamd, you would use something like this:
#smtp inet n - - - - smtpd
# -o content_filter=spamassassin
#spamassassin unix - n n - - pipe
# user=spamd argv=/usr/local/bin/spamc -f -e
# /usr/sbin/sendmail -oi -f ${sender} ${recipient}n
The filter script is in the FILTER_README doc. Read it carefully.
You can either feed mail directly to the spamassassin daemon, spamd, or fun
it through a filter script that calls spamassassin for each individual
email. I've tried both, but I use the filter script because it allows me
to write mail to a directory and then sort through it for any legitimate
mail. And frankly, there is very little, if any, legitimate mail in there.
This is a very small mail domain with only two recipients. The owners
don't want to see spam at all, so I am very aggressive. I also send
anything lower than 5 to myself so I can screen it before they see it.
Here's my filter script, which is essentially a ripoff of Weitse's script:
#!/bin/sh
# Simple shell-based filter. It is meant to be invoked as follows:
# /path/to/script -f sender recipients...
# Localize these.
INSPECT_DIR=/usr/local/filter
SPAMDIR=/var/spool/spam
SENDMAIL="/usr/sbin/sendmail -i"
SPAMASSASSIN=/usr/local/bin/spamassassin
SPAMLIMIT=5
SPAMCK=4
# Exit codes from
EX_TEMPFAIL=75
EX_UNAVAILABLE=69
# Start processing.
cd $INSPECT_DIR || {
echo $INSPECT_DIR does not exist; exit $EX_TEMPFAIL; }
# Clean up when done or when aborting.
trap "rm -f in.$$" 0 1 2 3 15
cat | $SPAMASSASSIN -x > out.$$ || \
{ echo Cannot save mail to file; exit $EX_TEMPFAIL; }
if egrep -q "^X-Spam-Level: \*{$SPAMLIMIT,}" < out.$$
then
mv out.$$ $SPAMDIR
elif egrep -q "^X-Spam-Level: \*{$SPAMCK,}" < out.$$
then
$SENDMAIL geek < out.$$
else
$SENDMAIL "$@" < out.$$
fi
trap "rm -f out.$$" 0 1 2 3 15
exit $?
Paul Schmehl (pschm...@tx.rr.com)
Independent Researcher
Re: 53% of Postfix servers are black-listed (DNSBL)
This is baloney. 94% of Exchange servers are open relays but ZERO percent are blacklisted? This entire thing is one steaming pile of crap. --On December 29, 2015 at 1:01:30 PM +0100 sb wrote: 90% of global e-mail is SPAM. 91% of targeted attacks start with e-mail. What is Postfix's share of SPAM? A recent survey of 2.8M SMTP servers shows the following. - 53% of Postfix servers are black-listed (DNSBL) http://www.mailradar.com/mailstat/mta/Postfix.html - 44% of open relays are Postfix servers http://www.mailradar.com/mailstat/open-relay/ - 35% of Postfix servers are hosted in the USA http://www.mailradar.com/mailstat/mta/Postfix.html Who makes Postfix? -- Wietse Venema IBM T.J. Watson Research P.O. Box 704 Yorktown Heights, NY 10598, USA What is Postfix's share of the SMTP server market? -- A recent survey of 2.3M SMTP servers shows the following. # 1: 53.25% EXIM # 2: 32.64% POSTFIX # 3: 6.66% SENDMAIL http://www.securityspace.com/s_survey/data/man.201511/mxsurvey.html What is wrong with Postfix? --- Suppose you are a school/SME/you-name-it, you want a secure server, and you run Postfix. The following is what you get in your inbox. Date: Thu, 17 Dec 2015 15:6:1 From: paulnoah@ Message-ID: <8038f16fe88ca0b6a66649d005c232e9@localhost.localdomain> Received: from 1-160-101-156.dynamic.hinet.net ([1.160.101.156]:52001 helo=uwtir.com) by seth.lunarpages.com with esmtpsa [...] Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.baycix.de (Postfix) with ESMTP id E7078416A85 [...] Received: from [127.0.0.1] by omp1062.mail.bf1.yahoo.com with NNFMP; 25 Dec 2015 23:24:21 - Received: from uhosp.example.com ([37.230.116.83]) Received: [...] ... Message-ID: [...] <--- Delivered-To: [...] Received: [...] Received: [...] [anonymised] To: ... Reply-To: There are more examples, and the all reduce to Postfix accepting incoming e-mail whose origin and envelope are not RFC compliant. In fact, the task of writing PCRE parsers and policies is delegated to the user, that is you, as part of your own configuration (access, helo_access, header_checks, etc). Writing such parsers and policies is highly rewarding: my servers reject 95% of SPAM by rejecting non-RFC-compliant e-mails, without any DNSxL or anti-spam add-on. The task required months of full-time labour. The same task cannot be brought to completion, however. The postfix-users forum would be a good place where to discuss Postfix's problems in detail. However, the same forum is rather focused on self-celebration than active collaboration, where attempts to address SPAM as a problem are scornfully dismissed. Given the above statistics, this is no longer surprising. Postfix is easy on the spammers and hard on the honest. unsubscribe postfix-users "The man who never looks into a newspaper is better informed than he who reads them, inasmuch as he who knows nothing is nearer the truth than he whose mind is filled with falsehoods and errors." - Thomas Jefferson Paul Schmehl (pschm...@tx.rr.com) Independent Researcher
Re: Open relay
--On October 22, 2016 at 12:16:33 PM +0200 Paul van der Vlis wrote: Op 22-10-16 om 04:32 schreef Bill Cole: On 21 Oct 2016, at 16:15, Paul van der Vlis wrote: Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi [87.92.55.206]) (Authenticated sender: p...@puk.nl) by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285; Fri, 21 Oct 2016 18:57:14 +0200 (CEST) As would my server sent it to my server... Not exactly. That Received header indicates that the machine at 87.92.55.206 which is actually named 87-92-55-206.bb.dnainternet.fi introduced itself with "EHLO [127.0.0.1]" on an encrypted session and proceeded to authenticate as the user whose name you've replaced with p...@puk.nl. As a stopgap, you could add a directive like this to smtpd_helo_restrictions: check_helo_access pcre:/etc/postfix/helo_checks And in that helo_checks file; /127\.0\.0\.1/REJECT you are not me Thanks, a great idea to have standard in most cases. I would make one suggestion. I would reject the attempt silently. No sense in tipping off the spammer to what he needs to do to work around it. Just use REJECT with no explanation. "The man who never looks into a newspaper is better informed than he who reads them, inasmuch as he who knows nothing is nearer the truth than he whose mind is filled with falsehoods and errors." - Thomas Jefferson Paul Schmehl (pschm...@tx.rr.com) Independent Researcher
Re: Open relay
--On October 22, 2016 at 11:27:56 AM -0500 "/dev/rob0" wrote: On Sat, Oct 22, 2016 at 11:19:36AM -0500, Paul Schmehl wrote: --On October 22, 2016 at 12:16:33 PM +0200 Paul van der Vlis wrote: > Op 22-10-16 om 04:32 schreef Bill Cole: >>/127\.0\.0\.1/REJECT you are not me > > Thanks, a great idea to have standard in most cases. I would make one suggestion. I would reject the attempt silently. No sense in tipping off the spammer to what he needs to do to work around it. Just use REJECT with no explanation. The point of rejection messages is in case a human comes up against it (and even this one, it could happen.) You need to let a novice postmaster know what s/he has misconfigured. There is zero evidence over 2 decades that botnet spammers even have the capability to receive and parse their rejection messages, much less the interest in doing so. I wonder how you explain, over the past two decades, how spammers keep adjusting their tactics to get around the defenses that are put up to foil them. Precognition? We've been fighting this battle for, as you say, the past two decades, and the spammers have been successful at getting around our defenses. I could list the many things we've done that they've overcome, but why bother? You're clearly experienced enough to know what they are. "The man who never looks into a newspaper is better informed than he who reads them, inasmuch as he who knows nothing is nearer the truth than he whose mind is filled with falsehoods and errors." - Thomas Jefferson Paul Schmehl (pschm...@tx.rr.com) Independent Researcher
Re: Open relay
--On October 22, 2016 at 1:51:12 PM -0400 Bill Cole wrote: On 22 Oct 2016, at 12:19, Paul Schmehl wrote: I would make one suggestion. I would reject the attempt silently. No sense in tipping off the spammer to what he needs to do to work around it. Just use REJECT with no explanation. That's a nice hypothesis but it doesn't seem to play out in reality. I've been emitting specific (and yes, sometimes snarky) rejection messages on a variety of systems for all sorts of access rules, in part so I can keep track of what rules are being hit easily. I have never seen any hint that spammers behaving in grossly fraudulent ways (like EHLO arguments that claim to be the server they're talking to) substantively change their behavior in response to those messages. Keep in mind that essentially ANY idiosyncratically wrong EHLO argument seen only from spammers has been configured intentionally by someone who has no idea how cheap, simple, and reliable it is to reject spam on that basis. These are cognitively impaired spammers, not smart ones. The smart ones try very hard to look very normal and legitimate, not to stand out as something starkly different from any legitimate mail. And you don't think this spammer fits into the latter category? He's clearly doing something very clever that is not the usual brute force cram-it-down-your-throat spam run. "The man who never looks into a newspaper is better informed than he who reads them, inasmuch as he who knows nothing is nearer the truth than he whose mind is filled with falsehoods and errors." - Thomas Jefferson Paul Schmehl (pschm...@tx.rr.com) Independent Researcher
Puzzling problem
1s Jan 9 04:05:37 mail postfix/smtpd[35245]: C27AB2F1513: client=ip-001.utdallas.edu[129.110.180.40] Jan 9 04:05:37 mail postfix/cleanup[35248]: C27AB2F1513: message-id=<43F88331AA2D150AEFE9BB60@Pauls-MacBook-Pro.local> Jan 9 04:05:37 mail postfix/qmgr[5989]: C27AB2F1513: from=, size=1467, nrcpt=1 (queue active) Jan 9 04:05:42 mail postfix/smtpd[35245]: disconnect from ip-001.utdallas.edu[129.110.180.40] Jan 9 04:05:44 mail postfix/pickup[30226]: CBE712F157D: uid=1004 from= Jan 9 04:05:44 mail postfix/cleanup[35248]: CBE712F157D: message-id=<43F88331AA2D150AEFE9BB60@Pauls-MacBook-Pro.local> Jan 9 04:05:44 mail postfix/pipe[35249]: C27AB2F1513: to=, relay=filter, delay=8, delays=1.1/0.01/0/6.9, dsn=2.0.0, status=sent (delivered via filter service) Jan 9 04:05:44 mail postfix/qmgr[5989]: C27AB2F1513: removed Jan 9 04:05:44 mail postfix/qmgr[5989]: CBE712F157D: from=, size=1810, nrcpt=1 (queue active) Jan 9 04:05:44 mail postfix/local[35259]: warning: database /usr/local/mailman/data/aliases.db is older than source file /usr/local/mailman/data/aliases Jan 9 04:05:44 mail postfix/local[35259]: CBE712F157D: to=, relay=local, delay=0.07, delays=0.04/0.01/0/0.02, dsn=2.0.0, status=sent (delivered to maildir) Jan 9 04:05:44 mail postfix/qmgr[5989]: CBE712F157D: removed I am stumped. The filter.sh script is verbatim the one scraped from Weitse's pages. Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson "There are some ideas so wrong that only a very intelligent person could believe in them." George Orwell
Re: Puzzling problem
--On January 9, 2014 at 11:31:30 AM +0100 Marko Weber | ZBF wrote: Command died with status 1: "/usr/local/bin/filter.sh". Command output: Jan 9 02:49:28.913 [29829] warn: netset: cannot include 127.0.0.0/32 as it has already been included Jan 9 02:49:28.913 [29829] warn: netset: illegal network address given: '216.58.158.271' rm: out.29827: No such file or directory That is a bug in the NetAddr::IP Perl module that's affecting spamassassin. Cf. <https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6681> In reviewing my mail logs, it appears that every time that bug manifests itself, the mail is rejected, so that looks like the path I need to go down. Not sure why it's being triggered every time the form mail arrives, but I'm going to try constructing proper email headers for the message before sending it to see if that resolves the issue. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson "There are some ideas so wrong that only a very intelligent person could believe in them." George Orwell
Re: Puzzling problem
--On January 9, 2014 at 11:00:30 AM + Duane Hill wrote: Thursday, January 9, 2014, 10:31:30 AM, you wrote: Command died with status 1: "/usr/local/bin/filter.sh". Command output: Jan 9 02:49:28.913 [29829] warn: netset: cannot include 127.0.0.0/32 as it has already been included Jan 9 02:49:28.913 [29829] warn: netset: illegal network address given: '216.58.158.271' rm: out.29827: No such file or directory I am not a network Pro, but 127.0.0.0 is the first available address, and is reserved , also the last one 127.0.0.255 is reserved. (broadcast) so, for me it has to be 127.0.0.1/32 for the first usable address and 172.0.0.0/8 if you plan to use a wider range. warn: netset: illegal network < ! i think its bcause u used 127.0.0.0/32. can u give it a try with 127.0.0.1/32 ? That is a warning from SpamAssassin stating 127.0.0.0/32 is already included as an internal network. Therefore, the OP should remove the internal network configuration option from the SpamAssassin config. Thanks. That solved the problem. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson "There are some ideas so wrong that only a very intelligent person could believe in them." George Orwell
Problem with filter
Years ago I setup postfix using the filter script that Wietse wrote to integrate spamassassin into my mail setup. It's worked fine for a long time. smtp inet n - n - - smtpd -o content_filter=filter:dummyr On Monday, I updated the server from freebsd-10.4-RELEASE to 11.2-RELEASE. This included a reinstall of all ports, since it was a major version upgrade. Now I'm getting very strange errors. In the logs: Dec 10 22:08:39 mail postfix/pipe[83221]: fatal: get_service_attr: unknown username: filter Dec 10 22:08:40 mail postfix/qmgr[25686]: warning: private/filter socket: malformed response Dec 10 22:08:40 mail postfix/qmgr[25686]: warning: transport filter failure -- see a previous warning/fatal/panic logfile record for the problem description Dec 10 22:08:40 mail postfix/master[25684]: warning: process /usr/local/libexec/postfix/pipe pid 83221 exit status 1 Dec 10 22:08:40 mail postfix/master[25684]: warning: /usr/local/libexec/postfix/pipe: bad command startup -- throttling As a result, mail is not being delivered to courier but is piling up in the queue (except for internal mail, of course). The problem is, filter IS a legitimate user: # grep filter /etc/passwd filter:*:1004:1004:User &:/home/filter:/bin/sh And the passwd file is world-readable: # ls -lsa /etc/passwd 4 -rw-r--r-- 1 root wheel 2931 Dec 10 22:04 /etc/passwd So why does postfix think this user does not exist? The log entry above is the first instance of the error, and I believe all errors are logged to /var/log/maillog. I've verified that filter's home directory exists and is owned by him as well as the directory where filter puts emails that are detected to be spam. There is one anomaly in his home directory that strikes me as a possible clue. ls -lsa /home/filter/ total 24 2 drwxr-xr-x 4 1004 filter 512 Sep 27 2012 . 2 drwxr-xr-x 13 root wheel 512 Nov 19 2017 .. 2 -rw-r--r-- 1 1004 filter 751 Sep 27 2012 .cshrc 2 -rw-r--r-- 1 1004 filter 248 Sep 27 2012 .login 2 -rw-r--r-- 1 1004 filter 158 Sep 27 2012 .login_conf 2 -rw--- 1 1004 filter 373 Sep 27 2012 .mail_aliases 2 -rw-r--r-- 1 1004 filter 331 Sep 27 2012 .mailrc 2 -rw-r--r-- 1 1004 filter 766 Sep 27 2012 .profile 2 -rw--- 1 1004 filter 276 Sep 27 2012 .rhosts 2 -rw-r--r-- 1 1004 filter 975 Sep 27 2012 .shrc 2 drwx-- 2 1004 filter 512 Dec 10 21:45 .spamassassin 2 drwx-- 5 1004 filter 512 Sep 27 2012 Maildir Note that the .spamassassin folder was created on Dec 10, the day of the upgrade. Everything else dates back to the origin of the directory. Everything spamassassin-related used to be in /usr/local/etc/mail/spamassassin, including bayes_seen, and all of those files are owned by filter as well. The following items are in that folder: # ls -lsa /home/filter/.spamassassin/ total 25056 2 drwx-- 2 1004 filter 512 Dec 10 21:45 . 2 drwxr-xr-x 4 1004 filter 512 Sep 27 2012 .. 2592 -rw--- 1 1004 filter 2633728 Sep 27 2012 auto-whitelist 12 -rw--- 1 1004 filter 11448 Dec 10 21:58 bayes_journal 18304 -rw--- 1 1004 filter 20299776 Dec 10 21:45 bayes_seen 4144 -rw--- 1 1004 filter 5193728 Dec 10 21:45 bayes_toks 0 -rw-r--r-- 1 1004 filter 0 Dec 26 2012 user_prefs I'm at a loss. It's probably something obvious, but I don't see it. Paul Schmehl Independent Researcher
Re: Problem with filter
--On December 13, 2018 at 6:54:48 PM +0100 Benny Pedersen wrote: Paul Schmehl skrev den 2018-12-13 18:36: # ls -lsa /home/filter/.spamassassin/ total 25056 2 drwx-- 2 1004 filter 512 Dec 10 21:45 . why is 1004 when it should be ascii usernamme ? what user is 1004 ?, its imho not known in your system id 1004 1004 is the uid of filter. It shouldn't make a difference since the ascii name and uid refer to the same account. Paul Schmehl Independent Researcher
Re: Problem with filter
--On December 13, 2018 at 2:36:44 PM -0500 Viktor Dukhovni wrote: On Dec 13, 2018, at 2:33 PM, Paul Schmehl wrote: # ls -lsa /home/filter/.spamassassin/ total 25056 2 drwx-- 2 1004 filter 512 Dec 10 21:45 . why is 1004 when it should be ascii usernamme ? what user is 1004 ?, its imho not known in your system id 1004 1004 is the uid of filter. It shouldn't make a difference since the ascii name and uid refer to the same account. It makes all the difference, since "ls -l" shows that the uid does not in fact resolve to that user name. Perhaps there's a syntax error earlier in your passwd file? And perhaps the user is missing from the "shadow" password file... The user does not exist until "ls -l" is able to correctly identify the files as belonging to the user. Hmmm...thank you, Victor. I'll try to sort that out. Paul Schmehl Independent Researcher
Re: Problem with filter
--On December 13, 2018 at 9:00:06 PM +0100 Benny Pedersen wrote: Paul Schmehl skrev den 2018-12-13 20:45: The user does not exist until "ls -l" is able to correctly identify the files as belonging to the user. Hmmm...thank you, Victor. I'll try to sort that out. if its more simple, change to use spampd so spamassassin is smtp content filter seen from postfix its have being rock solid for me, and i only use clamav-milter for virus scanning, and opendmarc, opendkim, spf-policyd, thats all i need :=) That's what I've been doing, but apparently my /etc/passwd file is screwed up. Paul Schmehl Independent Researcher
Maillog error - warn: Unescaped left brace in regex is deprecated here (and will be fata))
I'm seeing this error in the logs: warn: Unescaped left brace in regex is deprecated here (and will be fata)) It comes right after this: status=sent (delivered via filter service The filter service uses filter.sh (stolen from the docs) and spamassassin. Is it safe to assume this is a code problem in spam assassin (which I assume they will fix at some point)? Googling says it's a perl error, so it can't be the filter shell script. Paul Schmehl Independent Researcher
Re: Maillog error - warn: Unescaped left brace in regex is deprecated here (and will be fata))
--On December 14, 2018 at 3:32:11 PM -0500 Bill Cole
wrote:
On 14 Dec 2018, at 0:46, Paul Schmehl wrote:
I'm seeing this error in the logs:
warn: Unescaped left brace in regex is deprecated here (and will be
fata))
This is a new warning in Perl 5.26. The use of curly-brace regex
enumeration ranges with an implied zero first term ( e.g. {,5} instead of
{0,5} ) will be a fatal error in a later version (maybe 5.28, I have not
checked...)
It would be a wise choice to update ALL of your Perl modules to the
latest releases, as this issue can arise in non-obvious places...
It comes right after this:
status=sent (delivered via filter service
The filter service uses filter.sh (stolen from the docs) and
spamassassin. Is it safe to assume this is a code problem in spam
assassin (which I assume they will fix at some point)?
Not if you're using the current release (3.4.2) of SpamAssassin. As one
of the developers who worked on that specific issue, I am sure that we
believed all cases of that problem that were internal to the SpamAssassin
framework were fixed in 3.4.2. There are a lot of modules which SA
depends on, some of which can also cause that warning.
# spamassassin -V
SpamAssassin version 3.4.2
running on Perl version 5.26.3
Thanks, Bill. Guess I'll start rummaging through the modules.
Paul Schmehl
Independent Researcher
Re: Maillog error - warn: Unescaped left brace in regex is deprecated here (and will be fata))
--On December 14, 2018 at 3:32:11 PM -0500 Bill Cole
wrote:
On 14 Dec 2018, at 0:46, Paul Schmehl wrote:
I'm seeing this error in the logs:
warn: Unescaped left brace in regex is deprecated here (and will be
fata))
It would be a wise choice to update ALL of your Perl modules to the
latest releases, as this issue can arise in non-obvious places...
So, I would assume it would be one of these modules?
BUILD_DEPENDS= p5-Encode-Detect>=0:converters/p5-Encode-Detect \
p5-HTML-Parser>=3.46:www/p5-HTML-Parser \
p5-HTTP-Date>=0:www/p5-HTTP-Date \
p5-Net-DNS>=0.63:dns/p5-Net-DNS \
p5-NetAddr-IP>=4.010:net-mgmt/p5-NetAddr-IP
RUN_DEPENDS:= ${BUILD_DEPENDS} \
p5-Net-IDN-Encode>=0:textproc/p5-Net-IDN-Encode \
p5-Net-LibIDN>=0:dns/p5-Net-LibIDN \
p5-URI>=0:net/p5-URI \
re2c>=.12.0:devel/re2c
Paul Schmehl
Independent Researcher
Re: Problem with filter
--On December 14, 2018 at 2:49:36 PM -0700 "@lbutlr" wrote: On 13 Dec 2018, at 20:05, Paul Schmehl wrote: --On December 13, 2018 at 9:00:06 PM +0100 Benny Pedersen wrote: Paul Schmehl skrev den 2018-12-13 20:45: The user does not exist until "ls -l" is able to correctly identify the files as belonging to the user. Hmmm...thank you, Victor. I'll try to sort that out. [snipped] That's what I've been doing, but apparently my /etc/passwd file is screwed up. I had a similar issue when I moved from 10.x to 11.x where a user account line in the passwd field was mangled in some minor way and it cause the rest of the passed file to not be processed. I had to run fsck twice to get the system back up and running. I do not recall the details, but I think on UID was changed from something like 1015 to 115? So, look at the passwd file and move the ‘filter’ user earlier in the file, If that fixes it, you can then use the id command to check each UID later in the file to narrow down where the problem is. It's fixed now. I ran pwd_mkdb -C and it reported that the file was corrupted. Which is pretty useless, because it says the same thing on a perfectly fine passwd file. At any rate, I rebuilt it, and that did the trick. Paul Schmehl Independent Researcher
Re: Maillog error - warn: Unescaped left brace in regex is deprecated here (and will be fata))
--On December 14, 2018 at 4:09:08 PM -0500 Bill Cole
wrote:
On 14 Dec 2018, at 15:32, Bill Cole wrote:
On 14 Dec 2018, at 0:46, Paul Schmehl wrote:
I'm seeing this error in the logs:
warn: Unescaped left brace in regex is deprecated here (and will be
fata))
NOTE: that message should specify the source of the error. If it does
not, something in your logging plumbing is mangling error messages.
I tried increasing the debug level and even added -v to the pipe line in
master.cf, but the message was the same. This is the entire line.
Dec 15 18:50:32 mail postfix/pipe[33227]: A3CE22F157E:
to=, relay=filter, delay=13, delays=3.7/0/0/9.7,
dsn=2.0.0, status=sent (delivered via filter service (Dec 15 18:50:25.479
[33256] warn: Unescaped left brace in regex is deprecated here (and will be
fata))
These are the lines in master.cf that points to the pipe for filter:
# grep filter /usr/local/etc/postfix/master.cf
smtp inet n - n - - smtpd -o
content_filter=filter:dummyr
# -o content_filter=spamassassin
filterunix - n n - 10 pipe
flags=Rq user=filter argv=/usr/local/bin/filter.sh -f ${sender} --
${recipient}
smtpd pass - - n - - smtpd -o
content_filter=filter:dummy
Also note: there is at least one 3rd-party ruleset (http://sa.zmi.at)
which appears to have had a typo ('.' where a ',' should have been) which
also resulted in this error message in a recent version. See
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7669 for a report of
this issue (which is not a bug in SA per se, as the rules with the typo
are an independent distribution.)
I checked for this problem in the SA rules, but didn't find any problems.
I'm using the default set, and my research says these have all been fixed.
So, the problem must be in an affiliated perl module, but I have no idea
how to find it.
Everything on this server is up to date. I just upgraded to 11.2-RELEASE
last week and rebuilt all the ports. I've run portmaster -ad twice since
and updated several other ports.
If there's a way to do it, I'd like to run this problem down and notify the
developer, but I have no clue how to go about that. I don't know how to
setup a trace on the filter process.
Paul Schmehl
Independent Researcher
Re: Maillog error - warn: Unescaped left brace in regex is deprecated here (and will be fata))
--On December 14, 2018 at 4:09:08 PM -0500 Bill Cole
wrote:
On 14 Dec 2018, at 15:32, Bill Cole wrote:
On 14 Dec 2018, at 0:46, Paul Schmehl wrote:
I'm seeing this error in the logs:
warn: Unescaped left brace in regex is deprecated here (and will be
fata))
NOTE: that message should specify the source of the error. If it does
not, something in your logging plumbing is mangling error messages.
Also note: there is at least one 3rd-party ruleset (http://sa.zmi.at)
which appears to have had a typo ('.' where a ',' should have been) which
also resulted in this error message in a recent version. See
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7669 for a report of
this issue (which is not a bug in SA per se, as the rules with the typo
are an independent distribution.)
I did the following searches trying to locate this issue:
# grep -ro "\[,.\]" /usr/local/lib/perl5/site_perl/*
/usr/local/lib/perl5/site_perl/LWP/Authen/Digest.pm:[,;]
/usr/local/lib/perl5/site_perl/LWP/Authen/Digest.pm:[,;]
/usr/local/lib/perl5/site_perl/Mail/Header.pm:[,;]
/usr/local/lib/perl5/site_perl/Mail/SpamAssassin/ArchiveIterator.pm:[,.]
# grep -ro "{,.}" /usr/local/lib/perl5/site_perl/*
/usr/local/lib/perl5/site_perl/Text/Unidecode/x0f.pm:{, }
/usr/local/lib/perl5/site_perl/Text/Unidecode/x18.pm:{, }
{, }
/usr/local/lib/perl5/site_perl/Text/Unidecode/x20.pm:{,,}
/usr/local/lib/perl5/site_perl/Text/Unidecode/x30.pm:{, }
/usr/local/lib/perl5/site_perl/Text/Unidecode/x30.pm:{,,}
/usr/local/lib/perl5/site_perl/Text/Unidecode/x00.pm:{,,}
/usr/local/lib/perl5/site_perl/mach/5.26/opie.ph:{,;}
The same searches run on SA rules found one possible issue:
# grep -ro "\[,.\]" /usr/local/etc/mail/spamassassin/*
/usr/local/etc/mail/spamassassin/70_sare_specific.cf:[,s
I say possible because in my researching this issue I've seen both curly
braces only and also both curly braces and square braces, so I'm not
completely certain which (or if both) are a problem.
At any rate, I don't see any dependency on Text::Unicode, although I
wouldn't be surprised if it's used by SA.
If square braces are included as well, then Mail::Header and
ArchiveIterator.pm would likely be potential culprits for the error message.
If parenthetical braces are also implicated, then there is an additional
potential problem:
# grep -ro "(,.)" /usr/local/lib/perl5/site_perl/*
/usr/local/lib/perl5/site_perl/mach/5.26/sys/lock.ph:(, )
/usr/local/lib/perl5/site_perl/mach/5.26/sys/lock.ph:(, )
At this point, I need an experienced programmer to decipher all this and
let me know where the issue(s) might be.
Paul Schmehl
Independent Researcher
Re: Maillog error - warn: Unescaped left brace in regex is deprecated here (and will be fata))
--On December 15, 2018 at 9:36:56 PM -0500 Bill Cole wrote: Remove any rules file with 'sare' in its name. It would also be wise to make sure that you are running 'sa-update' regularly (weekly at least, ideally daily) to be sure that you have the current default ruleset. Thanks, Bill. I'll do that right away. Paul Schmehl Independent Researcher
Re: Maillog error - warn: Unescaped left brace in regex is deprecated here (and will be fata))
--On December 15, 2018 at 9:36:56 PM -0500 Bill Cole wrote: On 15 Dec 2018, at 14:00, Paul Schmehl wrote: --On December 14, 2018 at 4:09:08 PM -0500 Bill Cole wrote: On 14 Dec 2018, at 15:32, Bill Cole wrote: On 14 Dec 2018, at 0:46, Paul Schmehl wrote: I'm seeing this error in the logs: warn: Unescaped left brace in regex is deprecated here (and will be fata)) NOTE: that message should specify the source of the error. If it does not, something in your logging plumbing is mangling error messages. I tried increasing the debug level and even added -v to the pipe line in master.cf, but the message was the same. This is the entire line. Dec 15 18:50:32 mail postfix/pipe[33227]: A3CE22F157E: to=, relay=filter, delay=13, delays=3.7/0/0/9.7, dsn=2.0.0, status=sent (delivered via filter service (Dec 15 18:50:25.479 [33256] warn: Unescaped left brace in regex is deprecated here (and will be fata)) That's broken... Something between Perl and your log is mangling and truncating the error message. Maybe the Postfix 'pipe' plumbing? That's a secondary issue though, as it is easy to run SA by itself to. find the problem. Try this: spamassassin -D all --lint That should give you a large amount of debug output including the original error message with a file & line reference. These are the lines in master.cf that points to the pipe for filter: [...] That solved the problem. It was a single ruleset, and I removed it. I thought I only had default rulesets, but I guess I added a few extra ones over the years. Thanks for your help. Errors bug me to no end, as you've probably figured out by now. Paul Schmehl Independent Researcher
Re: Why am I accepting this email?
--On May 24, 2017 at 9:25:30 AM -0400 D'Arcy Cain wrote: The following is in my logs. I have no server called nan.vex.net and no user called aida.wanda. I don't see anything in main.cf that looks like a wild card entry. Can anyone suggest why I would be accepting this message in the first place? I really don't want to back-scatter. May 22 20:11:59 smaug postfix/smtpd[5457]: BBA8F3F9F1CA: client=mx-n07.wc1.phx1.stabletransit.com[207.246.241.253] May 22 20:11:59 smaug postfix/cleanup[8796]: BBA8F3F9F1CA: message-id=<20170523001149.8c76f642...@mx-n07.wc1.phx1.stabletransit.com> May 22 20:12:00 smaug postfix/qmgr[347]: BBA8F3F9F1CA: from=, size=22692, nrcpt=1 (queue active) May 22 This message was accepted. ^ 20:12:00 smaug postfix/smtp[9232]: BBA8F3F9F1CA: to=, relay=none, delay=0.34, delays=0.33/0.01/0/0, dsn=5.4.6, status=bounced (mail for nan.vex.net loops back to myself) May 22 20:12:00 smaug postfix/bounce[3630]: ^^^ BBA8F3F9F1CA: sender non-delivery notification: 1D2793F9F1D8 May 22 20:12:00 smaug postfix/qmgr[347]: BBA8F3F9F1CA: removed This message was rejected. "The man who never looks into a newspaper is better informed than he who reads them, inasmuch as he who knows nothing is nearer the truth than he whose mind is filled with falsehoods and errors." - Thomas Jefferson Paul Schmehl (pschm...@tx.rr.com) Independent Researcher
