ed headers added by trusted
machines), of course if you trust that machine.
all further headers, e.g. X-Spam-* headers put at the end of headers are not
trusted, even the sender can add them and trick you e.g. into thinking your mail
is not spammy, clear of viruses etc.
... however I see that
Am Mittwoch, dem 05.07.2023 um 14:50 +0200 schrieb Reindl Harald:
>
> *nothing* should touch existing headers as you also have multiple
> Reveived-headers
Good point. So, it seems that spamass-milter is doing things a bit,
well, unconventional...
I thought this is the case to not confuse later
Am Mittwoch, dem 05.07.2023 um 10:20 +0200 schrieb Matus UHLAR -
fantomas:
> On 05.07.23 04:38, Robert Senger wrote:
> > Thanks for the hint that the milter is responsible for that. Found
> > a
> > little patch for spamass-milter that fixed this.
>
> note that the headers that appear first in the
lters put added headers at the beginning of message.
On 7/4/2023 7:38 PM, Robert Senger wrote:
> is there a reason why spamassassin adds its "X-Spam ..." headers to
> the
> bottom of the header block, not to the top like every other mail
> filtering software (e.g. opendkim, o
ds its "X-Spam ..." headers to
> > the
> > bottom of the header block, not to the top like every other mail
> > filtering software (e.g. opendkim, opendmarc, clamav ... ) does?
> > Can
> > this behavious be changed?
> Mine are at the top, but usually this
Hi Jared,
I am using spamass-milter.
Robert
Am Dienstag, dem 04.07.2023 um 19:45 -0400 schrieb Jared Hall:
> On 7/4/2023 7:38 PM, Robert Senger wrote:
> > is there a reason why spamassassin adds its "X-Spam ..." headers to
> > the
> > bottom of the header block,
On 7/4/2023 7:38 PM, Robert Senger wrote:
is there a reason why spamassassin adds its "X-Spam ..." headers to the
bottom of the header block, not to the top like every other mail
filtering software (e.g. opendkim, opendmarc, clamav ... ) does? Can
this behavious be changed?
Mine are
Hi all,
is there a reason why spamassassin adds its "X-Spam ..." headers to the
bottom of the header block, not to the top like every other mail
filtering software (e.g. opendkim, opendmarc, clamav ... ) does? Can
this behavious be changed?
Regards,
Robert
--
Robert Senger
Hi,
That was the problem, thanks David!
Apparently I hadn't restarted spamassassin properly when making this change
because it dates from September the 13th while spamassassin stopped tagging
my messages since November 11th only.
Thanks all,
Cyrille
"David Bürgin" dbuer...@glue
Cyrille Bollu:
> spamass+ 673 1 0 13:06 ? 00:00:00 /usr/sbin/spamass-milter -P
> /var/run/spamass/spamass.pid -f -p /var/spool/postfix/spamass/spamass.sock -u
> spamass-milter -d func,misc,net,poll,rcpt,spamc,str,uori -i 127.0.0.1 -- -s
> 10485760 -r 10
-r 10 is in the wrong place
No no:
root@bollu:/home/debian# ps -eaf | grep spamass-milter
spamass+ 673 1 0 13:06 ? 00:00:00
/usr/sbin/spamass-milter -P /var/run/spamass/spamass.pid -f -p
/var/spool/postfix/spamass/spamass.sock -u spamass-milter -d
func,misc,net,poll,rcpt,spamc,str,uori -i 127.0.0.1 -- -s 104
On 26.11.21 12:53, Cyrille Bollu wrote:
postfix communicates with spamassassin via a milter:
# milter settings (for DKIM, spam filters,...)
smtpd_milters = unix:/opendkim/opendkim.sock,local:spamass/spamass.sock
non_smtpd_milters = $smtpd_milters
As said, I can see logs in mail.log that sh
Hello,
postfix communicates with spamassassin via a milter:
# milter settings (for DKIM, spam filters,...)
smtpd_milters = unix:/opendkim/opendkim.sock,local:spamass/spamass.sock
non_smtpd_milters = $smtpd_milters
As said, I can see logs in mail.log that show messages being processed and
> What should happen technically is that Postfix connects to the milter,
> the milter uses spamc to communicate with SpamAssassin/spamd, and
> finally the milter will add the new headers it receives from
> SpamAssassin.
To expand a little bit on this, the crucial thing is that all components
can c
And does Postfix connect via the milter and spamc, or does it call
spamassassin directly? For example, I have this in /etc/postfix/main.cf:
smtpd_milters =
...
unix:spamassassin/spamassassin-milter.sock
Another thing to try is enable more logging in spamass-milter to see
what it’s doing.
Wha
Hi,
Here's my config. It's quite a default one: I didn't change much (I show
you below what I've changed)
Best regards,
Cyrille
= CONFIG ==
root@bollu:/etc# grep -v '^#' default/spamassassin | grep -v '^$'
OPTIONS="-D --create-prefs --max-children 5 --helper
First we would need to see the spamd config,
SpamAssassin config, spamass-milter config
to see how it is all wired up.
ests_pri_0: 473
(75.4%), check_dkim_signature: 0.85 (0.1%), check_dkim_adsp: 355 (56.6%),
poll_dns_idle: 312 (49.7%), check_spf: 1.37 (0.2%), check_pyzor: 0.38
(0.1%), tests_pri_500: 11 (1.7%), get_report: 0.60 (0.1%), copy_config: 46
(7.4%)
Eventualy, I can see in my dovecot Maildir that the me
+0300, Henrik K wrote:
On Thu, Jul 22, 2021 at 05:15:54PM +0200, Martin Flygenring wrote:
Is there a limitation to SpamAssassin so it doesn't accept
looking for the two X-Spam-headers, or can you spot why this rule
isn't matching?
SA removes all X-Spam-* headers from the message, it'
ethod.
>>
>> Cheers,
>> Laurent
>>
>> On 22.07.21 21:31, RW wrote:
>>> On Thu, 22 Jul 2021 20:09:19 +0300
>>> Henrik K wrote:
>>>
>>>> On Thu, Jul 22, 2021 at 08:06:15PM +0300, Henrik K wrote:
>>>>> On Thu, Jul 22,
2 Jul 2021 20:09:19 +0300
Henrik K wrote:
On Thu, Jul 22, 2021 at 08:06:15PM +0300, Henrik K wrote:
On Thu, Jul 22, 2021 at 05:15:54PM +0200, Martin Flygenring wrote:
Is there a limitation to SpamAssassin so it doesn't accept
looking for the two X-Spam-headers, or can you spot why this
Martin Flygenring wrote:
>>>>
>>>> Is there a limitation to SpamAssassin so it doesn't accept
>>>> looking for the two X-Spam-headers, or can you spot why this rule
>>>> isn't matching?
>>>
>>> SA removes all X-Spam-* header
On Thu, 22 Jul 2021 20:09:19 +0300
Henrik K wrote:
> On Thu, Jul 22, 2021 at 08:06:15PM +0300, Henrik K wrote:
> > On Thu, Jul 22, 2021 at 05:15:54PM +0200, Martin Flygenring wrote:
> > >
> > > Is there a limitation to SpamAssassin so it doesn't accept
> >
On Thu, Jul 22, 2021 at 08:06:15PM +0300, Henrik K wrote:
> On Thu, Jul 22, 2021 at 05:15:54PM +0200, Martin Flygenring wrote:
> >
> > Is there a limitation to SpamAssassin so it doesn't accept looking for the
> > two X-Spam-headers, or can you spot why this rule isn&#
On Thu, Jul 22, 2021 at 05:15:54PM +0200, Martin Flygenring wrote:
>
> Is there a limitation to SpamAssassin so it doesn't accept looking for the
> two X-Spam-headers, or can you spot why this rule isn't matching?
SA removes all X-Spam-* headers from the message, it's
Martin Flygenring wrote:
Hi.
I'm trying to write a rule that matches on a mail that has the
following headers:
X-Spam-Reasons: {'verdict': 'phishing',
'spamcause':
'gggruggvucftvghtrhhoucdtuddrgedvtddruddvgddugecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfkpffvgfftoffgfffktedpqfgfvfenuceurgh
since it's matching on the
X-AES-Category header which comes after, and removing that
X-Spam-Reasons header doesn't change anything for the X-Spam-Category
header, so that doesn't seem to be the issue.
Is there a limitation to SpamAssassin so it doesn't accept looking for
t
>From time to time (rarely) I notice that spamass-milter does not for
some reason add the x-spam-* headers to a message, but I clearly see
the "Milter add: header: X-Spam-Status:" in the mail log.
For example, this is in the mail.log but nothing in the message received:
Jan 22 13:
Yes, that does look like it. If that hasn't made it into the standard
Fedora repo by the time of my next scheduled update I'll pull it it from
Testing - I've got enough other stuff I need to deal with right now
without adding in a 3.3.2->3.4.0 conversion.
Final follow-up
===
Yesterday
On Mon, 2014-06-02 at 02:41 +0200, Karsten Bräckelmann wrote:
> If that is the culprit, the easiest, fastest and most painless way of
> getting a fully functional SA back, is to revert the recent Perl
> Net::DNS upgrade.
>
Yes, I can now confirm that the problem was the recent upgrade of
Net::DNS
On Sun, 2014-06-01 at 09:13 +0100, Martin Gregorie wrote:
> On Sun, 2014-06-01 at 03:01 +0200, Karsten Bräckelmann wrote:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1096405
> >
> > Comment 5 also mentions an issue with Perl Net::DNS 0.75, which is the
> > exact version the package upgrade
On Sun, 2014-06-01 at 03:01 +0200, Karsten Bräckelmann wrote:
> That error message rings a bell. Will (aragonx?) posted that line very
> recently, and updated the thread himself just today, pointing to a RH /
> Fedora 20 bugzilla report for its SA 3.3.2 package, related to Perl
> Net::DNS 0.76 (on
On Sun, 2014-06-01 at 01:20 +0100, Martin Gregorie wrote:
> On Sun, 2014-06-01 at 01:21 +0200, Karsten Bräckelmann wrote:
> > For bonus-points, watch the logs for spamd claiming to be ready.
>
> Here you go:
> Jun 1 01:07:41 zappa spamd[15831]: plugin: eval failed: Insecure
> dependency in conn
On Sun, 2014-06-01 at 01:21 +0200, Karsten Bräckelmann wrote:
> I haven't really used systemd yet, but one fundamental design decision
> is, that systemd itself takes care about sockets and stuff, returning
> early and asynchronously lets the service complete starting up in the
> background.
>
Th
On Sat, 2014-05-31 at 23:07 +0100, Martin Gregorie wrote:
> On Sat, 2014-05-31 at 20:15 +0200, Karsten Bräckelmann wrote:
> > > The testsa script looks like this:
> >
> > > state=$(spamdstatus)
> > > if [ "$state" == 'spamd is stopped' ]
> > > then
> > > sudo systemctl start spamassassin.servic
On Sat, 2014-05-31 at 20:15 +0200, Karsten Bräckelmann wrote:
> $ which -a spamc
>
'locate spamc' turned up a copy of spamc 3.2.4 in /usr/local/bin dated
2008. I can't remember how it might have got there since I've only ever
installed SA from the Fedora repo. Anyway, that is gone now and both
spa
On Sat, 2014-05-31 at 17:39 +0100, Martin Gregorie wrote:
> On Tue, 2014-05-27 at 02:48 +0200, Karsten Bräckelmann wrote:
> > A quick googlin' brings up spamassassin 3.3.2-18.fc20 for Fedora 20, in
> > a single package shipping both spamc and spamd in /usr/bin.
>
> After deleting and reinstalling
machine. No change, so I tried a few stripped-down runs, i.e. I
> > started spamd via a test script that uses systemctl to start or stop it
> > and then used "spamc > with spamc options. In the course of this I noticed a strange effect:
> >
> > The FIRST mess
d via a test script that uses systemctl to start or stop it
> and then used "spamc with spamc options. In the course of this I noticed a strange effect:
>
> The FIRST message after restarting spamd never has X-Spam headers, but
> the second and subsequent ones do have X-Spam headers.
&g
On Sat, 2014-05-24 at 05:04 +0200, Karsten Bräckelmann wrote:
> On Sat, 2014-05-24 at 03:28 +0100, Martin Gregorie wrote:
> > On Sat, 2014-05-24 at 02:36 +0200, Karsten Bräckelmann wrote:
>
> > I've looked down the list a couple of times and didn't see anything I
> > thought would affect it due to
On Sat, 2014-05-24 at 03:28 +0100, Martin Gregorie wrote:
> On Sat, 2014-05-24 at 02:36 +0200, Karsten Bräckelmann wrote:
> I've looked down the list a couple of times and didn't see anything I
> thought would affect it due to a possibly bad assumption that this sort
> of error would be insulated
On Sat, 2014-05-24 at 03:28 +0100, Martin Gregorie wrote:
> I'll post the complete list either later today or on Tuesday (this is
> the start of the second May Bank Holiday weekend).
>
Here you go. This is the yum upgrade summary:
Packages Installed:
kernel-PAE-3.14.4-200.fc20.i686
Gr
On Sat, 2014-05-24 at 02:36 +0200, Karsten Bräckelmann wrote:
> On Sat, 2014-05-24 at 01:10 +0100, Martin Gregorie wrote:
> > On Sat, 2014-05-24 at 01:12 +0200, Karsten Bräckelmann wrote:
>
> > > > > The yum upgrade replaced three Perl libraries:
> > >
> > > Is that everything that was upgraded,
On Sat, 2014-05-24 at 01:10 +0100, Martin Gregorie wrote:
> On Sat, 2014-05-24 at 01:12 +0200, Karsten Bräckelmann wrote:
> > > > The yum upgrade replaced three Perl libraries:
> >
> > Is that everything that was upgraded, or just the Perl bits?
>
> Just the Perl bits.
Figured as much. That ra
On Sat, 2014-05-24 at 01:12 +0200, Karsten Bräckelmann wrote:
> On Sat, 2014-05-24 at 00:34 +0200, Axb wrote:
> > On 05/24/2014 12:23 AM, Martin Gregorie wrote:
>
> > > 2 Failure of spamc/spamd to output any X-Spam headers
> > > ==
ral tests. Each spam
example is simply a text file which Evolution has dumped a spam message
into under the impression that its saving it in mbox format and that has
then been passed through an awk script that strips out any X-Spam
headers.
> This sounds similar to the behavior I was mentioni
On Sat, 2014-05-24 at 00:34 +0200, Axb wrote:
> On 05/24/2014 12:23 AM, Martin Gregorie wrote:
> > 2 Failure of spamc/spamd to output any X-Spam headers
> > =
> > This morning SA 3.3.2 was working as expected on my SA test b
t; =
> install and enable DCC in the .pre file or ignore.
>
Thanks for the advice: I don't need DCC, so I'll simply ignore it.
> > 2 Failure of spamc/spamd to output any X-Spam headers
> > =
>
normal weekly yum upgrade. Shortly after that I got some new spam which
I ran a test on using my normal spamc/spamd test system on the SA test
box. To my surprise, no X-Spam headers at all were added to it.
--As for the rest, it is mine.
Two quick questions: Does it happen to *every* message
defined dependency? Do I need to do anything about it.
install and enable DCC in the .pre file or ignore.
2 Failure of spamc/spamd to output any X-Spam headers
=
This morning SA 3.3.2 was working as expected on my SA test box when I
amended a
it.
2 Failure of spamc/spamd to output any X-Spam headers
=
This morning SA 3.3.2 was working as expected on my SA test box when I
amended a rule to recognise a new spam variant. The test box is running
a fully patched (as of last Friday) cop
the status, score and a list of rules hit only.
> Unlike with PROCESS, the message itself is not returned, thus no X-Spam
> headers either.
>
> A closer look at the python code suggests, the filter even hardly cares
> about the rules hit -- it just cares about the score to decide whethe
s hit only.
Unlike with PROCESS, the message itself is not returned, thus no X-Spam
headers either.
A closer look at the python code suggests, the filter even hardly cares
about the rules hit -- it just cares about the score to decide whether
to pass, moderate or discard the message. That decision
m-status-header-to-ham-for-debugging/)
suggests that these headers are actually added by amavisd ... which I don't
have installed. However, the blog posting does say:
"In other words, in configurations where SpamAssasin is controlled by
amavisd-new, the X-Spam- headers are actually adde
On Tue, 20 Aug 2013, Matus UHLAR - fantomas wrote:
> On 19.08.13 19:37, Catalin Constantin wrote:
> > Is there any setting in spamassassin to make it NOT add the X-Spam
> > headers
> > for mails which are originating from trusted ips (listed in
> > trusted_network
On 19.08.13 19:37, Catalin Constantin wrote:
Is there any setting in spamassassin to make it NOT add the X-Spam headers
for mails which are originating from trusted ips (listed in
trusted_networks) ?
On Tue, 20 Aug 2013, Matus UHLAR - fantomas wrote:
Configure your mailer not to filter such
On Tue, 20 Aug 2013, Matus UHLAR - fantomas wrote:
On 19.08.13 19:37, Catalin Constantin wrote:
Is there any setting in spamassassin to make it NOT add the X-Spam headers
for mails which are originating from trusted ips (listed in
trusted_networks) ?
Configure your mailer not to filter such
On 19.08.13 19:37, Catalin Constantin wrote:
Is there any setting in spamassassin to make it NOT add the X-Spam headers
for mails which are originating from trusted ips (listed in
trusted_networks) ?
Configure your mailer not to filter such spam with SpamAssassin.
I assume they are already
On Mon, 19 Aug 2013, Catalin Constantin wrote:
Hello,
Is there any setting in spamassassin to make it NOT add the X-Spam headers
for mails which are originating from trusted ips (listed in
trusted_networks) ?
Bear in mind, trusted networks is "trusted to not forge Received:
headers&
Hello,
Is there any setting in spamassassin to make it NOT add the X-Spam headers
for mails which are originating from trusted ips (listed in
trusted_networks) ?
Thanks!
Nikita Kipriyanov wrote:
> SpamAssassin tags mail with headers X-Spam- But, what if there were
> some headers like these, as with mail that already passed someones
> SpamAssassin and has X-Spam-Score, before being recieved by my server?
Those won't matter.
> Will it remove them, replace t
Hello,
SpamAssassin tags mail with headers X-Spam- But, what if there were
some headers like these, as with mail that already passed someones
SpamAssassin and has X-Spam-Score, before being recieved by my server?
Will it remove them, replace them or simply add new ones? In the latter
cas
gt;
>> will add an "X-" to the header names.
>>
> Shouldn't this break some special things like DKIM signatures?
>
>
Comment and X-* headers should not be DKIM signed.
and anyway, there is no viable alternative, because when you use
procmail, maildrop, siev
mouss пишет:
you can "preserve" them by rewriting them before passing the message to
SA. for example, with postfix, you can use header checks:
/^(X-Spam-*)/ X-$1
will add an "X-" to the header names.
Shouldn't this break some special things like DKIM signatures?
erver?
>
> Will it remove them, replace them or simply add new ones? In the latter
> case, how do I tell headers, added by my SpamAssassin, from headers,
> that were there before my mail server?
I use procmail and have a formail recipe within my procmail.rc that prepends
"Old"
Nikita Kipriyanov a écrit :
> Hello,
>
> SpamAssassin tags mail with headers X-Spam- But, what if there were
> some headers like these, as with mail that already passed someones
> SpamAssassin and has X-Spam-Score, before being recieved by my server?
>
> Will it remove them, replace them or s
On Sun, 2008-11-30 at 16:22 +0300, Nikita Kipriyanov wrote:
> Will it remove them, replace them or simply add new ones? In the latter
> case, how do I tell headers, added by my SpamAssassin, from headers,
> that were there before my mail server?
>
SA adds a new set of headers. Look at the X-Spam-C
Hello,
SpamAssassin tags mail with headers X-Spam- But, what if there were
some headers like these, as with mail that already passed someones
SpamAssassin and has X-Spam-Score, before being recieved by my server?
Will it remove them, replace them or simply add new ones? In the latter
case, h
case as they specify.
--
View this message in context:
http://www.nabble.com/How-to-capitalise-X-Spam-headers--tp18193136p18193136.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Christopher Martin wrote:
> I have been noticing the occasional spam slipping past spam assassin
> unscathed lately but have been a bit busy to pay attention (one spam a
> day is much better than the 150 each user used to get). I paid a bit
> more attention to one the other day and noticed it had a
spamassass-milter to strip X-Spam headers
before the mails are handed to Spam Assassin for processing? If not, is
there another milter I will need to use? I guess I can put it in between
milter-regex and spamass-milter.
Any ideas?
Chris M
[EMAIL PROTECTED] wrote:
> This small edit will place x-spam headers back at the bottom of the
> original headers where god intended. I assume they changed this for a
> reason, presumably to maintain any cryptographic email signatures
> that include bits of header, so use this edit wit
This small edit will place x-spam headers back at the bottom of the original
headers where god intended. I assume they changed this for a reason,
presumably to maintain any cryptographic email signatures that include bits
of header, so use this edit with discretion.
Find the file "PerMsgStat
y for not being clearer or provide the required information.
The change is that the X-Spam headers are now at the very top of the headers
section, whereas previously they had been at the bottom of the headers. This
is not a problem, but was unexpected and I thought it to be some sort of
error. I thoug
I'm very sorry for not being clearer or provide the required information.
The change is that the X-Spam headers are now at the very top of the headers
section, whereas previously they had been at the bottom of the headers. This
is not a problem, but was unexpected and I thought it to be some
[mailto:[EMAIL PROTECTED]
Sent: Mon 12-Jun-06 14:02
To: SpamAssassin Users
Subject: Re: X-Spam-Headers at top of email
Hi Sietse,
The original poster didn't actually explain why this was a problem for
him. So I was explaining why the position of the headers had changed.
Sietse van Zanen
-Sietse
From: Anthony Peacock [mailto:[EMAIL PROTECTED]
Sent: Mon 12-Jun-06 14:02
To: SpamAssassin Users
Subject: Re: X-Spam-Headers at top of email
Hi Sietse,
The original poster didn't actually explain why this was a problem for
him. So I was explainin
ere's much more on this issue. But not sure about win2003 installations of it.
-Sietse
From: Ben Wylie [mailto:[EMAIL PROTECTED]
Sent: Mon 12-Jun-06 13:40
To: Sietse van Zanen; users@spamassassin.apache.org
Subject: RE: X-Spam-Headers at top of email
I
un-06 13:40
To: Sietse van Zanen; users@spamassassin.apache.org
Subject: RE: X-Spam-Headers at top of email
I am running SpamAssassin version 3.1.2 on windows 2003 server called via
the command line, so I think it must be something in SpamAssassin that has
changed.
Thanks
Ben
-Original Me
discussions:
http://article.gmane.org/gmane.mail.spam.spamassassin.general/72378/match=headers+location
Thanks
Ben
-Original Message-
From: Sietse van Zanen [mailto:[EMAIL PROTECTED] Sent: 12 June 2006 12:00
To: Ben Wylie; users@spamassassin.apache.org
Subject: RE: X-Spam-Headers
@spamassassin.apache.org
Subject: RE: X-Spam-Headers at top of email
It's a bug in spamass-milter 0.3.0. Upgrade to 0.3.1
-Sietse
From: Ben Wylie [mailto:[EMAIL PROTECTED]
Sent: Mon 12-Jun-06 12:56
To: users@spamassassin.apache.org
Subject: X-Spam-Headers at t
It's a bug in spamass-milter 0.3.0. Upgrade to 0.3.1
-Sietse
From: Ben Wylie [mailto:[EMAIL PROTECTED]
Sent: Mon 12-Jun-06 12:56
To: users@spamassassin.apache.org
Subject: X-Spam-Headers at top of email
For some reason when I upgraded recently, Spamass
For some reason when I upgraded recently, Spamassassin is now placing the
X-Spam headers at the top of the email rather than at the end of the headers
section as it had been. Is there an option I can set, or does anyone know
why it has suddenly changed where it puts the headers?
Thanks
Ben
On Sat, 2006-03-18 at 15:00 -0500, Theo Van Dinter wrote:
> On Sat, Mar 18, 2006 at 01:40:23PM -0500, czar wrote:
> > [17437] dbg: config: using "/var/lib/spamassassin/3.001001" for sys
> > rules pre files
> > [17437] dbg: config: using "/var/lib/spamassassin/3.001001" for default
> > rules dir
>
On Sat, Mar 18, 2006 at 01:40:23PM -0500, czar wrote:
> [17437] dbg: config: using "/var/lib/spamassassin/3.001001" for sys
> rules pre files
> [17437] dbg: config: using "/var/lib/spamassassin/3.001001" for default
> rules dir
It looks like you tried to run sa-update but it wasn't able to complet
On Sat, 18 Mar 2006, czar wrote:
hI,
[...]
> # I try the CPAN test install of Mail::SpamAssassin, this MIGHT be the
> problem?
> $ perl -MCPAN -e shell
> $ test Mail::SpamAssassin
> [...]
> t ../masses/parse-rules-for-masses line 86, line 55.
> Malformed UTF-8 character (unexpected non-continuat
to become unstable. I second that v3.1.1 was //downloaded//
and //installed// I noticed that spam was no longer detected and all of
the X-Spam headers (except X-Spam-Checker-Version: SpamAssassin 3.1.1)
went missing.
== Logs and Messages ==
# This message is pure spam, yet the result is always 0
On Tue, 6 Dec 2005, [EMAIL PROTECTED] stipulated:
> Don't bother to try to report spam with that header placement if you
> expect outfits that use DCC to respond. Placing the headers at the
> bottom that way will screw up the DCC hash they can use to identify
> the message details as "truth".
AIUI
From: "Graham Murray" <[EMAIL PROTECTED]>
"jdow" <[EMAIL PROTECTED]> writes:
Don't bother to try to report spam with that header placement if you
expect outfits that use DCC to respond. Placing the headers at the
bottom that way will screw up the DCC hash they can use to identify
the message d
"jdow" <[EMAIL PROTECTED]> writes:
> Don't bother to try to report spam with that header placement if you
> expect outfits that use DCC to respond. Placing the headers at the
> bottom that way will screw up the DCC hash they can use to identify
> the message details as "truth".
But does spamassas
From: "SickBoy" <[EMAIL PROTECTED]>
I believe the answer is to change this line in PerMsgStatus.pm:
$new_hdrs_pre .= "X-Spam-$header: $line\n";
to
$new_hdrs_post .= "X-Spam-$header: $line\n";
I haven't tested it or anything, just reading the code.
Well Theo, thank God there are peop
> I believe the answer is to change this line in PerMsgStatus.pm:
>
> $new_hdrs_pre .= "X-Spam-$header: $line\n";
>
> to
>
> $new_hdrs_post .= "X-Spam-$header: $line\n";
>
> I haven't tested it or anything, just reading the code.
Well Theo, thank God there are people like you around. ;)
T
On Tue, Dec 06, 2005 at 08:08:54PM +0100, SickBoy wrote:
> Well, I've searched thru archives before posting (vide
> http://www.nabble.com/SA-Headers-Moved-t365404.html#a1011617 as a decent
> example), and still my question HOW to do it remains unanswered.
What you're looking for is a patch, which
> I don't want to be one of those jerks who tells you to read the list
> archives for an answer, but I know this subject has been raised several
> times since the release of 3.1.0.
Well, I've searched thru archives before posting (vide
http://www.nabble.com/SA-Headers-Moved-t365404.html#a1011617
When mail is processed by SA ( spamc/spamd from procmail in this example),
it adds all the X-Spam headers at the beginning of the mail (prepend).
I don't want to be one of those jerks who tells you to read the list
archives for an answer, but I know this subject has been raised several
Hi there.
After installing the brand new SA 3.1.0 I've spotted one small thing.
When mail is processed by SA ( spamc/spamd from procmail in this example),
it adds all the X-Spam headers at the beginning of the mail (prepend).
I've submitted a bug [
http://issues.apache.org/Sp
g to vsnag.rc
Wed Nov 9 01:06:05 MST 2005 back from vsnag.rc
Wed Nov 9 01:06:05 MST 2005 * back from npd.rc
Wed Nov 9 01:06:05 MST 2005 CALLING RC.SPAM
FIRST PASS THROUGH SPAMC
***
as you can see, when things are not working, th
back from npd.rc
Wed Nov 9 01:06:05 MST 2005 CALLING RC.SPAM
FIRST PASS THROUGH SPAMC
***
as you can see, when things are not working, the mail goes to spamc but
never comes out of the process. (never gets to LOG="FIRST PASS COMPLETED&qu
&&&&&&&& NEW MESSAGE &&&&&&&&&&#
> Wed Nov 9 01:06:05 MST 2005 *** going to vsnag.rc
> Wed Nov 9 01:06:05 MST 2005 back from vsnag.rc
> Wed Nov 9 01:06:05 MST 2005 ***** back from npd.rc
> Wed Nov 9
never seem to get scanned by spamc. The X-SPAM headers
do not appear on SOME messages but it works fine for the majority. (of
course
those getting through are usually spam)... YES, I have read all of the
FAQs and posting I could find on this issue and I still cannot seem to
solve the problem. I
1 - 100 of 105 matches
Mail list logo
