On Tuesday October 9 2007 20:19:36 Loren Wilton wrote: > > To me it looks like a misfeature. > > I think I would agree that it may be a misfeature in the case of this > specific header. In general though it may not be. Consider the case of > two separate Subject: headers, often with completely different subjects. > There was a time that was a quite decent spam sign (I haven't checked > recently to see if it still is).
I wasn't suggesting discarding repeated header fields. But a rule like (a test for an older virus storm): header L_LANIECA_S1 Subject =~ /^(girls|love|screensaver)$/ could be tried individually with each Subject header field body, instead of with both field bodies concatenated - without noticable performance degradation. As it goes now, the above rule can be easily circumvented by adding a second Subject line, and the ^ or $ would not match any more. It is easy to forget putting the /m flag in rules. An incident that made me aware of the problem is when I tried to detect mail coming with a particular X-*... line - which misteriously failed every now and then, until I realized it fails when there are two such lines in a header. In my case it was a pure security incident (I won't go into details). Justin Mason wrote: > Yeah -- it's long-standing, but surprising, behaviour. > it should probably be documented in the Conf manpage somewhere... I think it should be changed for 3.3.0 (and a change well documented). I would think a change would fix more rules that are unknowingly broken now, than rules that would possibly be affected in undesirable way. Mark
