spamass-milt-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

subject or content-type deleted instead of rewritten -- fixed


From: Niki Waibel
Subject: subject or content-type deleted instead of rewritten -- fixed
Date: Thu, 09 Jan 2003 22:41:45 +0100 (MET)

okay - here comes the fix and a description
where/why the bug/error occurs.

if you have a look to the function 
        string retrieve_field(const string& header, const string& field)
the first code line searches for the header field.
but the coders prepend the header field name by a '\n'.
this is okay to match only fields which start at the beginning of a line.
but if such a field is in the first line of a string then you'll never
ever match it.

there are 2 solutions for this problem.
you can remove the prepending of the '\n' of the field.
this is bad, because then you would also match fields which are not at
the beginning of a line.
the other solution is to add a '\n' at the very beginning of each mail.
this is what i did.

possible that the modification i did has another sideeffect.
i hope that you :) (whoever this is) have a look at it.
this is the patch for 0.1.3a:
===
diff -u -N -r spamass-milter-0.1.3a.orig/spamass-milter.cpp 
spamass-milter-0.1.3a/spamass-milter.cpp
--- spamass-milter-0.1.3a.orig/spamass-milter.cpp       Tue Dec 31 21:03:13 2002
+++ spamass-milter-0.1.3a/spamass-milter.cpp    Thu Jan  9 22:32:56 2003
@@ -890,6 +890,10 @@
   if (!running || error)
     return;
 
+  // prepend each mail by '\n' to make a match of the first header field
+  // possible.
+  mail = string("\n");
+
   // keep reading from input pipe until it is empty
   empty_and_close_pipe();
   
===

i'd love to hear comments about this topic and to see a clean fix in
0.1.3b or 0.1.4.
pls reply to address@hidden also.

happy coding, niki w. waibel



On 09-Jan-2003 Ronan Waide wrote:
> On January 9, address@hidden said:
>> the bad thing happens in:
>>         int assassinate(SMFICTX* ctx, SpamAssassin* assassin)
>> if you look at the following code it happens after the first
>> ``update_or_insert()''.
> 
> Okay, can you rerun that with debug level set to 5, since that'll
> trace execution of update_or_insert(). There's also some
> curious-looking code in retrieve_field.
> 
> Cheers,
> Waider.
> -- 
> address@hidden / Yes, it /is/ very personal of me.
> 
> "My evil is unjust and cruel in the smallest and most annoying way possible."
>                                                   - Catherine Clarke

-- 
niki w. waibel - system administrator @ newlogic technologies ag




reply via email to

[Prev in Thread] Current Thread [Next in Thread]