Re: Errors since upgrading to 3.4.1: "meta test ... with a zero score"
On Thu, Jun 15 2017, John Hardin wrote: > On Thu, 15 Jun 2017, Gerald Turner wrote: >> spamd[32137]: rules: meta test FREEMAIL_FORGED_FROMDOMAIN has dependency >> 'HEADER_FROM_DIFFERENT_DOMAINS' with a zero score >> spamd[31552]: rules: meta test __FORM_FRAUD_3 has dependency 'LOTTO_AGENT' >> with a zero score >> spamd[31552]: rules: meta test __MONEY_FRAUD_3 has dependency 'LOTTO_AGENT' >> with a zero score >> spamd[31552]: rules: meta test __FORM_FRAUD_5 has dependency 'LOTTO_AGENT' >> with a zero score >> spamd[31552]: rules: meta test __ADVANCE_FEE_4_NEW has dependency >> 'LOTTO_AGENT' with a zero score >> spamd[31552]: rules: meta test __MONEY_FRAUD_8 has dependency 'LOTTO_AGENT' >> with a zero score >> spamd[31552]: rules: meta test __ADVANCE_FEE_2_NEW has dependency >> 'LOTTO_AGENT' with a zero score >> spamd[31552]: rules: meta test __MONEY_FRAUD_5 has dependency 'LOTTO_AGENT' >> with a zero score >> spamd[31552]: rules: meta test __ADVANCE_FEE_3_NEW has dependency >> 'LOTTO_AGENT' with a zero score >> spamd[31552]: rules: meta test __ADVANCE_FEE_5_NEW has dependency >> 'LOTTO_AGENT' with a zero score >> spamd[31552]: rules: meta test __FORM_FRAUD has dependency 'LOTTO_AGENT' >> with a zero score > >> - Is there a bug with the project's sa-update channel / auto- >>mass-check setup? > > That's what it sounds like to me - it should not be omitting or > zeroing the scores of rules that participate in metas. > > Something is odd. This didn't come up on the old masscheck host, but > the score generation code should not have changed since then... > > It looks like it's not setting both the net and non-net scores for a > few rules: > > score FROM_IN_TO_AND_SUBJ1.099 0.000 1.099 0.000 > score HEADER_FROM_DIFFERENT_DOMAINS 0.001 0.000 0.001 0.000 > score HK_SCAM_N8 2.506 0.000 2.506 0.000 > score LOTTO_AGENT2.609 0.000 2.609 0.000 > > The non-network-enabled scores should only be zero for rules marked as > being network-dependent rules, and *all* rules should have a nonzero > network-enabled score (which appears to be the problem here). > > Something else odd is going on in the score generation: some > well-performing rules (notably URI_WP_HACKED) are now getting scored > at 1 point. There are only 56 rules listed in 72_scores.cf (the output > from the masscheck score generator), the rest would be defaulting to 1 > point. Uh oh! FWIW my 3.004001/updates_spamassassin_org/72_scores.cf contains the same lines: # grep 0.000 72_scores.cf score FROM_IN_TO_AND_SUBJ1.099 0.000 1.099 0.000 score HEADER_FROM_DIFFERENT_DOMAINS 0.001 0.000 0.001 0.000 score HK_SCAM_N8 2.506 0.000 2.506 0.000 score LOTTO_AGENT2.609 0.000 2.609 0.000 -- Gerald Turner Encrypted mail preferred! OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80 3858 EC94 2276 FDB8 716D signature.asc Description: PGP signature
Re: Errors since upgrading to 3.4.1: "meta test ... with a zero score"
On Thu, Jun 15 2017, David Jones wrote:
> On 06/15/2017 06:42 PM, Gerald Turner wrote:
>> What could be the cause?
>>
>>- Cruft left behind by old SA versions
>> (e.g. /etc/spamassassin/v310.pre, /var/lib/spamassassin/3.003001,
>> etc.)?
>
> Make sure you remove all old rule dirs like that
> one. /var/lib/spamassassin should only have your new 3.004001
> directory.
Interesting. I had these files in /var/lib/spamassassin:
# ls -l
drwxr-xr-x 3 debian-spamd debian-spamd 4096 May 5 2013 3.003001
drwxr-xr-x 3 debian-spamd debian-spamd 4096 Apr 23 2015 3.003002
drwxr-xr-x 3 debian-spamd debian-spamd 4096 Jun 11 07:09 3.004000
drwxr-xr-x 3 debian-spamd debian-spamd 4096 Jun 15 06:47 3.004001
drwxr-xr-x 6 debian-spamd debian-spamd 4096 Jun 11 13:25 compiled
drwx-- 3 debian-spamd debian-spamd 4096 Jun 11 13:55 sa-update-keys
# ls -l compiled
drwxr-xr-x 3 debian-spamd debian-spamd 4096 Sep 3 2010 5.010
drwxr-xr-x 3 debian-spamd debian-spamd 4096 May 5 2013 5.014
drwxr-xr-x 3 debian-spamd debian-spamd 4096 Apr 26 2015 5.020
drwxr-xr-x 3 debian-spamd debian-spamd 4096 Jun 11 13:25 5.024
I removed *all* of these directories except for sa-update-keys, then
re-ran sa-update and sa-compile, resulting in much cleaner
/var/lib/spamassassin directory:
# ls -l
drwxr-xr-x 3 debian-spamd debian-spamd 4096 Jun 15 17:54 3.004001
drwxr-xr-x 3 debian-spamd debian-spamd 4096 Jun 15 17:55 compiled
drwx-- 3 debian-spamd debian-spamd 4096 Jun 11 13:55 sa-update-keys
# ls -l compiled
drwxrwxr-x 3 debian-spamd debian-spamd 4096 Jun 15 17:55 5.024
>>- Is there a bug with the project's sa-update channel / auto-
>> mass-check setup?
>>
> I hope not. I have spent dozens and dozens of hours getting the
> masscheck processing running again on a new server. It seems to be
> working fine to me. We tested for a couple of weeks before going live
> with sa-update updates recently.
I hope not either. Apologies for insinuating updates are bugged. Your
work on SA is much appreciated, thanks! :)
>> Any ideas?
>>
> 1. Clean up any old versions of rules in /var/lib/spamassassin.
> 2. Make sure that spamd is restarted to pickup the rule changes
> 3. Run this to find any issues:
>
> spamassassin -D --lint 2>&1 | grep -Ei '(failed|undefined dependency|score
> set for non-existent rule)'
This resulted in:
Jun 15 17:56:03.036 [12601] dbg: diag: [...] module not installed:
Digest::SHA1 ('require' failed)
Jun 15 17:56:03.036 [12601] dbg: diag: [...] module not installed: Geo::IP
('require' failed)
Jun 15 17:56:03.036 [12601] dbg: diag: [...] module not installed:
Net::CIDR::Lite ('require' failed)
Jun 15 17:56:03.037 [12601] dbg: diag: [...] module not installed:
Encode::Detect::Detector ('require' failed)
Jun 15 17:56:03.037 [12601] dbg: diag: [...] module not installed:
Net::Patricia ('require' failed)
Jun 15 17:56:03.945 [12601] dbg: config: warning: score set for non-existent
rule FILL_THIS_FORM_FRAUD_PHISH
Jun 15 17:56:03.945 [12601] dbg: config: warning: score set for non-existent
rule RCVD_IN_SORBS_SPAM
Jun 15 17:56:03.946 [12601] dbg: config: warning: score set for non-existent
rule URI_OBFU_WWW
Much of these Perl modules are packaged as Recommends/Suggests metadata
to the Debian spamassassin package. Installed all of them except for
for Digest::SHA1 - I believe there must have been a historical change
from Digest::SHA1 to Digest::SHA, and SA has compatibility to load
either - at least that's my understanding after poking around SA's
source a bit.
[INSTALL, DEPENDENCIES] libdigest-sha-perl:amd64 5.96-1+b1
[INSTALL, DEPENDENCIES] libencode-detect-perl:amd64 1.01-4+b3
[INSTALL, DEPENDENCIES] libgeo-ip-perl:amd64 1.50-1+b1
[INSTALL, DEPENDENCIES] libnet-patricia-perl:amd64 1.22-1+b3
[INSTALL, DEPENDENCIES] libnet-cidr-lite-perl:amd64 0.21-1
Sadly, after this long overdue pass at SA cleanup, I still have the zero
score warnings:
spamd[12588]: rules: meta test __MONEY_FRAUD_8 has dependency 'LOTTO_AGENT'
with a zero score
spamd[12588]: rules: meta test __ADVANCE_FEE_2_NEW has dependency
'LOTTO_AGENT' with a zero score
spamd[12588]: rules: meta test FREEMAIL_FORGED_FROMDOMAIN has dependency
'HEADER_FROM_DIFFERENT_DOMAINS' with a zero score
spamd[12588]: rules: meta test __ADVANCE_FEE_5_NEW has dependency
'LOTTO_AGENT' with a zero score
spamd[12588]: rules: meta test __FORM_FRAUD has dependency 'LOTTO_AGENT' with
a zero score
spamd[12588]: rules: meta test __ADVANCE_FEE_3_NEW has dependency
'LOTTO_AGENT' with a zero score
spamd[12588]: rules: meta test __MONEY_FRAUD_5 has dependency 'LOTTO_AGENT'
with a zero score
spamd[12588]: rules: meta test __FORM_FRA
Errors since upgrading to 3.4.1: "meta test ... with a zero score"
Hello list, I'm a happy long-time user of SA, and just upgraded a mail
server from Debian 8 "jessie" to Debian 9 "stretch", and in turn
upgraded SA from 3.4.0 to 3.4.1. The upgrade was smoothe, other than
some irrelevant breakage with FuzzyOCR¹, however there's been an
enormous increase in syslog messages that I've been combating, and I
cannot find the root cause.
Upon upgrading to SA 3.4.1, each email scanned is emitting the following
message to syslog:
spamd[32137]: rules: meta test FREEMAIL_FORGED_FROMDOMAIN has dependency
'HEADER_FROM_DIFFERENT_DOMAINS' with a zero score
After a bit of searching, I gave up and simply added the following line
to /etc/spamassassin/local.cf:
score HEADER_FROM_DIFFERENT_DOMAINS 0.001
Now a week later, a simlar set of 'meta test ... with a zero score'
syslog messages have appeared:
spamd[31552]: rules: meta test __FORM_FRAUD_3 has dependency 'LOTTO_AGENT'
with a zero score
spamd[31552]: rules: meta test __MONEY_FRAUD_3 has dependency 'LOTTO_AGENT'
with a zero score
spamd[31552]: rules: meta test __FORM_FRAUD_5 has dependency 'LOTTO_AGENT'
with a zero score
spamd[31552]: rules: meta test __ADVANCE_FEE_4_NEW has dependency
'LOTTO_AGENT' with a zero score
spamd[31552]: rules: meta test __MONEY_FRAUD_8 has dependency 'LOTTO_AGENT'
with a zero score
spamd[31552]: rules: meta test __ADVANCE_FEE_2_NEW has dependency
'LOTTO_AGENT' with a zero score
spamd[31552]: rules: meta test __MONEY_FRAUD_5 has dependency 'LOTTO_AGENT'
with a zero score
spamd[31552]: rules: meta test __ADVANCE_FEE_3_NEW has dependency
'LOTTO_AGENT' with a zero score
spamd[31552]: rules: meta test __ADVANCE_FEE_5_NEW has dependency
'LOTTO_AGENT' with a zero score
spamd[31552]: rules: meta test __FORM_FRAUD has dependency 'LOTTO_AGENT' with
a zero score
Looking at the timestamps of /var/lib/spamassassin/3.004001 files
reveals that there was an sa-update this morning, minutes before the
warning messages began.
Now I suppose I'll add another line to local.cf ("score LOTTO_AGENT
0.001"), but this doesn't feel right - this server has been setup for
ten+ years, has been through four or five Debian stable upgrades, and
the corresponding SA upgrades, and in all these years SA has been low
maintenance.
What could be the cause?
- Cruft left behind by old SA versions
(e.g. /etc/spamassassin/v310.pre, /var/lib/spamassassin/3.003001,
etc.)?
- Is there a bug with the project's sa-update channel / auto-
mass-check setup?
- Configuration for sa-update's channels seems rather sparse, and I
see no evidence that I'm using anything other than the
defaults. Could I be pulling from the wrong channel?
FWIW my local.cf is pretty boring, a bit of bayes configuration,
trusted_networks and shortcircuit options. On a per-user basis there
are a few odd custom rules, but nothing hitting this "money" and/or
freemail stuff.
I ran “spamassassin -D --lint” and it only reported dbg messages, none
of which contained "LOTTO_AGENT".
I also manually ran “su debian-spamd -c "sa-update --refreshmirrors -D
channel,gpg,http --gpghomedir /var/lib/spamassassin/sa-update-keys"”,
which is normally handled by Debian's cron.daily script, and it's output
was clean:
Jun 15 16:25:55.464 [3027] dbg: gpg: Searching for 'gpg'
Jun 15 16:25:55.464 [3027] dbg: gpg: found /usr/bin/gpg
Jun 15 16:25:55.464 [3027] dbg: gpg: release trusted key id list:
0C2B1D7175B852C64B3CDC716C55397824F434CE
5E541DC959CB8BAC7C78DFDC4056A61A5244EC45
Jun 15 16:25:55.465 [3027] dbg: channel: attempting channel
updates.spamassassin.org
Jun 15 16:25:55.465 [3027] dbg: channel: using existing directory
/var/lib/spamassassin/3.004001/updates_spamassassin_org
Jun 15 16:25:55.465 [3027] dbg: channel: channel cf file
/var/lib/spamassassin/3.004001/updates_spamassassin_org.cf
Jun 15 16:25:55.465 [3027] dbg: channel: channel pre file
/var/lib/spamassassin/3.004001/updates_spamassassin_org.pre
Jun 15 16:25:55.466 [3027] dbg: channel: metadata version = 1798658, from
file /var/lib/spamassassin/3.004001/updates_spamassassin_org.cf
Jun 15 16:25:55.561 [3027] dbg: channel: current version is 1798658, new
version is 1798658, skipping channel
Any ideas?
¹ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808572
--
Gerald Turner Encrypted mail preferred!
OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80 3858 EC94 2276 FDB8 716D
signature.asc
Description: PGP signature
Re: Postfix, spamc per-user, with aliases?
Gerald Turner writes:
> Looks like Postfix alias lookup is only handled by local(8) and not
> something accessible to pipe(8). The only foreseeable option is to
> duplicate the lookup in a shell script, which isn't pretty because I'm
> using a combination of aliases db and LDAP.
>
> Anyone have experience with this?
>
Ha! Found similar question from April on postfix-user:
http://thread.gmane.org/gmane.mail.postfix.user/220489/focus=220494
Replace all the spamc bits from master.cf, and the current
mailbox_command = /usr/lib/dovecot/deliver in main.cf with:
mailbox_command = /usr/bin/spamc -u ${user} -e /usr/lib/dovecot/deliver
--
Gerald Turner Email: gtur...@unzane.com JID: gtur...@unzane.com
GPG: 0xFA8CD6D5 21D9 B2E8 7FE7 F19E 5F7D 4D0C 3FA0 810F FA8C D6D5
pgpC2uj1xAkUj.pgp
Description: PGP signature
Postfix, spamc per-user, with aliases?
Hello,
I'm using a Postfix after-queue configuration very close to what is
documented on the SpamAssassin wiki[1]. Works great with mail where
localpart matches a user, but doesn't work so great for aliases. I'm
using the spamc -u argument so that each user has their own prefs,
bayes, awl, etc., master.cf will fallback to 'nobody' if setuid fails
(in the case of an alias), and there will be a few harmless errors and
spamassassin will still get the job done with system-wide default
behavior.
Looks like Postfix alias lookup is only handled by local(8) and not
something accessible to pipe(8). The only foreseeable option is to
duplicate the lookup in a shell script, which isn't pretty because I'm
using a combination of aliases db and LDAP.
Anyone have experience with this?
Example fallback messages when using an alias:
spamd: connection from localhost [127.0.0.1] at port 49244
spamd: handle_user unable to find user: 'admins'
spamd: still running as root: user not specified with -u, not found, or set
to root, falling back to nobody
spamd: processing message for admins:65534
auto-whitelist: open of auto-whitelist file failed: locker: safe_lock: cannot
create lockfile /nonexistent/.spamassassin/auto-whitelist.mutex: No such file
or directory
spamd: clean message (-0.1/3.0) for admins:65534 in 1.7 seconds, 2879 bytes.
spamd: result: . 0 - AAA,BBB
scantime=1.7,size=2879,user=admins,uid=65534,required_score=3.0,rhost=localhost,raddr=127.0.0.1,rport=49244,mid=,autolearn=no,shortcircuit=no
prefork: child states: I
... then pickup/qmgr/local take over and 'admins' is expanded to the
real user(s)
Configuration:
main.cf:
spamc_destination_recipient_limit = 1
master.cf:
smtp inet n - - - 20 smtpd
-o content_filter=spamc
spamc unix - n n - 5 pipe
flags=u user=nobody argv=/etc/postfix/spamc-filter -u ${user}
-e /usr/sbin/sendmail -oi -f ${sender} ${recipient}
spamc-filter:
#!/bin/sh
(/bin/cat | /usr/bin/spamc -x $@) || {
echo spamc exit code $? 1>&2
exit 75
}
[1] http://wiki.apache.org/spamassassin/IntegratedSpamdInPostfix
--
Gerald Turner Email: gtur...@unzane.com JID: gtur...@unzane.com
GPG: 0xFA8CD6D5 21D9 B2E8 7FE7 F19E 5F7D 4D0C 3FA0 810F FA8C D6D5
pgpeQbKgTKLgf.pgp
Description: PGP signature
Re: Spamd hits 100% and times out - Started today
Karsten Bräckelmann writes: > On Sun, 2011-03-20 at 22:09 +0100, JKL wrote: >> On 03/20/2011 10:04 PM, Karsten Bräckelmann wrote: > >> > This appears to be a bug with re2c (using sa-compile) and some >> > combination of hardware architecture and/or OS. Bug 6558 [1]. > >> > [1] https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558 >> >> Thanks for the heads up. Is there an easy way to disable this rule so >> its not hit? What is the name of the file that contains __PILL_PRICE ? > > Did you read the bug report? Commenting out the tflags multiple lines > for all three __PILL_PRICE_x rules will do. You'll need to re-run > sa-compile, of course. > > In this case, this is surgery in 72_active.cf, found in your sa-update > maintained rules channel. > > An alternative (untested) should be, to drop this in your site config > local.cf -- disable the sub-rules, without breaking their dependencies. > > meta __PILL_PRICE_1 (0) > meta __PILL_PRICE_2 (0) > meta __PILL_PRICE_3 (0) Thanks Karsten, the meta rules in local.cf works for me, no surgery or recompile necessary. My spamassassin/postfix server held up pretty well, I was alerted to oom-killer kernel messages Sunday morning, and again this morning, while trying to debug the problem I was headed down razor/pyzor timeout issues since fork errors were the only clue I had to go on, until I caught up on this mailing list thread. Thank you guys! FYI: $ spamassassin -V SpamAssassin version 3.3.1 running on Perl version 5.10.1 $ uname -a Linux azathoth 2.6.32-5-xen-amd64 #1 SMP Wed Jan 12 05:46:49 UTC 2011 x86_64 GNU/Linux $ lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux 6.0.1 (squeeze) Release:6.0.1 Codename: squeeze $ head -n11 /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 26 model name : Intel(R) Xeon(R) CPU E5520 @ 2.27GHz stepping: 5 cpu MHz : 2255.410 cache size : 8192 KB fpu : yes fpu_exception : yes cpuid level : 11 -- Gerald Turner Email: gtur...@unzane.com JID: gtur...@unzane.com GPG: 0xFA8CD6D5 21D9 B2E8 7FE7 F19E 5F7D 4D0C 3FA0 810F FA8C D6D5 pgpbSzIRhAvKE.pgp Description: PGP signature
Re: Pyzor problem
"Hans-Werner Friedemann" writes: > Hi @ all > > what´s the matter with pyzor if I get the following hint by starting > spamd? > > Wed Sep 29 11:23:29 2010 [5176] info: urlredirect: No redirectors! > Wed Sep 29 11:23:29 2010 [5176] info: zoom: able to use 675/1223 'body_0' > compiled rules (55.192%) > Wed Sep 29 11:23:39 2010 [5176] info: pyzor: [5182] error: TERMINATED, signal > 15 (000f) > Wed Sep 29 11:23:39 2010 [5176] info: spamd: server started on port 783/tcp > (running version 3.3.1) > Wed Sep 29 11:23:39 2010 [5176] info: spamd: server pid: 5176 > Wed Sep 29 11:23:39 2010 [5176] info: spamd: server successfully spawned > child process, pid 5184 > Wed Sep 29 11:23:39 2010 [5176] info: spamd: server successfully spawned > child process, pid 5185 > Wed Sep 29 11:23:39 2010 [5176] info: spamd: server successfully spawned > child process, pid 5186 > Wed Sep 29 11:23:39 2010 [5176] info: spamd: server successfully spawned > child process, pid 5187 > Wed Sep 29 11:23:39 2010 [5176] info: spamd: server successfully spawned > child process, pid 5189 > > Thanks for your help! I've been investigating this problem as well, I believe it is a timeout error. People have been discussing the timeout issue on the pyzor mailing list for months, with no resolution: http://sourceforge.net/mailarchive/forum.php?thread_name=4C07B30A.8080300%40spamexperts.com&forum_name=pyzor-users -- Gerald Turner Email: gtur...@unzane.com JID: gtur...@unzane.com GPG: 0xFA8CD6D5 21D9 B2E8 7FE7 F19E 5F7D 4D0C 3FA0 810F FA8C D6D5 pgpz7nvw2Mdge.pgp Description: PGP signature
Re: Alternative to Postfix header_checks?
mouss writes:
> Gerald Turner a écrit :
>> Hello, I have been using SpamAssassin integrated with Postfix via
>> spampd SMTP proxy and I have the following header_checks file:
>>
>> /^X-Spam-Level: \*{8,}/ DISCARD Spam score 8+
>> /^X-Spam-Level: \*{4,}/ REJECT Spam score 4+
>>
>> There are cases where I'd rather DISCARD the low score mail (>= 4, <
>> 8) than REJECT, for instance:
>>
>>When the mail contains mailing-list headers - some mailing lists
>>unsubscribe after too many bounces, particularly Debian with
>>open/unmoderated lists.
>>
>>When the mail was sent to a quasi-spamtrap address - I'm aliased
>>on a few hosts with webmas...@example.com type addresses, some of
>>which will generate bounce warnings to mailer-daemon who is
>>aliased to several people, evil!
>>
>> Unfortunately Postfix header_checks can only process one header at a
>> time, there's no way to compound conditions of multiple headers.
>> I've searched and can't seem to come up with any possibility of
>> configuring Postfix to conditionally discard rather than bounce. I'm
>> on the verge of customizing an example Perl milter to do the job, but
>> it seems like something that should be built-in to either Postfix,
>> spampd, or perhaps amavisd-new - any suggestions?
>>
>
> first, add an SA rule to detect mailing lists. for example
>
> header H_FROM_ML ...
> score H_FROM_ML 0.01
>
> (actually, you will need multiple rules, then combine them with a
> meta).
>
> then your header checks would become
>
> /^X-Spam-Status: Yes, score=([8-9]|\d{2}).*H_FROM_ML/
>
Excellent! Checking X-Spam-Status rather than X-Spam-Level totally
escaped me, thanks.
> some notes:
>
> - unless you are calling SA during the smtp transaction, you should
> not reject mail (ie after it was queued by postfix)
>
It is before-queue while the SMTP connection is still active. I like to
bounce in case legitimate people that have yet to be whitelisted trigger
a false-positive.
> - discarding mail is risky.
>
Other than possibly dropping a false-positive is there anything else I
should know of?
> - spammers can forge list headers...
>
Yes but I think I'm getting what I want in this case: list spam is
discarded, whether forged or not.
> - There are other cases when you don't want to reject (mail to
> ab...@example.com, ... etc).
That's the other problem I'm trying to solve (don't reject mail sent to
these "quasi-spamtrap" addresses, simply discard) - I can see how to do
it now with custom rules checked in X-Spam-Status header. Thanks for
the suggestion.
--
Gerald Turner Email: gtur...@unzane.com JID: gtur...@jabber.unzane.com
GPG: 0xFA8CD6D5 21D9 B2E8 7FE7 F19E 5F7D 4D0C 3FA0 810F FA8C D6D5
Re: Alternative to Postfix header_checks?
LuKreme writes: > On 6-Jan-2009, at 15:39, Gerald Turner wrote: >> Unfortunately Postfix header_checks can only process one header at a >> time, there's no way to compound conditions of multiple headers. >> I've searched and can't seem to come up with any possibility of >> configuring Postfix to conditionally discard rather than bounce. I'm >> on the verge of customizing an example Perl milter to do the job, but >> it seems like something that should be built-in to either Postfix, >> spampd, or perhaps amavisd-new - any suggestions? > > Can't you rewrite a header based on conditions? > Not with header_checks (http://www.postfix.org/header_checks.5.html), although there is a REPLACE action, it still couldn't operate on a combination of headers. > The other thing you could do is setup a separate submission port for > tested messages? Or a policy server? > Yeah, that's kind of what I'm thinking with writing a hacked up Perl milter. Thanks. -- Gerald Turner Email: gtur...@unzane.com JID: gtur...@jabber.unzane.com GPG: 0xFA8CD6D5 21D9 B2E8 7FE7 F19E 5F7D 4D0C 3FA0 810F FA8C D6D5
Alternative to Postfix header_checks?
Hello, I have been using SpamAssassin integrated with Postfix via spampd
SMTP proxy and I have the following header_checks file:
/^X-Spam-Level: \*{8,}/ DISCARD Spam score 8+
/^X-Spam-Level: \*{4,}/ REJECT Spam score 4+
There are cases where I'd rather DISCARD the low score mail (>= 4, < 8)
than REJECT, for instance:
When the mail contains mailing-list headers - some mailing lists
unsubscribe after too many bounces, particularly Debian with
open/unmoderated lists.
When the mail was sent to a quasi-spamtrap address - I'm aliased on a
few hosts with webmas...@example.com type addresses, some of which
will generate bounce warnings to mailer-daemon who is aliased to
several people, evil!
Unfortunately Postfix header_checks can only process one header at a
time, there's no way to compound conditions of multiple headers. I've
searched and can't seem to come up with any possibility of configuring
Postfix to conditionally discard rather than bounce. I'm on the verge
of customizing an example Perl milter to do the job, but it seems like
something that should be built-in to either Postfix, spampd, or perhaps
amavisd-new - any suggestions?
--
Gerald Turner Email: gtur...@unzane.com JID: gtur...@jabber.unzane.com
GPG: 0xFA8CD6D5 21D9 B2E8 7FE7 F19E 5F7D 4D0C 3FA0 810F FA8C D6D5
