Paul,
Thanks for posting the patch.
This works, I just tested it. I also forwarded it to Dan Nelson
(spamass-milter). I'm not certain this is the "correct" way to fix
it, though. Will let you know if I hear more.
Thanks.
Paul Stavrides wrote:
version=3.1.1
X-Spam-Checker-V
Got this patch from a FreeBSD user yesterday. I tested it for a day and
all seems just fine.
This backs out the 3.1.1 change and reverts to the 3.1.0 behavior.
This
leaves some 3.1.1 CRLF code in Message.pm, but it now has no effect.
Normal processing of the headers fixes any trouble I was hav
Theo, Carl,
I poked around the code this morning and I think for us, this is going
to be a tougher problem to solve than I first thought.
Theo, you are correct AFAIK the calls to the library routines
responsible for wrapping lines and adding in the \t chars are confused
by the lines they are rece
On Thu, Mar 16, 2006 at 12:33:50AM -0600, David B Funk wrote:
> Silly question; would it be sufficient for the milter to just canonicalize
> the message that it passes to SA by converting CRLF to a plain LF?
> Or better, do the inverse of SA; for it to look at the first line of
> the message and if
On Wed, 15 Mar 2006, Theo Van Dinter wrote:
> The problem is caused by a specific feature that was added into
> SpamAssassin in 3.1.1 -- namely that we'll use the same line endings that the
> original message uses (LF vs CRLF). spamass-milter relied on the previous
> behavior (always use LF), whi
Theo Van Dinter wrote:
On Thu, Mar 16, 2006 at 01:19:59PM +1100, Carl Brewer wrote:
Previously, the milter could assume that folding was going to happen via
"\n\t", but now it's "\r\n\t".
Does this mean that a change is needed in spamass-milter or
spamassassin? It seems odd that this started w
On Thu, Mar 16, 2006 at 01:19:59PM +1100, Carl Brewer wrote:
> >Previously, the milter could assume that folding was going to happen via
> >"\n\t", but now it's "\r\n\t".
>
> Does this mean that a change is needed in spamass-milter or
> spamassassin? It seems odd that this started with 3.1.1 but
Theo Van Dinter wrote:
On Wed, Mar 15, 2006 at 04:31:24PM -0500, Paul Stavrides wrote:
The problem is an extra an extra "0D" in the X-Spam-Checker-Version
line, such that I see an "...0D 0D 0A 09..." by the time I look at the
headers in Windows. The line is getting munged when it is getting
wr
On Wed, Mar 15, 2006 at 04:31:24PM -0500, Paul Stavrides wrote:
> The problem is an extra an extra "0D" in the X-Spam-Checker-Version
> line, such that I see an "...0D 0D 0A 09..." by the time I look at the
> headers in Windows. The line is getting munged when it is getting
> wrapped.
Interestin
Paul Stavrides wrote:
Felicity,
Thanks for the tips.
We too are having the problem of headers creeping into out received
e-mail. Difference here is that our setup is a Linux front end to
MSExchange. So we run SA site-wide and use Milter to keep the crap out
of Exchange. Works like
On Thu, Mar 16, 2006 at 08:29:29AM +1100, Carl Brewer wrote:
> >Is this reproducable with spamassassin or spamc/spamd from a commandline?
>
> I'm not sure, how would I test it?
Something similar to "spamassassin < file_with_message" or
"spamc < file_with_message" if you want to test spamd.
--
Title: Header1
Felicity,
Thanks for the tips.
We too are having the problem of headers creeping into out
received e-mail. Difference here is that our setup is a Linux front end
to MSExchange. So we run SA site-wide and use Milter to keep the crap out
of Exchange. Works like a c
Theo Van Dinter wrote:
On Wed, Mar 15, 2006 at 06:47:58PM +1100, Carl Brewer wrote:
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00
autolearn=ham version=3.1.1
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on
rollcage2.bl.echidna.id.au
It looks li
On Wed, Mar 15, 2006 at 06:47:58PM +1100, Carl Brewer wrote:
> X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00
>
> autolearn=ham version=3.1.1
> X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on
> rollcage2.bl.echidna.id.au
>
> It looks like sometime
> Since I upgraded, I'm seeing bits of the X-Spam-Header message
> in my mail bodies, like this :
The latest version changed things to make life on Windows systems better.
Instead of always using a \n for a line ending, it looks at the kind of line
ending it got on the first line of the input file
Hello,
I just upgraded to 3.1.1 on a NetBSD box via pkgsrc, and
am using sendmail 8.13.5 with spamass-milter 0.3.0, and sendmail
is configured to use cyrus imapd as its local delivery agent.
Since I upgraded, I'm seeing bits of the X-Spam-Header message
in my mail bodies, like this :
To: Carl
16 matches
Mail list logo
