Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: header checks not working
1,255 views
Skip to first unread message
Den
Sep 11, 2014, 11:24:40 AM9/11/14
to
Hello there,
I understand this post is quite old but I would really highly appreciate any
help / suggestions at all as I have absolutely the same problem.. well,
almost.
I am completely lost trying to discard emails via header_checks.
My rules are as follows:
/^Subject:.*\*{5}SPAM\*{5}/ DISCARD *SPAM*
/^X-Spam-Flag: YES/ DISCARD Spam 1
/^X-Spam-Flag .YES/ DISCARD Spam 2
/^Subject:(.*)SPAM/ DISCARD 8
They all do work well because testing them via postmap doesn't report any
issues. For example running the following:
postmap -q "X-Spam-Flag: YES/" regexp:/etc/postfix/filter
returns DISCARD Spam 1 as per my rules above.
I do not have any of these "receive_override_options=no_header_body_checks"
in my master.cf or any other places anywhere.
Now the following test also runs well as per my above-mentioned rules:
postmap -q "Subject: *****SPAM*****
XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X"
regexp:/etc/postfix/filter
DISCARD *SPAM*
Now the most interesting part is that the email with the subject line
(above) I am testing goes through right into my inbox, like a stone through
air without anything ever stopping it.
I also tried pcre but the results are the same. "Air won't stop stones, they
get right through it."
I would be really so much thankful if anybody could at least point / suggest
/ advise / comment how to solve this.
My postconf -m says I have pcre and regexp available and installed.
I am completely stuck and this is beyond my understanding. I am starting to
think that I've come up with a test string in my subject that passes through
absolutely any rules... I don't know if that is ever possible though... This
is the rules' killer subject line:
XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X
The X-Spam-Flag header as well as the other regular headers are successfully
created, the subject also gets appended correctly that is *****SPAM***** is
added...
I have now run out of any ideas where else to look. Would be so much
grateful indeed for any assistance at all! Many thanks in advance!
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70570.html
Sent from the Postfix Users mailing list archive at Nabble.com.
I understand this post is quite old but I would really highly appreciate any
help / suggestions at all as I have absolutely the same problem.. well,
almost.
I am completely lost trying to discard emails via header_checks.
My rules are as follows:
/^Subject:.*\*{5}SPAM\*{5}/ DISCARD *SPAM*
/^X-Spam-Flag: YES/ DISCARD Spam 1
/^X-Spam-Flag .YES/ DISCARD Spam 2
/^Subject:(.*)SPAM/ DISCARD 8
They all do work well because testing them via postmap doesn't report any
issues. For example running the following:
postmap -q "X-Spam-Flag: YES/" regexp:/etc/postfix/filter
returns DISCARD Spam 1 as per my rules above.
I do not have any of these "receive_override_options=no_header_body_checks"
in my master.cf or any other places anywhere.
Now the following test also runs well as per my above-mentioned rules:
postmap -q "Subject: *****SPAM*****
XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X"
regexp:/etc/postfix/filter
DISCARD *SPAM*
Now the most interesting part is that the email with the subject line
(above) I am testing goes through right into my inbox, like a stone through
air without anything ever stopping it.
I also tried pcre but the results are the same. "Air won't stop stones, they
get right through it."
I would be really so much thankful if anybody could at least point / suggest
/ advise / comment how to solve this.
My postconf -m says I have pcre and regexp available and installed.
I am completely stuck and this is beyond my understanding. I am starting to
think that I've come up with a test string in my subject that passes through
absolutely any rules... I don't know if that is ever possible though... This
is the rules' killer subject line:
XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X
The X-Spam-Flag header as well as the other regular headers are successfully
created, the subject also gets appended correctly that is *****SPAM***** is
added...
I have now run out of any ideas where else to look. Would be so much
grateful indeed for any assistance at all! Many thanks in advance!
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70570.html
Sent from the Postfix Users mailing list archive at Nabble.com.
Wietse Venema
Sep 11, 2014, 11:40:11 AM9/11/14
to
Den:
Wietse
> I do not have any of these "receive_override_options=no_header_body_checks"
> in my master.cf or any other places anywhere.
Prove it.
> in my master.cf or any other places anywhere.
Wietse
Den
Sep 11, 2014, 12:01:17 PM9/11/14
to
Hello Wetsie,
That's a piece of cake.
My master.cf in full is below.
Would you like to see my main.cf?
receive_override_options=no_header_body_checks is not actually found in
main.cf as I selectively chose every single line in main.cf myself but I can
copy-paste it for clarity should that help solve it. I am slowly starting to
go crazy about this issue. Many thanks!
#
# 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 - - - - smtpd
smtp inet n - - - 1 postscreen
smtpd pass - - - - - smtpd
dnsblog unix - - - - 0 dnsblog
tlsproxy unix - - - - 0 tlsproxy
submission inet n - - - - smtpd
#Bind the IP to the domian name in outgoing emails.
newcruz-offshore.com unix - - n - - smtp
-o smtp_bind_address=199.175.50.90
-o smtp_helo_name=newcruz-offshore.com
-o syslog_name=postfix-newcruz-offshore.com
# -o content_filter=spamassassin
# -o syslog_name=postfix/submission
# -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 - - - - smtpd
# -o syslog_name=postfix/smtps
# -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 - - - - qmqpd
pickup fifo n - - 60 1 pickup
cleanup unix n - - - 0 cleanup
qmgr fifo n - n 300 1 qmgr
#qmgr fifo n - n 300 1 oqmgr
tlsmgr unix - - - 1000? 1 tlsmgr
rewrite unix - - - - - trivial-rewrite
bounce unix - - - - 0 bounce
defer unix - - - - 0 bounce
trace unix - - - - 0 bounce
verify unix - - - - 1 verify
flush unix n - - 1000? 0 flush
proxymap unix - - n - - proxymap
proxywrite unix - - n - 1 proxymap
smtp unix - - - - - smtp
relay unix - - - - - smtp
# -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
showq unix n - - - - showq
error unix - - - - - error
retry unix - - - - - error
discard unix - - - - - discard
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - - - - lmtp
anvil unix - - - - 1 anvil
scache unix - - - - 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/bin/maildrop -d ${recipient}
dovecot unix - n n - - pipe
flags=DRhu user=mail:mail argv=/usr/lib/dovecot/deliver -f ${sender} -d
${recipient}
dovecot-spamass unix - n n - - pipe
flags=DRhu user=mail:mail argv=/usr/bin/spamc -u ${recipient} -e
/usr/lib/dovecot/deliver -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/lib/bsmtp/bsmtp -t$nexthop -f$sender
$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}
policy-spf unix - n n - - spawn
user=nobody argv=/usr/sbin/postfix-policyd-spf-perl
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70573.html
That's a piece of cake.
My master.cf in full is below.
Would you like to see my main.cf?
receive_override_options=no_header_body_checks is not actually found in
main.cf as I selectively chose every single line in main.cf myself but I can
copy-paste it for clarity should that help solve it. I am slowly starting to
go crazy about this issue. Many thanks!
#
# 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 - - - - smtpd
smtp inet n - - - 1 postscreen
smtpd pass - - - - - smtpd
dnsblog unix - - - - 0 dnsblog
tlsproxy unix - - - - 0 tlsproxy
submission inet n - - - - smtpd
#Bind the IP to the domian name in outgoing emails.
newcruz-offshore.com unix - - n - - smtp
-o smtp_bind_address=199.175.50.90
-o smtp_helo_name=newcruz-offshore.com
-o syslog_name=postfix-newcruz-offshore.com
# -o content_filter=spamassassin
# -o syslog_name=postfix/submission
# -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 - - - - smtpd
# -o syslog_name=postfix/smtps
# -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 - - - - qmqpd
pickup fifo n - - 60 1 pickup
cleanup unix n - - - 0 cleanup
qmgr fifo n - n 300 1 qmgr
#qmgr fifo n - n 300 1 oqmgr
tlsmgr unix - - - 1000? 1 tlsmgr
rewrite unix - - - - - trivial-rewrite
bounce unix - - - - 0 bounce
defer unix - - - - 0 bounce
trace unix - - - - 0 bounce
verify unix - - - - 1 verify
flush unix n - - 1000? 0 flush
proxymap unix - - n - - proxymap
proxywrite unix - - n - 1 proxymap
smtp unix - - - - - smtp
relay unix - - - - - smtp
# -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
showq unix n - - - - showq
error unix - - - - - error
retry unix - - - - - error
discard unix - - - - - discard
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - - - - lmtp
anvil unix - - - - 1 anvil
scache unix - - - - 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/bin/maildrop -d ${recipient}
dovecot unix - n n - - pipe
flags=DRhu user=mail:mail argv=/usr/lib/dovecot/deliver -f ${sender} -d
${recipient}
dovecot-spamass unix - n n - - pipe
flags=DRhu user=mail:mail argv=/usr/bin/spamc -u ${recipient} -e
/usr/lib/dovecot/deliver -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/lib/bsmtp/bsmtp -t$nexthop -f$sender
$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}
policy-spf unix - n n - - spawn
user=nobody argv=/usr/sbin/postfix-policyd-spf-perl
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70573.html
Den
Sep 11, 2014, 12:24:38 PM9/11/14
to
Hello again Wietse,
Here goes my main.cf. There is no
"receive_override_options=no_header_body_checks"
anywhere here as well. Would be absolutely and genuinely thankful for any
suggestions...
# See /usr/share/postfix/main.cf.dist for a commented, more complete version
# Debian specific: Specifying a file name will cause the first
# line of that file to be used as the name. The Debian default
# is /etc/mailname.
myorigin = $mydomain
#myhostname = localhost
myhostname =
mydestination =
virtual_mailbox_domains =
virtual_mailbox_base = /home/mail
virtual_mailbox_maps = hash:/etc/postfix/virtual_boxes
virtual_minimum_uid = 100
virtual_uid_maps = static:1000
virtual_gid_maps = static:1000
virtual_alias_maps = hash:/etc/postfix/virtual_alias_maps
virtual_transport = dovecot-spamass
dovecot-spamass_destination_recipient_limit = 1
biff = no
# appending .domain is the MUA's job.
append_dot_mydomain = no
sender_dependent_default_transport_maps = hash:/etc/postfix/sender_transport
append_at_myorigin = yes
disable_vrfy_command = yes
show_user_unknown_table_name = no
smtpd_error_sleep_time = 20
smtpd_soft_error_limit = 2
smtpd_hard_error_limit = 3
smtpd_junk_command_limit = 2
message_size_limit = 20480000
mailbox_size_limit = 0
local_destination_concurrency_limit = 16
default_destination_concurrency_limit = 20
in_flow_delay = 1s
delay_warning_time = 4h
readme_directory = no
# TLS parameters
smtpd_tls_security_level = may
smtpd_tls_CAfile = /etc/ssl/signed/ca.crt
smtpd_tls_cert_file = /etc/ssl/signed/new.crt
smtpd_tls_key_file = /etc/ssl/signed/new.key
smtpd_tls_loglevel = 1
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_tls_session_cache_timeout = 3600s
smtpd_tls_auth_only = yes
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
broken_sasl_auth_clients = yes
smtpd_sasl_security_options = noanonymous noplaintext
smtpd_sasl_tls_security_options = noanonymous
smtp_sasl_security_options = noanonymous noplaintext
smtp_sasl_tls_security_options = noanonymous
alias_maps = hash:/etc/aliases
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_command = /usr/bin/procmail
home_mailbox = Maildir/
mailbox_size_limit = 0
recipient_delimiter = +
smtpd_recipient_restrictions = reject_non_fqdn_recipient
reject_unknown_recipient_domain permit_sasl_authenticated permit_mynetworks
reject_unauth_destination reject_non_fqdn_hostname reject_invalid_hostname
reject_unauth_pipelining reject_rbl_client zen.spamhaus.org
reject_rbl_client cbl.abuseat.org reject_rbl_client dsn.rfc-ignorant.org
reject_rbl_client dul.dnsbl.sorbs.net reject_rbl_client bl.spamcop.net
reject_rbl_client combined.rbl.msrbl.net reject_rbl_client
b.barracudacentral.org check_policy_service unix:private/policy-spf
check_policy_service inet:127.0.0.1:10023 permit
smtpd_client_restrictions = check_client_access hash:/etc/postfix/blacklist,
reject_unknown_reverse_client_hostname, reject_rbl_client relays.ordb.org,
reject_rbl_client zen.spamhaus.org, reject_rbl_client cbl.abuseat.org,
reject_rbl_client dsn.rfc-ignorant.org, reject_rbl_client
dul.dnsbl.sorbs.net, reject_rbl_client bl.spamcop.net, reject_rbl_client
combined.rbl.msrbl.net, reject_rbl_client b.barracudacentral.org
smtpd_sender_restrictions = reject_unknown_sender_domain,
reject_non_fqdn_sender, reject_rhsbl_sender dsn.rfc-ignorant.org
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname,
check_helo_access hash:/etc/postfix/helo_access
strict_rfc821_envelopes = yes
smtpd_delay_reject = yes
smtpd_data_restrictions = reject_unauth_pipelining
policy-spf_time_limit = 3600s
postscreen_greet_action = enforce
smtp_header_checks = regexp:/etc/postfix/hide
header_checks = regexp:/etc/postfix/filter
smtpd_tls_ciphers = export
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70574.html
Here goes my main.cf. There is no
"receive_override_options=no_header_body_checks"
anywhere here as well. Would be absolutely and genuinely thankful for any
suggestions...
# See /usr/share/postfix/main.cf.dist for a commented, more complete version
# Debian specific: Specifying a file name will cause the first
# line of that file to be used as the name. The Debian default
# is /etc/mailname.
myorigin = $mydomain
#myhostname = localhost
myhostname =
mydestination =
virtual_mailbox_domains =
virtual_mailbox_base = /home/mail
virtual_mailbox_maps = hash:/etc/postfix/virtual_boxes
virtual_minimum_uid = 100
virtual_uid_maps = static:1000
virtual_gid_maps = static:1000
virtual_alias_maps = hash:/etc/postfix/virtual_alias_maps
virtual_transport = dovecot-spamass
dovecot-spamass_destination_recipient_limit = 1
biff = no
# appending .domain is the MUA's job.
append_dot_mydomain = no
sender_dependent_default_transport_maps = hash:/etc/postfix/sender_transport
append_at_myorigin = yes
disable_vrfy_command = yes
show_user_unknown_table_name = no
smtpd_error_sleep_time = 20
smtpd_soft_error_limit = 2
smtpd_hard_error_limit = 3
smtpd_junk_command_limit = 2
message_size_limit = 20480000
mailbox_size_limit = 0
local_destination_concurrency_limit = 16
default_destination_concurrency_limit = 20
in_flow_delay = 1s
delay_warning_time = 4h
readme_directory = no
# TLS parameters
smtpd_tls_security_level = may
smtpd_tls_CAfile = /etc/ssl/signed/ca.crt
smtpd_tls_cert_file = /etc/ssl/signed/new.crt
smtpd_tls_key_file = /etc/ssl/signed/new.key
smtpd_tls_loglevel = 1
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_tls_session_cache_timeout = 3600s
smtpd_tls_auth_only = yes
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
broken_sasl_auth_clients = yes
smtpd_sasl_security_options = noanonymous noplaintext
smtpd_sasl_tls_security_options = noanonymous
smtp_sasl_security_options = noanonymous noplaintext
smtp_sasl_tls_security_options = noanonymous
alias_maps = hash:/etc/aliases
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_command = /usr/bin/procmail
home_mailbox = Maildir/
mailbox_size_limit = 0
recipient_delimiter = +
smtpd_recipient_restrictions = reject_non_fqdn_recipient
reject_unknown_recipient_domain permit_sasl_authenticated permit_mynetworks
reject_unauth_destination reject_non_fqdn_hostname reject_invalid_hostname
reject_unauth_pipelining reject_rbl_client zen.spamhaus.org
reject_rbl_client cbl.abuseat.org reject_rbl_client dsn.rfc-ignorant.org
reject_rbl_client dul.dnsbl.sorbs.net reject_rbl_client bl.spamcop.net
reject_rbl_client combined.rbl.msrbl.net reject_rbl_client
b.barracudacentral.org check_policy_service unix:private/policy-spf
check_policy_service inet:127.0.0.1:10023 permit
smtpd_client_restrictions = check_client_access hash:/etc/postfix/blacklist,
reject_unknown_reverse_client_hostname, reject_rbl_client relays.ordb.org,
reject_rbl_client zen.spamhaus.org, reject_rbl_client cbl.abuseat.org,
reject_rbl_client dsn.rfc-ignorant.org, reject_rbl_client
dul.dnsbl.sorbs.net, reject_rbl_client bl.spamcop.net, reject_rbl_client
combined.rbl.msrbl.net, reject_rbl_client b.barracudacentral.org
smtpd_sender_restrictions = reject_unknown_sender_domain,
reject_non_fqdn_sender, reject_rhsbl_sender dsn.rfc-ignorant.org
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname,
check_helo_access hash:/etc/postfix/helo_access
strict_rfc821_envelopes = yes
smtpd_delay_reject = yes
smtpd_data_restrictions = reject_unauth_pipelining
policy-spf_time_limit = 3600s
postscreen_greet_action = enforce
smtp_header_checks = regexp:/etc/postfix/hide
header_checks = regexp:/etc/postfix/filter
smtpd_tls_ciphers = export
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70574.html
Viktor Dukhovni
Sep 11, 2014, 12:43:03 PM9/11/14
to
On Thu, Sep 11, 2014 at 09:24:38AM -0700, Den wrote:
Do not post main.cf files. Rather, post or attach output of
"postconf -n" that is not line-wrapped after cut/paste, you
need to post it with the original line-breaks preserved.
> # Debian specific: Specifying a file name will cause the first
> # line of that file to be used as the name. The Debian default
> # is /etc/mailname.
> myorigin = $mydomain
> #myhostname = localhost
> myhostname =
This cannot be your active main.cf file, since Postfix enforces a
non-empty setting for myhostname.
... bash used below for sub-process file handles <( ... ) ...
$ touch /tmp/master.cf
$ echo "myhostname =" > /tmp/main.cf
$ postconf -c /tmp -n
config_directory = /tmp
myhostname =
$ postmap -c /tmp -q "foo" pcre:<(echo '/foo/ bar')
postmap: fatal: bad string length 0 < 1: myhostname =
$ echo "myhostname = bogus" > /tmp/main.cf
$ postmap -c /tmp -q "foo" pcre:<(echo '/foo/ bar')
bar
Similar fatal errors would break pretty much everything other than
postconf(1).
--
Viktor.
Do not post main.cf files. Rather, post or attach output of
"postconf -n" that is not line-wrapped after cut/paste, you
need to post it with the original line-breaks preserved.
> # Debian specific: Specifying a file name will cause the first
> # line of that file to be used as the name. The Debian default
> # is /etc/mailname.
> myorigin = $mydomain
> #myhostname = localhost
> myhostname =
non-empty setting for myhostname.
... bash used below for sub-process file handles <( ... ) ...
$ touch /tmp/master.cf
$ echo "myhostname =" > /tmp/main.cf
$ postconf -c /tmp -n
config_directory = /tmp
myhostname =
$ postmap -c /tmp -q "foo" pcre:<(echo '/foo/ bar')
postmap: fatal: bad string length 0 < 1: myhostname =
$ echo "myhostname = bogus" > /tmp/main.cf
$ postmap -c /tmp -q "foo" pcre:<(echo '/foo/ bar')
bar
Similar fatal errors would break pretty much everything other than
postconf(1).
--
Viktor.
Wietse Venema
Sep 11, 2014, 1:02:19 PM9/11/14
to
Den:
As Viktor says, Postfix would never run with empty myhostname.
Send "postconf -n" output instead, preserving line breaks
(or use "postconf -nf" if your Postfix version supports that).
Wietse
> Hello again Wietse,
>
> Here goes my main.cf. There is no
> "receive_override_options=no_header_body_checks"
> anywhere here as well. Would be absolutely and genuinely thankful for any
> suggestions...
>
> # See /usr/share/postfix/main.cf.dist for a commented, more complete version
>
>
> Here goes my main.cf. There is no
> "receive_override_options=no_header_body_checks"
> anywhere here as well. Would be absolutely and genuinely thankful for any
> suggestions...
>
> # See /usr/share/postfix/main.cf.dist for a commented, more complete version
>
> # Debian specific: Specifying a file name will cause the first
> # line of that file to be used as the name. The Debian default
> # is /etc/mailname.
> myorigin = $mydomain
> #myhostname = localhost
> myhostname =
> mydestination =
> # line of that file to be used as the name. The Debian default
> # is /etc/mailname.
> myorigin = $mydomain
> #myhostname = localhost
> myhostname =
As Viktor says, Postfix would never run with empty myhostname.
Send "postconf -n" output instead, preserving line breaks
(or use "postconf -nf" if your Postfix version supports that).
Wietse
Den
Sep 11, 2014, 1:09:08 PM9/11/14
to
Hello Viktor,
Thank you for your message.
It is my functional, active, and fully operational main.cf that has been
working perfectly fine. The only thing removed for privacy / security
reasons was a big list of actual domain names hosted on this server. Not
sure if it is really needed to know these names to troubleshoot the issue.
However, that wasn't the point. The point (Wetse's request) was to prove
that none of my configuration files had
"receive_override_options=no_header_body_checks". I think it has been proved
now. The "override" option is not present anywhere, but header checks do not
discard email messages.
Would you still like me to post postconf -n? Thanks.
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70577.html
Thank you for your message.
It is my functional, active, and fully operational main.cf that has been
working perfectly fine. The only thing removed for privacy / security
reasons was a big list of actual domain names hosted on this server. Not
sure if it is really needed to know these names to troubleshoot the issue.
However, that wasn't the point. The point (Wetse's request) was to prove
that none of my configuration files had
"receive_override_options=no_header_body_checks". I think it has been proved
now. The "override" option is not present anywhere, but header checks do not
discard email messages.
Would you still like me to post postconf -n? Thanks.
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70577.html
Wietse Venema
Sep 11, 2014, 1:14:01 PM9/11/14
to
Den:
anonymize, use example.com, example.net, 10.*.*.* etc. Don't just
silently alter the evidence and waste our time.
Wietse
> Hello Viktor,
>
> Thank you for your message.
>
> It is my functional, active, and fully operational main.cf that has been
> working perfectly fine. The only thing removed for privacy / security
> reasons was a big list of actual domain names hosted on this server. Not
> sure if it is really needed to know these names to troubleshoot the issue.
Sorry, Postfix does not work with empty myhostname. If you must
>
> Thank you for your message.
>
> It is my functional, active, and fully operational main.cf that has been
> working perfectly fine. The only thing removed for privacy / security
> reasons was a big list of actual domain names hosted on this server. Not
> sure if it is really needed to know these names to troubleshoot the issue.
anonymize, use example.com, example.net, 10.*.*.* etc. Don't just
silently alter the evidence and waste our time.
Wietse
Den
Sep 11, 2014, 1:20:06 PM9/11/14
to
Hello Wietse and Viktor,
OK. Let me post the postconf -n with just one domain name I am fine to
disclose. Hope it will help. Thank you so much for your fast replies.
Appreciate your taking part in troubleshooting my problem...
alias_maps = hash:/etc/aliases
append_at_myorigin = yes
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
default_destination_concurrency_limit = 20
delay_warning_time = 4h
disable_vrfy_command = yes
dovecot-spamass_destination_recipient_limit = 1
header_checks = regexp:/etc/postfix/spamdiscard
home_mailbox = Maildir/
in_flow_delay = 1s
local_destination_concurrency_limit = 16
mailbox_command = /usr/bin/procmail
mailbox_size_limit = 0
message_size_limit = 20480000
mydestination =
mydomain = newcruz-offshore.com
myhostname = mail.newcruz-offshore.com
recipient_delimiter = +
sender_dependent_default_transport_maps = hash:/etc/postfix/sender_transport
show_user_unknown_table_name = no
smtp_header_checks = regexp:/etc/postfix/hide
smtpd_delay_reject = yes
smtpd_error_sleep_time = 20
smtpd_hard_error_limit = 3
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_path = private/auth
smtpd_tls_CAfile = /etc/ssl/signed/ca.crt
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/ssl/signed/new.crt
smtpd_tls_ciphers = export
strict_rfc821_envelopes = yes
virtual_alias_maps = hash:/etc/postfix/virtual_alias_maps
virtual_gid_maps = static:1000
virtual_mailbox_base = /home/mail
virtual_mailbox_domains = newcruz-offshore.com
virtual_uid_maps = static:1000
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70579.html
OK. Let me post the postconf -n with just one domain name I am fine to
disclose. Hope it will help. Thank you so much for your fast replies.
Appreciate your taking part in troubleshooting my problem...
alias_maps = hash:/etc/aliases
append_at_myorigin = yes
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
default_destination_concurrency_limit = 20
delay_warning_time = 4h
disable_vrfy_command = yes
dovecot-spamass_destination_recipient_limit = 1
header_checks = regexp:/etc/postfix/spamdiscard
home_mailbox = Maildir/
in_flow_delay = 1s
local_destination_concurrency_limit = 16
mailbox_command = /usr/bin/procmail
mailbox_size_limit = 0
message_size_limit = 20480000
mydestination =
mydomain = newcruz-offshore.com
myhostname = mail.newcruz-offshore.com
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
myorigin = $mydomain
policy-spf_time_limit = 3600s
postscreen_greet_action = enforce
readme_directory = no
postscreen_greet_action = enforce
recipient_delimiter = +
sender_dependent_default_transport_maps = hash:/etc/postfix/sender_transport
show_user_unknown_table_name = no
smtp_header_checks = regexp:/etc/postfix/hide
smtp_sasl_security_options = noanonymous noplaintext
smtp_sasl_tls_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_client_restrictions = check_client_access hash:/etc/postfix/blacklist,
reject_unknown_reverse_client_hostname, reject_rbl_client relays.ordb.org,
reject_rbl_client zen.spamhaus.org, reject_rbl_client cbl.abuseat.org,
reject_rbl_client dsn.rfc-ignorant.org, reject_rbl_client
dul.dnsbl.sorbs.net, reject_rbl_client bl.spamcop.net, reject_rbl_client
combined.rbl.msrbl.net, reject_rbl_client b.barracudacentral.org
smtpd_data_restrictions = reject_unauth_pipelining
reject_unknown_reverse_client_hostname, reject_rbl_client relays.ordb.org,
reject_rbl_client zen.spamhaus.org, reject_rbl_client cbl.abuseat.org,
reject_rbl_client dsn.rfc-ignorant.org, reject_rbl_client
dul.dnsbl.sorbs.net, reject_rbl_client bl.spamcop.net, reject_rbl_client
combined.rbl.msrbl.net, reject_rbl_client b.barracudacentral.org
smtpd_delay_reject = yes
smtpd_error_sleep_time = 20
smtpd_hard_error_limit = 3
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname,
check_helo_access hash:/etc/postfix/helo_access
smtpd_junk_command_limit = 2
smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname,
check_helo_access hash:/etc/postfix/helo_access
smtpd_recipient_restrictions = reject_non_fqdn_recipient
reject_unknown_recipient_domain permit_sasl_authenticated permit_mynetworks
reject_unauth_destination reject_non_fqdn_hostname reject_invalid_hostname
reject_unauth_pipelining reject_rbl_client zen.spamhaus.org
reject_rbl_client cbl.abuseat.org reject_rbl_client dsn.rfc-ignorant.org
reject_rbl_client dul.dnsbl.sorbs.net reject_rbl_client bl.spamcop.net
reject_rbl_client combined.rbl.msrbl.net reject_rbl_client
b.barracudacentral.org check_policy_service unix:private/policy-spf
check_policy_service inet:127.0.0.1:10023 permit
smtpd_sasl_auth_enable = yes
reject_unknown_recipient_domain permit_sasl_authenticated permit_mynetworks
reject_unauth_destination reject_non_fqdn_hostname reject_invalid_hostname
reject_unauth_pipelining reject_rbl_client zen.spamhaus.org
reject_rbl_client cbl.abuseat.org reject_rbl_client dsn.rfc-ignorant.org
reject_rbl_client dul.dnsbl.sorbs.net reject_rbl_client bl.spamcop.net
reject_rbl_client combined.rbl.msrbl.net reject_rbl_client
b.barracudacentral.org check_policy_service unix:private/policy-spf
check_policy_service inet:127.0.0.1:10023 permit
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous noplaintext
smtpd_sasl_tls_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_sasl_tls_security_options = noanonymous
smtpd_sender_restrictions = reject_unknown_sender_domain,
reject_non_fqdn_sender, reject_rhsbl_sender dsn.rfc-ignorant.org
smtpd_soft_error_limit = 2
reject_non_fqdn_sender, reject_rhsbl_sender dsn.rfc-ignorant.org
smtpd_tls_CAfile = /etc/ssl/signed/ca.crt
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/ssl/signed/new.crt
smtpd_tls_ciphers = export
smtpd_tls_key_file = /etc/ssl/signed/new.key
smtpd_tls_loglevel = 1
smtpd_tls_security_level = may
smtpd_tls_loglevel = 1
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_tls_session_cache_timeout = 3600s
strict_rfc821_envelopes = yes
virtual_alias_maps = hash:/etc/postfix/virtual_alias_maps
virtual_gid_maps = static:1000
virtual_mailbox_base = /home/mail
virtual_mailbox_domains = newcruz-offshore.com
virtual_mailbox_maps = hash:/etc/postfix/virtual_boxes
virtual_minimum_uid = 100
virtual_transport = dovecot-spamass
virtual_minimum_uid = 100
virtual_uid_maps = static:1000
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70579.html
Viktor Dukhovni
Sep 11, 2014, 1:37:30 PM9/11/14
to
On Thu, Sep 11, 2014 at 10:20:06AM -0700, Den wrote:
> header_checks = regexp:/etc/postfix/spamdiscard
So this is is the actual setting.
On Thu, Sep 11, 2014 at 09:24:38AM -0700, Den wrote:
> header_checks = regexp:/etc/postfix/filter
And this is not.
On Thu, Sep 11, 2014 at 08:24:40AM -0700, Den wrote:
> They all do work well because testing them via postmap doesn't report any
> issues. For example running the following:
>
> postmap -q "X-Spam-Flag: YES/" regexp:/etc/postfix/filter
And this is the wrong test.
--
Viktor.
> header_checks = regexp:/etc/postfix/spamdiscard
So this is is the actual setting.
On Thu, Sep 11, 2014 at 09:24:38AM -0700, Den wrote:
And this is not.
On Thu, Sep 11, 2014 at 08:24:40AM -0700, Den wrote:
> They all do work well because testing them via postmap doesn't report any
> issues. For example running the following:
>
> postmap -q "X-Spam-Flag: YES/" regexp:/etc/postfix/filter
--
Viktor.
Den
Sep 11, 2014, 1:47:09 PM9/11/14
to
That's right Viktor. Your are absolutely right.
The correct line is header_checks = regexp:/etc/postfix/spamdiscard
and running this: postmap -q "X-Spam-Flag: YES/"
regexp:/etc/postfix/spamdiscard
returns no errors.
The postmap -q "X-Spam-Flag: YES/" regexp:/etc/postfix/filter
is a typo as I was doing it manually while copy-pasting my config for the
first time, I am so sorry about that.
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70581.html
The correct line is header_checks = regexp:/etc/postfix/spamdiscard
and running this: postmap -q "X-Spam-Flag: YES/"
regexp:/etc/postfix/spamdiscard
returns no errors.
The postmap -q "X-Spam-Flag: YES/" regexp:/etc/postfix/filter
is a typo as I was doing it manually while copy-pasting my config for the
first time, I am so sorry about that.
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70581.html
Viktor Dukhovni
Sep 11, 2014, 3:32:44 PM9/11/14
to
On Thu, Sep 11, 2014 at 10:47:09AM -0700, Den wrote:
> That's right Viktor. Your are absolutely right.
>
> The correct line is header_checks = regexp:/etc/postfix/spamdiscard
>
> and running this: postmap -q "X-Spam-Flag: YES/"
> regexp:/etc/postfix/spamdiscard
>
> returns no errors.
>
> The postmap -q "X-Spam-Flag: YES/" regexp:/etc/postfix/filter
>
> is a typo as I was doing it manually while copy-pasting my config for the
> first time, I am so sorry about that.
If you cannot report problems accurately, or expect readers to piece
> That's right Viktor. Your are absolutely right.
>
> The correct line is header_checks = regexp:/etc/postfix/spamdiscard
>
> and running this: postmap -q "X-Spam-Flag: YES/"
> regexp:/etc/postfix/spamdiscard
>
> returns no errors.
>
> The postmap -q "X-Spam-Flag: YES/" regexp:/etc/postfix/filter
>
> is a typo as I was doing it manually while copy-pasting my config for the
> first time, I am so sorry about that.
together fragments of separate messages, I'm afraid I can't help you.
Header checks work when correctly specified.
--
Viktor.
Den
Sep 11, 2014, 5:04:30 PM9/11/14
to
Hello Viktor,
Thank you for your comment.
I just thought that my last message had been somehow misinterpreted. I said
there was a little typo while I posted it here. But that was just a bad
wording. In fact, it wasn't even a typo, it was just an example /in general/
that I called a filter. Then my main.cf had a real name used, not the
abstract example.
If Mr. Dukhovni can't help that's absolutely fine with me. I didn't ask you
personally. I asked the community. Perhaps there might be others who would
have more experience and would be able to assist.
Now, despite the fact that my main.cf has no "typos" and regexps in my
header checks are correct and have no issues as per tests run, the messages
are still not being discarded.
I have a feeling that my subject line is a problem because much simpler
header checks that contain only two or three simple dictionary words work
just fine. Therefore I was also wondering if anyone who runs reject,
discard, and redirect rules in their header checks could possibly do me a
big favor and run a very simple test, please. It would be real kind of you
if you could put the following into your subject field:
XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X
then email it to yourself and advise back. I am really curious to know if
this is going to be discarded, rejected or redirected in accordance with how
your rules go. Many thanks in advance!
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70592.html
Thank you for your comment.
I just thought that my last message had been somehow misinterpreted. I said
there was a little typo while I posted it here. But that was just a bad
wording. In fact, it wasn't even a typo, it was just an example /in general/
that I called a filter. Then my main.cf had a real name used, not the
abstract example.
If Mr. Dukhovni can't help that's absolutely fine with me. I didn't ask you
personally. I asked the community. Perhaps there might be others who would
have more experience and would be able to assist.
Now, despite the fact that my main.cf has no "typos" and regexps in my
header checks are correct and have no issues as per tests run, the messages
are still not being discarded.
I have a feeling that my subject line is a problem because much simpler
header checks that contain only two or three simple dictionary words work
just fine. Therefore I was also wondering if anyone who runs reject,
discard, and redirect rules in their header checks could possibly do me a
big favor and run a very simple test, please. It would be real kind of you
if you could put the following into your subject field:
XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X
then email it to yourself and advise back. I am really curious to know if
this is going to be discarded, rejected or redirected in accordance with how
your rules go. Many thanks in advance!
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70592.html
Wietse Venema
Sep 11, 2014, 5:20:20 PM9/11/14
to
Den:
software then that is your problem.
$ hexdump -c the-regexp-file
And look for anything in that you did not mean to have in there.
What you should see is printable characters and an occasional
space, \t or \n.
Wietse
> I have a feeling that my subject line is a problem because much simpler
> header checks that contain only two or three simple dictionary words work
> just fine. Therefore I was also wondering if anyone who runs reject,
What text editor are you using? If it is any kind of word processor
> header checks that contain only two or three simple dictionary words work
> just fine. Therefore I was also wondering if anyone who runs reject,
software then that is your problem.
$ hexdump -c the-regexp-file
And look for anything in that you did not mean to have in there.
What you should see is printable characters and an occasional
space, \t or \n.
Wietse
Viktor Dukhovni
Sep 11, 2014, 5:50:04 PM9/11/14
to
On Thu, Sep 11, 2014 at 02:04:30PM -0700, Den wrote:
> if you could put the following into your subject field:
>
> XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X
Depending on your locale and MUA, subjects are sometimes encoded
> if you could put the following into your subject field:
>
> XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X
using either Quoted Printable or Base64 encoding. What you see
on the screen may differ from the subject header on the wire.
Header checks is a crude mechanism, that only deals with raw
wire-form data.
--
Viktor.
Wietse Venema
Sep 11, 2014, 5:58:40 PM9/11/14
to
Viktor Dukhovni:
You can expose the on-the-wire form with a header_checks rule:
/^Subject:/ WARN
That will log each header.
Wietse
/^Subject:/ WARN
That will log each header.
Wietse
Den
Sep 11, 2014, 6:04:47 PM9/11/14
to
I am replying through a gadget / portable device now so my apologies if it doesn't meet your gateway's etiquette requirements.
I am using a simple notepad as I don't like all these fansy word processors and all but hey! thank you so much for the idea, Wietse! I'll run more tests to see how it works when simplified to the very minimum then will start building on top of that, making it more complex step by step...
Regards,
Dennis.
_______________________________________________
If you reply to this email, your message will be added to the discussion below:
http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70593.html
To unsubscribe from header checks not working, visit http://postfix.1071664.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=36845&code=dGRsQGJhbHRpY3VtLXR2Lmx0fDM2ODQ1fDEzNjk3OTYyNDg=
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70599.html
I am using a simple notepad as I don't like all these fansy word processors and all but hey! thank you so much for the idea, Wietse! I'll run more tests to see how it works when simplified to the very minimum then will start building on top of that, making it more complex step by step...
Regards,
Dennis.
If you reply to this email, your message will be added to the discussion below:
http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70593.html
To unsubscribe from header checks not working, visit http://postfix.1071664.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=36845&code=dGRsQGJhbHRpY3VtLXR2Lmx0fDM2ODQ1fDEzNjk3OTYyNDg=
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70599.html
Michael J Wise
Sep 11, 2014, 6:51:36 PM9/11/14
to
> It would be real kind of you
> if you could put the following into your subject field:
If you are going to refer to the GTUBE, best to just cite it by NAME, or
include an URL like:
http://spamassassin.apache.org/gtube/
Actually including it in a message is ... unwise.
Why is left as an exercise. :)
Aloha mai Nai`a.
--
" So this is how Liberty dies ... http://kapu.net/~mjwise/
" To Thunderous Applause.
Den
Sep 12, 2014, 1:13:03 AM9/12/14
to
Right, Michael.
Thank you for bringing this up and I really do appreciate your feedback.
I'll try to test this string with all the headers, not just my subject
field. Not sure it may get me somewhere though.
However, I think no matter what I put in my subject field or in the body
field the header
X-Spam-Flag: YES
is added when the spam is tagged. Then based on that header and the
following rule
/^X-Spam-Flag: YES/ discard
this message has to be discarded, right? In my case it's wrong and the
trouble is that it is not discarded, it gets delivered.
Additionally, there is another "bullet proof" rule on top
/^Subject:.*\*{5}SPAM\*{5}/ discard
that is also used. The subject is appended correctly and the word
*****SPAM***** is added. Then having this rule in action the message has to
be discarded as well but... it gets delivered. These two rules never stop
the string in question.
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70603.html
Thank you for bringing this up and I really do appreciate your feedback.
I'll try to test this string with all the headers, not just my subject
field. Not sure it may get me somewhere though.
However, I think no matter what I put in my subject field or in the body
field the header
X-Spam-Flag: YES
is added when the spam is tagged. Then based on that header and the
following rule
/^X-Spam-Flag: YES/ discard
this message has to be discarded, right? In my case it's wrong and the
trouble is that it is not discarded, it gets delivered.
Additionally, there is another "bullet proof" rule on top
/^Subject:.*\*{5}SPAM\*{5}/ discard
that is also used. The subject is appended correctly and the word
*****SPAM***** is added. Then having this rule in action the message has to
be discarded as well but... it gets delivered. These two rules never stop
the string in question.
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70603.html
Den
Sep 12, 2014, 1:32:40 AM9/12/14
to
Viktor:
but Quoted Printable and Base64 might be there I guess. Is it by any chances
email clients dependent somehow? The string in the subject field gets
converted to Quoted Printable by default in Microsoft's Outlook for example
and then it's not "parsed" correctly by the header rules in Postfix? This is
highly and exceptionally unlikely in my humble opinion but...
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70605.html
>Depending on your locale and MUA, subjects are sometimes encoded
>using either Quoted Printable or Base64 encoding. What you see
>on the screen may differ from the subject header on the wire.
>Header checks is a crude mechanism, that only deals with raw
>wire-form data.
Good point. All my locale and MUA are all English from head to toe all over,
>using either Quoted Printable or Base64 encoding. What you see
>on the screen may differ from the subject header on the wire.
>Header checks is a crude mechanism, that only deals with raw
>wire-form data.
but Quoted Printable and Base64 might be there I guess. Is it by any chances
email clients dependent somehow? The string in the subject field gets
converted to Quoted Printable by default in Microsoft's Outlook for example
and then it's not "parsed" correctly by the header rules in Postfix? This is
highly and exceptionally unlikely in my humble opinion but...
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70605.html
Den
Sep 12, 2014, 3:21:58 AM9/12/14
to
Hello there again Michael,
I think you "nailed" my issue.
Let me quote a little from documentation of GTUBE for clearance. It stands
for Generic Test for Unsolicited Bulk Email. /quote,/ "It's been agreed upon
a single string of characters that should always set off any spam detectors.
The GTUBE will be rejected as spam... Your spam-filter manufacturer may not
support this handy spam-testing tool, but if it doesn't please, call it and
tell it that it needs to." /unquote/
There is a test email to be sent to check it. It is provided in your posted
link here http://spamassassin.apache.org/gtube/
Now I have sent the test email and the spam detector did not go off (didn't
work)... Could anybody advise please, where do I head from this point and
where to look to have it fixed? Is this GTUBE not supported by postfix
filters and may that be the reason for my other messages not being rejected
via header checks in postfix? Would highly appreciate any further guidance
from any postfix experts out there. Many thanks in advance!
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70610.html
I think you "nailed" my issue.
Let me quote a little from documentation of GTUBE for clearance. It stands
for Generic Test for Unsolicited Bulk Email. /quote,/ "It's been agreed upon
a single string of characters that should always set off any spam detectors.
The GTUBE will be rejected as spam... Your spam-filter manufacturer may not
support this handy spam-testing tool, but if it doesn't please, call it and
tell it that it needs to." /unquote/
There is a test email to be sent to check it. It is provided in your posted
link here http://spamassassin.apache.org/gtube/
Now I have sent the test email and the spam detector did not go off (didn't
work)... Could anybody advise please, where do I head from this point and
where to look to have it fixed? Is this GTUBE not supported by postfix
filters and may that be the reason for my other messages not being rejected
via header checks in postfix? Would highly appreciate any further guidance
from any postfix experts out there. Many thanks in advance!
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70610.html
li...@rhsoft.net
Sep 12, 2014, 3:35:50 AM9/12/14
to
Am 12.09.2014 um 09:21 schrieb Den:
> Hello there again Michael,
>
> I think you "nailed" my issue.
>
> Let me quote a little from documentation of GTUBE for clearance. It stands
> for Generic Test for Unsolicited Bulk Email. /quote,/ "It's been agreed upon
> a single string of characters that should always set off any spam detectors.
> The GTUBE will be rejected as spam... Your spam-filter manufacturer may not
> support this handy spam-testing tool, but if it doesn't please, call it and
> tell it that it needs to." /unquote/
>
> There is a test email to be sent to check it. It is provided in your posted
> link here http://spamassassin.apache.org/gtube/
>
> Now I have sent the test email and the spam detector did not go off (didn't
> work)... Could anybody advise please, where do I head from this point and
> where to look to have it fixed? Is this GTUBE not supported by postfix
> filters and may that be the reason for my other messages not being rejected
> via header checks in postfix? Would highly appreciate any further guidance
> from any postfix experts out there. Many thanks in advance!
"GTUBE not supported by postfix filters" makes no sense without naming the filter
spamassassin supports the GTUBE and if you run it as milter it
REJECTS the message instead *silently drop it* with header_checks
later - the milter reacts on the same header but the difference
is that the delivering client is still connected and get a
reject after end-of-data
don't do that - depending on the country and context you could
go to jail for such a setup and it is unacceptable in general
if i send someone a mail he hes to receive that or the server
has to REJECT it so that mine writes me the bounce - REJECT it
due SMTP session with the delivering server and *not* accept
and bounce a backscatter
Den
Sep 12, 2014, 4:13:43 AM9/12/14
to
>in context of "the spam detector" you need to name it
>"GTUBE not supported by postfix filters" makes no sense without naming the
filter
Right. It's spamassassin. Thanks.
>"GTUBE not supported by postfix filters" makes no sense without naming the
filter
>don't do that - depending on...
I am not sure I follow. Don't do what? I am saying here that my header
checks do not work and all the spam is coming in right through without ever
being rejected, discarded and so on. I am safe in terms of jail :-) because
again it doesn't work.
Plus, it sounds a little weird to me that any "country and context" may
charge you with a crime for just discarding an email. This is my private
property and I may charge them back for trespassing for example, which is
much more serious then discarding an email. There are countries with rules
where you first have to receive prior written consent form the receivers
before sending them any commercials, ads and so on but this is never charged
criminally, they only administratively charge you (fine that is) if you do
not follow these rules and only IF it is proved. Every person in the world
in considered innocent unless PROVEN otherwise. But never mind as these are
just my comments spoken out loud, plus it has nothing to do with Postfix and
this is not a law forum :-)
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70616.html
li...@rhsoft.net
Sep 12, 2014, 4:24:38 AM9/12/14
to
Am 12.09.2014 um 10:13 schrieb Den:
>> in context of "the spam detector" you need to name it
>> "GTUBE not supported by postfix filters" makes no sense without naming the
> filter
>
> Right. It's spamassassin. Thanks.
>
>> don't do that - depending on...
>
> I am not sure I follow. Don't do what?
http://www.postfix.org/MILTER_README.html
> I am saying here that my header checks do not work
> and all the spam is coming in right through without ever
> being rejected, discarded and so on. I am safe in terms
> of jail :-) because again it doesn't work.
because the message is rejected before it ever touchs header_checks
/usr/sbin/spamass-milter -p /run/spamass-milter/spamass-milter.sock -g sa-milt -r 8.0 -- -s 3145728.0 --port=10027
that above is a correct setup and any message above score 8 is rejected
Sep 12 10:08:42 mail-gw postfix/smtpd[31570]: 3hvV3G6KHqz20: client=smtpoazh.emms.com[62.146.111.108]
Sep 12 10:08:42 mail-gw postfix/cleanup[1956]: 3hvV3G6KHqz20:
message-id=<63546113299366...@emailsocket.dc.lan>
Sep 12 10:08:44 mail-gw postfix/cleanup[1956]: 3hvV3G6KHqz20: milter-reject: END-OF-MESSAGE from
smtpoazh.emms.com[62.146.111.108]: 5.7.1 Blocked by SpamAssassin; from=<bounc...@flug-jetzt.com> to=<***>
proto=ESMTP helo=<smtpoazh.emms.com>
> Plus, it sounds a little weird to me that any "country and context"
> may charge you with a crime for just discarding an email
silently drop it in germany you hit the same law than a postman standing in
front of your house saying "oh no, i just put that letter in the basket"
just because the sender can proofe that your server accepted the message
but the RCPT never saw it and in case it was a false positive but important
business mail leading to lose money for whatever reason you are guilty
Den
Sep 12, 2014, 4:32:23 AM9/12/14
to
Wietse:
practice? Looks like it works successively and any rule that goes after
/^Subject:/ WARN gets to be "warned" and ignored. Many thanks!
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70620.html
>You can expose the on-the-wire form with a header_checks rule:
>
> /^Subject:/ WARN
>
>That will log each header.
>
> Wietse
>
Could you please, elaborate a little further how to put it to work in
>
> /^Subject:/ WARN
>
>That will log each header.
>
> Wietse
>
practice? Looks like it works successively and any rule that goes after
/^Subject:/ WARN gets to be "warned" and ignored. Many thanks!
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70620.html
Den
Sep 12, 2014, 5:29:02 AM9/12/14
to
Thanks. Will double-check on that. Chances also are that I missed something
too or I might as well have to try to switch to these milters as running SA
daemonized doesn't work. I posted my main.cf and my master.cf a bit earlier
in this post if you are interested to take a look.
>if you run SA as milter header_checks are mot involved at all because the
message is rejected before it >ever touchs header_checks
I do not run SA as milter, I run it demonized and my rules do not work
despite the fact that they pass the tests like these (/example/):
postmap -q "Subject: Viagra/" regexp:/etc/postfix/spamdiscard
DISCARD *Spam*
rule (/example)/ is /^Subject: Viagra/ discard *Spam*
>if you are the mailadmin for other users and accept a message with "250 OK"
but
>silently drop it in germany you hit the same law than a postman standing in
>front of your house saying "oh no, i just put that letter in the basket"
That's an interesting concept. I would say that 250 OK does not really
confirm reception. Even if you request delivery receipt / read receipt does
not necessarily confirm that a receiver actually read and understood what
was written in that email. Any good lawyer will prove it literally in
seconds and also prove that a person accused is not guilty. This is a sieve
law in my opinion but I will not argue / dispute on it. You have it this way
in Germany and it's not for me to criticize. If your government considers it
right so it is. There are many laws that have "holes" in them to be used to
a culprit's / defendant's advantage. I think this is a very clear example.
>just because the sender can proofe that your server accepted the message
>but the RCPT never saw it and in case it was a false positive but important
>business mail leading to lose money for whatever reason you are guilty
The server is not a person. The server may have accepted the message but the
person may have never even seen it. The server (machine) cannot be
substituted for a person. A mail man standing in front of your door receives
a receipt signature from a /live/ person in person and live so to speak.
This is the only evidence accepted. I think that if a delivery receipt was
received from a robot (server), not a live person, it would NOT hold enough
testimony that a live person was involved at all. It would definitely not be
the case in our country and by no means would ever be regarded as the only
truth averment.
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70628.html
too or I might as well have to try to switch to these milters as running SA
daemonized doesn't work. I posted my main.cf and my master.cf a bit earlier
in this post if you are interested to take a look.
>if you run SA as milter header_checks are mot involved at all because the
message is rejected before it >ever touchs header_checks
despite the fact that they pass the tests like these (/example/):
postmap -q "Subject: Viagra/" regexp:/etc/postfix/spamdiscard
DISCARD *Spam*
rule (/example)/ is /^Subject: Viagra/ discard *Spam*
>if you are the mailadmin for other users and accept a message with "250 OK"
but
>silently drop it in germany you hit the same law than a postman standing in
>front of your house saying "oh no, i just put that letter in the basket"
confirm reception. Even if you request delivery receipt / read receipt does
not necessarily confirm that a receiver actually read and understood what
was written in that email. Any good lawyer will prove it literally in
seconds and also prove that a person accused is not guilty. This is a sieve
law in my opinion but I will not argue / dispute on it. You have it this way
in Germany and it's not for me to criticize. If your government considers it
right so it is. There are many laws that have "holes" in them to be used to
a culprit's / defendant's advantage. I think this is a very clear example.
>just because the sender can proofe that your server accepted the message
>but the RCPT never saw it and in case it was a false positive but important
>business mail leading to lose money for whatever reason you are guilty
person may have never even seen it. The server (machine) cannot be
substituted for a person. A mail man standing in front of your door receives
a receipt signature from a /live/ person in person and live so to speak.
This is the only evidence accepted. I think that if a delivery receipt was
received from a robot (server), not a live person, it would NOT hold enough
testimony that a live person was involved at all. It would definitely not be
the case in our country and by no means would ever be regarded as the only
truth averment.
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70628.html
li...@rhsoft.net
Sep 12, 2014, 5:38:50 AM9/12/14
to
Am 12.09.2014 um 11:29 schrieb Den:
>> run the spamfilter after queue
>> http://www.postfix.org/MILTER_README.html
>
> Thanks. Will double-check on that. Chances also are that I missed something
> too or I might as well have to try to switch to these milters as running SA
> daemonized doesn't work. I posted my main.cf and my master.cf a bit earlier
> in this post if you are interested to take a look.
>
>> if you run SA as milter header_checks are mot involved at all because the
> message is rejected before it >ever touchs header_checks
>
> I do not run SA as milter, I run it demonized and my rules do not work
> despite the fact that they pass the tests like these (/example/):
* spamd running as daemon and listening on TCP
* spamass-milter running as deamon and listening on a unix socket
* postfix talks to spamass-milter via the socket
* spamass-milter takls to spamd via TCP
* spamd has prefroking childs for the scanning
* finally the milter parses the headers of SA
* if the score header is above the limit it rejects the message
well, it needs some work to setup SA correctly but that's part
of the job running a mailserver - running a public MTA brings
a lot of responsibility because you can do much damage with it
sa-milt 2045 0.0 0.1 586372 5976 ? SNsl Sep11 0:11 /usr/sbin/spamass-milter -p
/run/spamass-milter/spamass-milter.sock -g sa-milt -r 8.0 -- -s 3145728.0 --port=10027
sa-milt 6802 3.6 3.5 358320 144056 ? SN 11:14 0:39 spamd child
sa-milt 17179 0.0 1.7 283784 72312 ? SNs 04:16 0:06 /usr/bin/perl -T -w /usr/bin/spamd -c -H
--max-children=25 --min-children=10 --min-spare=5 --max-spare=15 --port=10027
sa-milt 17206 0.0 3.1 339920 126196 ? SN 04:16 0:18 spamd child
sa-milt 17207 0.0 1.9 292720 80540 ? SN 04:16 0:00 spamd child
sa-milt 17209 0.0 1.9 292788 80608 ? SN 04:16 0:00 spamd child
sa-milt 17210 0.0 1.6 283784 67080 ? SN 04:16 0:00 spamd child
sa-milt 17211 0.0 1.6 283784 67144 ? SN 04:16 0:00 spamd child
sa-milt 17212 0.0 1.6 283784 67084 ? SN 04:16 0:00 spamd child
sa-milt 17213 0.0 1.6 283784 67148 ? SN 04:16 0:00 spamd child
sa-milt 17214 0.0 1.6 283784 67212 ? SN 04:16 0:00 spamd child
sa-milt 17215 0.0 1.6 283784 67084 ? SN 04:16 0:00 spamd child
sa-milt 17216 0.0 1.6 283784 67084 ? SN 04:16 0:00 spamd child
sa-milt 17217 0.0 1.6 283784 67152 ? SN 04:16 0:00 spamd child
sa-milt 17218 0.0 1.6 283784 67088 ? SN 04:16 0:00 spamd child
sa-milt 28262 0.0 1.6 283784 66996 ? SN 08:03 0:00 spamd child
sa-milt 32364 0.0 1.6 283784 66828 ? SN 09:12 0:00 spamd child
>> if you are the mailadmin for other users and accept a message
>> with "250 OK" but silently drop it in germany you hit the same
>> law than a postman standing in
>> front of your house saying "oh no, i just put that letter in the basket"
>
> That's an interesting concept. I would say that 250 OK does not really
> confirm reception. Even if you request delivery receipt / read receipt does
> not necessarily confirm that a receiver actually read and understood what
> was written in that email. Any good lawyer will prove it literally in
> seconds and also prove that a person accused is not guilty
the is a large difference between "one do not read or understand a mail"
or "the server admin confirmed that he received the mail but dropped it
silently and so it never made it to the inbox"
if you are doing that no lawyer can help you because you have to know
the legal side how to deal with a service you sell for customers and
frankly everybody in germany knows that such a wrong setup is forbidden
Den
Sep 12, 2014, 6:44:52 AM9/12/14
to
>you have 3 processes as part of the game:
>
>* spamd running as daemon and listening on TCP
>* spamass-milter running as deamon and listening on a unix socket
>* postfix talks to spamass-milter via the socket
>* spamass-milter takls to spamd via TCP
>* spamd has prefroking childs for the scanning
>* finally the milter parses the headers of SA
>* if the score header is above the limit it rejects the message
Simple rules on simple words work OK without any milters installed and
>
>* spamd running as daemon and listening on TCP
>* spamass-milter running as deamon and listening on a unix socket
>* postfix talks to spamass-milter via the socket
>* spamass-milter takls to spamd via TCP
>* spamd has prefroking childs for the scanning
>* finally the milter parses the headers of SA
>* if the score header is above the limit it rejects the message
running. So I guess my problem is not in installing something additionally
on top. There is something fishy and somewhere else going on.
As I said earlier the one below works just fine.
/^Subject: Viagra/ discard
There are other rules that do not work.
For example this one
/^Subject:.*\*{5}SPAM\*{5}/DISCARD *SPAM*
lets absolutely anything in without ever stopping it, despite the fact that
tests run on this rule return no errors at all.
>no you don't understand the point
no live person involved in doing something you cannot really say that this
person is guilty in doing that something. He wasn't involved. He simply
wasn't there. There was only a machine taking part (sever in your case).
>the is a large difference between "one do not read or understand a mail"
>or "the server admin confirmed that he received the mail but dropped it
>silently and so it never made it to the inbox"
for example, "thank you, your message is well-received and I will personally
make sure the addressee will read it and then puts his name, last name,
date, and possibly his signature beneath? I guess not :-) Therefore I
thought that there were only machines taking part in these, not live people
doing live responses as illustrated a bit above :-)
>if you are doing that no lawyer can help you because you have to know
>the legal side how to deal with a service you sell for customers and
>frankly everybody in germany knows that such a wrong setup is forbidden
everywhere. Plus, again most probably your know it better since perhaps you
are in this business so I'll let you live and cope with it. It's not a
concern of mine in any way. I simply expressed my personal view because it
did not sound logical to me.
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70634.html
Wietse Venema
Sep 12, 2014, 7:23:21 AM9/12/14
to
Den:
postfix/cleanup[2632]: warning: regexp map /etc/postfix/header_checks, line 1: unknown regexp option "D": skipping this rule
Wietse
> /^Subject:.*\*{5}SPAM\*{5}/DISCARD *SPAM*
PLease look for warnings like the following in your maillog file:
postfix/cleanup[2632]: warning: regexp map /etc/postfix/header_checks, line 1: unknown regexp option "D": skipping this rule
Wietse
Den
Sep 12, 2014, 8:23:33 AM9/12/14
to
Wietse:
options. However, doing it like this:
/^Subject:.*\*{5}SPAM\*{5}/ DISCARD *SPAM*
/^X-Spam-Flag: YES/ DISCARD Spam Flag
/^Subject:(.*)SPAM/ DISCARD 8
/^Subject: make money fast/ REJECT No more hullababallos, please.
/^Subject:/ WARN
disables all the rules that go /before/ WARN. Does it work successively as
PHP does? Then my best bet is to separate the troubled one like this:
/^Subject:.*\*{5}SPAM\*{5}/ DISCARD *SPAM*
/^Subject:/ WARN
that is without having anything before discard*spam*. Is that correct?
I also begin to think that there is a regexp issue somewhere. Is it actually
possible for different Linux distros to treat regexpes differently requiring
regexpes to be different as well?
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70638.html
> /^Subject:.*\*{5}SPAM\*{5}/DISCARD *SPAM*
>
>Please look for warnings like the following in your maillog file:
>
>
>postfix/cleanup[2632]: warning: regexp map /etc/postfix/header_checks, line
1: unknown regexp >option "D": skipping this rule
>
> Wietse
Thank you. I will try it and go on with testing it around with different
>postfix/cleanup[2632]: warning: regexp map /etc/postfix/header_checks, line
1: unknown regexp >option "D": skipping this rule
>
> Wietse
options. However, doing it like this:
/^Subject:.*\*{5}SPAM\*{5}/ DISCARD *SPAM*
/^Subject:(.*)SPAM/ DISCARD 8
/^Subject: make money fast/ REJECT No more hullababallos, please.
/^Subject:/ WARN
disables all the rules that go /before/ WARN. Does it work successively as
PHP does? Then my best bet is to separate the troubled one like this:
/^Subject:.*\*{5}SPAM\*{5}/ DISCARD *SPAM*
that is without having anything before discard*spam*. Is that correct?
I also begin to think that there is a regexp issue somewhere. Is it actually
possible for different Linux distros to treat regexpes differently requiring
regexpes to be different as well?
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70638.html
li...@rhsoft.net
Sep 12, 2014, 8:34:08 AM9/12/14
to
Am 12.09.2014 um 14:23 schrieb Den:
> /^Subject:.*\*{5}SPAM\*{5}/ DISCARD *SPAM*
> /^Subject:/ WARN
>
> that is without having anything before discard*spam*. Is that correct?
>
> I also begin to think that there is a regexp issue somewhere. Is it actually
> possible for different Linux distros to treat regexpes differently requiring
> regexpes to be different as well?
* the subject starts with [SPAM] so no need for .*
* {5} - what is that supposed to do?
* avoid a * in the action for safety
/^Subject: \[SPAM.*/ DISCARD SPAM
Wietse Venema
Sep 12, 2014, 8:43:25 AM9/12/14
to
Den:
i.e. each query stops at the first matching rule.
Postfix also works as documented in header_checks(5), i.e. DISCARD
causes Postfix to ignore the remainder of the message.
> Then my best bet is to separate the troubled one like this:
>
API which is controlled by an international standardization group.
Wietse
> Does it work successively as PHP does?
Postfix works as documented in regexp_table(5) and pcre_table(5),
i.e. each query stops at the first matching rule.
Postfix also works as documented in header_checks(5), i.e. DISCARD
causes Postfix to ignore the remainder of the message.
> Then my best bet is to separate the troubled one like this:
>
> /^Subject:.*\*{5}SPAM\*{5}/ DISCARD *SPAM*
> /^Subject:/ WARN
>
> that is without having anything before discard*spam*. Is that correct?
That would show the subjects that don't match patterns before /^Subject:/.
> /^Subject:/ WARN
>
> that is without having anything before discard*spam*. Is that correct?
>
> I also begin to think that there is a regexp issue somewhere. Is
> it actually possible for different Linux distros to treat regexpes
> differently requiring regexpes to be different as well?
Unlikely. Linux, as many other systems, implements the POSIX regexp
> I also begin to think that there is a regexp issue somewhere. Is
> it actually possible for different Linux distros to treat regexpes
> differently requiring regexpes to be different as well?
API which is controlled by an international standardization group.
Wietse
Den
Sep 12, 2014, 8:53:06 AM9/12/14
to
>"li...@rhsoft.net"
1. postmap -q "/^Subject:.*\*{5}SPAM\*{5}/" regexp:/etc/postfix/spamdiscard
returns no issues
2. {5} substitutes the \*\*\*\*\* because I have 5 ***** in front and after
the word SPAM, not 5 [[[[[
3. The dot with the wildcard or asterisk .* match any number or any
character that goes in front, like your mentioned [, my *, or + and so on.
Thus I do not have to explicitly mention each character separately including
[ * + and so on.
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70643.html
>no but the regexp is entirely wrong
>
>
> the subject starts with [SPAM] so no need for .*
>{5} - what is that supposed to do?
>avoid a * in the action for safety
>
>/^Subject: \[SPAM.*/ DISCARD SPAM
Strongly disagree. Regexp is 100% correct because:
>
>/^Subject: \[SPAM.*/ DISCARD SPAM
1. postmap -q "/^Subject:.*\*{5}SPAM\*{5}/" regexp:/etc/postfix/spamdiscard
returns no issues
2. {5} substitutes the \*\*\*\*\* because I have 5 ***** in front and after
the word SPAM, not 5 [[[[[
3. The dot with the wildcard or asterisk .* match any number or any
character that goes in front, like your mentioned [, my *, or + and so on.
Thus I do not have to explicitly mention each character separately including
[ * + and so on.
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70643.html
li...@rhsoft.net
Sep 12, 2014, 8:58:43 AM9/12/14
to
Am 12.09.2014 um 14:53 schrieb Den:
>> "li...@rhsoft.net"
>> no but the regexp is entirely wrong
>>
>> the subject starts with [SPAM] so no need for .*
>> {5} - what is that supposed to do?
>> avoid a * in the action for safety
>>
>> /^Subject: \[SPAM.*/ DISCARD SPAM
>
> Strongly disagree. Regexp is 100% correct because:
>
> 1. postmap -q "/^Subject:.*\*{5}SPAM\*{5}/" regexp:/etc/postfix/spamdiscard
> returns no issues
> 2. {5} substitutes the \*\*\*\*\* because I have 5 ***** in front and after
> the word SPAM, not 5 [[[[[
>
> 3. The dot with the wildcard or asterisk .* match any number or any
> character that goes in front, like your mentioned [, my *, or + and so on.
> Thus I do not have to explicitly mention each character separately including
> [ * + and so on
rewrite_header Subject [SPAM]
why don't you just stick with defaults and after all is working
change each time only one setting so that you in case of breakage
know which change is responsible
that's best practice for many years in server context
header_checks works - period
Den
Sep 12, 2014, 10:42:16 AM9/12/14
to
>quote author="li...@rhsoft.net"
Postfix version 2.9.6. My SA 3.3.2 (2011-06-06) default says rewrite_header
Subject *****SPAM***** and I do stick to its defaults.
On the other hand there is nothing out there that could possibly stop me
from giving your options a shoot and try them out. Will literally take just
a minute.
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70657.html
>
>SA default is
>rewrite_header Subject [SPAM]
>
>why don't you just stick with defaults and after all...
>SA default is
>rewrite_header Subject [SPAM]
>
Postfix version 2.9.6. My SA 3.3.2 (2011-06-06) default says rewrite_header
Subject *****SPAM***** and I do stick to its defaults.
On the other hand there is nothing out there that could possibly stop me
from giving your options a shoot and try them out. Will literally take just
a minute.
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70657.html
Den
Sep 13, 2014, 1:12:38 AM9/13/14
to
Hello there Postfix experts!
I was just wondering what exactly does the line below do? Could anybody
comment / advise, please? It does not actually check and *confirm* that the
code, syntax, etc. of any regexp present in /filter/ (example) is 100%
correct does it?
postmap -q "/^Subject:.*\*{5}SPAM\*{5}/" regexp:/etc/postfix//filter/
Many thanks!
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70666.html
I was just wondering what exactly does the line below do? Could anybody
comment / advise, please? It does not actually check and *confirm* that the
code, syntax, etc. of any regexp present in /filter/ (example) is 100%
correct does it?
postmap -q "/^Subject:.*\*{5}SPAM\*{5}/" regexp:/etc/postfix//filter/
Many thanks!
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70666.html
Viktor Dukhovni
Sep 13, 2014, 2:21:10 AM9/13/14
to
On Fri, Sep 12, 2014 at 10:12:38PM -0700, Den wrote:
> I was just wondering what exactly does the line below do? Could anybody
> comment / advise, please? It does not actually check and *confirm* that the
> code, syntax, etc. of any regexp present in /filter/ (example) is 100%
> correct does it?
>
> postmap -q "/^Subject:.*\*{5}SPAM\*{5}/" regexp:/etc/postfix//filter/
It means you're too tired to think straight. :-(
> I was just wondering what exactly does the line below do? Could anybody
> comment / advise, please? It does not actually check and *confirm* that the
> code, syntax, etc. of any regexp present in /filter/ (example) is 100%
> correct does it?
>
> postmap -q "/^Subject:.*\*{5}SPAM\*{5}/" regexp:/etc/postfix//filter/
* You're using a regexp pattern instead of an input string to match.
* Your regexp table is a directory, and is not what's in main.cf.
A sensible version of this is:
$ exec bash
$ /usr/sbin/postmap -q "Subject: *****SPAM*****" regexp:<(
echo '/^Subject:.*(\*{5}SPAM\*{5})/ MATCHED ${1}'
)
MATCHED *****SPAM*****
If you were to ensure that the file actually used in main.cf
$header_checks listed sensible content:
main.cf:
header_checks = regexp:${config_directory}/spamdiscard
spamdiscard:
# Flush left, with no leading whitespace on any lines:
# All subject rules go here between "if" and "endif"
if /^Subject:/
/DISCARD WITH PREJUDICE/ DISCARD
/(\*{5}SPAM\*{5})/ DISCARD ${1}
# Any additional rules below
# ...
# /pattern/ DISCARD optional text
# ...
# Finally log any subjects that don't hit any rules
/^/ WARN
# Once tests are concluded comment out WARN above, and
# short-circuit via DUNNO, since no other subjects will
# be matched by any rules below for any other headers.
/^/ DUNNO
endif
# hypothetical
if /^X-Some-Other-Header:/
# /pattern/ ACTION
# ...
/^/ DUNNO
endif
# still hypothetical
if /^X-Yet-Another-Header:/
# /pattern/ ACTION
# ...
/^/ DUNNO
endif
Then you'd be able to test, and either see discarded messages, or
see the actual subjects that did not match any rules.
--
Viktor.
Den
Sep 13, 2014, 3:30:29 AM9/13/14
to
Hello Viktor!
Now that's a great example. Fantastic! Thank you. And you are right, I am
too tired to think straight. I'll test it the way you suggested as I was
about to come up and apply something like that as well but just after I get
a good rest first :-)
My apologies again (tired), I am not of course an expert and I definitely
make mistakes. Otherwise I wouldn't be asking if I knew it :-) This is what
I type on a command line to test:
postmap -q "Subject: *****SPAM***** blablalba"
regexp:/etc/postfix/spamdiscard
the rule is:
/^Subject:.*\*{5}SPAM\*{5}/ DISCARD *SPAM*
the response is:
DISCARD *SPAM*
therefore I assumed the rule was fine, but that appeared to mean that it was
a match only wasn't it?
Now let me share my other observations if you are interested to know.
The following rules all work fine and block (discard) emails that contain
*****SPAM*****
/^Subject .*\*\*\*\*\*SPAM\*\*\*\*\*/ DISCARD ***SPAM***
/^Subject:.*\*{5}SPAM\*{5}/ DISCARD *SPAM*
/^Subject:(.*)SPAM/ DISCARD 8
However, the following line when put in the subject field:
XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X
breaks all the above-mentioned rules and lets the message tagged
*****SPAM***** right into my inbox. This is another paradox that is
absolutely beyond me.
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70669.html
Now that's a great example. Fantastic! Thank you. And you are right, I am
too tired to think straight. I'll test it the way you suggested as I was
about to come up and apply something like that as well but just after I get
a good rest first :-)
My apologies again (tired), I am not of course an expert and I definitely
make mistakes. Otherwise I wouldn't be asking if I knew it :-) This is what
I type on a command line to test:
postmap -q "Subject: *****SPAM***** blablalba"
regexp:/etc/postfix/spamdiscard
the rule is:
/^Subject:.*\*{5}SPAM\*{5}/ DISCARD *SPAM*
the response is:
DISCARD *SPAM*
therefore I assumed the rule was fine, but that appeared to mean that it was
a match only wasn't it?
Now let me share my other observations if you are interested to know.
The following rules all work fine and block (discard) emails that contain
*****SPAM*****
/^Subject .*\*\*\*\*\*SPAM\*\*\*\*\*/ DISCARD ***SPAM***
/^Subject:.*\*{5}SPAM\*{5}/ DISCARD *SPAM*
/^Subject:(.*)SPAM/ DISCARD 8
However, the following line when put in the subject field:
XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X
breaks all the above-mentioned rules and lets the message tagged
*****SPAM***** right into my inbox. This is another paradox that is
absolutely beyond me.
--
View this message in context: http://postfix.1071664.n5.nabble.com/header-checks-not-working-tp36845p70669.html
Wietse Venema
Sep 13, 2014, 8:44:50 AM9/13/14
to
Den:
contain the string SPAM, while XJS*C4JDB...C.34X does not.
The pcre or regexp table will not recognize XJS*C4JDB...C.34X as
spam, until you configure a pattern that matches it.
Wietse
> /^Subject .*\*\*\*\*\*SPAM\*\*\*\*\*/ DISCARD ***SPAM***
> /^Subject:.*\*{5}SPAM\*{5}/ DISCARD *SPAM*
> /^Subject:(.*)SPAM/ DISCARD 8
>
> However, the following line when put in the subject field:
>
> XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X
That line matches none of the above patterns. All patterns
> /^Subject:.*\*{5}SPAM\*{5}/ DISCARD *SPAM*
> /^Subject:(.*)SPAM/ DISCARD 8
>
> However, the following line when put in the subject field:
>
> XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X
contain the string SPAM, while XJS*C4JDB...C.34X does not.
The pcre or regexp table will not recognize XJS*C4JDB...C.34X as
spam, until you configure a pattern that matches it.
Wietse
li...@rhsoft.net
Sep 21, 2014, 6:45:44 AM9/21/14
to
Am 12.09.2014 um 11:29 schrieb Den:
>> run the spamfilter after queue
>> http://www.postfix.org/MILTER_README.html
>
> Thanks. Will double-check on that. Chances also are that I missed something
> too or I might as well have to try to switch to these milters as running SA
> daemonized doesn't work. I posted my main.cf and my master.cf a bit earlier
since you still have not solved your issue:
if you would have used "spamass-milter" from the very begin
besides the before-queue filtering you would not need to
mangle around in postfix configurations to drop messages
it is practically complete nonsense to discard every message which
was tagged as can because you don't have any change to realize false
positives and train your bayes, a bayes without at least 200 ham
samples don't work and a contentfilter without bayse don't catch
that much
______________________________________________________________________
the "-r 8.0" is the reject score and is milter-only
the "-s" is the biggest scanned messagesize
spamass-milter -g sa-milt -r 8.0 -- -s 3145728.0 --port=10027
______________________________________________________________________
that's the score to tag the subject, both things are independent
required_hits 4.5
rewrite_header Subject [SPAM]
0 new messages