FW: *SPAM*RE: Cygwin GDB crashes from cvs - solib

FW: *SPAM*RE: Cygwin GDB crashes from cvs - solib

[Dave Korn]

 
    Hiya Overseers,

  I got a note from Fabian Cenedese on the gdb list that SpamAssassin is
flagging up my posts to the list as being spammy: (quoted with permission)

On 11 April 2006 10:23, Fabian Cenedese wrote:
>
> Hi
> 
> I don't know if you're aware of this but our spam filter marks your mails
> as partly spam:
> 
> --------------
> X-spam-score: 3.2(+++)
> X-spam-report:  1.9 RATWARE_OUTLOOK_NONAME Bulk email fingerprint (Outlook
> no name) found 1.4 RATWARE_MS_HASH Bulk email fingerprint (msgid ms hash)
> found ============== -------------- 
> 
> That may not be much but other users may have more restrict rules
> and may not see your mail. Just thought I mention it.
> 
> bye  Fabi


  Looking into the matter, it turns out to be a known interaction between
ezmlm, Microsoft mail clients, and SpamAssasssin:

http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4678

  The summary is that any message that has a message-id of the format

  (12 hex digits)$(8 hex digits)$(8 hex digits)@(domain)

but does not also have an "X-Mailer" or "X-MimeOLE" header will trigger about
three of SpamAssassin's rules and get flagged up.  That's because such
messages very closely resemble spam sent by certain kinds of spamware that
attempts to mimic the headers generated by Microsoft mail clients.  The
discrepancy between having a microsoft-formatted message ID and not having one
of those two headers is what SA triggers on to detect the spamware-generated
mail, since all mails genuinely sent by microsoft's clients will have one or
other of those headers.

  This is all fine and good until you use a microsoft client to post to a
mailing list where the list manager has been configured to strip extraneous
headers from the incoming posts before forwarding them.  When I post through
the gdb list, the way it comes back to me has no such headers: (TLD's in email
addresses redacted by me)


X-Spam-Check-By: sourceware.org
From: "Dave Korn" <dave.korn@artimi.INVALID>
To: "'Daniel Jacobowitz'" <drow@false.INVALID>,
<gdb@sourceware.INVALID>
Subject: RE: Cygwin GDB crashes from cvs - solib
Date: Mon, 10 Apr 2006 18:47:34 +0100
Message-ID: <01a301c65cc6$d9023b80$a501a8c0@CAM.ARTIMI.COM>
MIME-Version: 1.0
Content-Type: text/plain; 	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <20060410172116.GA27907@nevyn.them.org>
Mailing-List: contact gdb-help@sourceware.INVALID; run by ezmlm
Precedence: bulk
List-Unsubscribe:
<mailto:gdb-unsubscribe-dk=artimi.INVALID@sourceware.INVALID>
List-Subscribe: <mailto:gdb-subscribe@sourceware.INVALID>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.INVALID>
List-Help: <mailto:gdb-help@sourceware.INVALID>,
<http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.INVALID
Delivered-To: mailing list gdb@sourceware.INVALID
Return-Path: gdb-return-24831-dk=artimi.INVALID@sourceware.INVALID

so I am inferring that the sourceware ezmlm is stripping them.

  Anyway, there's the problem and the explanation.  Can I please ask someone
to tweak the ezmlm config so that it doesn't strip X-Mailer and/or X-MimeOLE
any more?  It could stop some of those threads in the archives that keep on
acquiring "[SPAM]" tags in their subject lines as they go on.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: FW: *SPAM*RE: Cygwin GDB crashes from cvs - solib

[Frank Ch. Eigler]

[-- Attachment #1: Type: text/plain, Size: 757 bytes --]

Hi -

> [...]
> > That may not be much but other users may have more restrict rules
> > and may not see your mail. Just thought I mention it.

This part is not a realistic concern: wise people don't configure
their local email filters based on what headers *someone else's* spam
filter may have left in the messages.  The problem here may be that,
starting with this high a penalty, future messages carrying only a bit
of extra spamlike cargo may get filtered at sourceware.


>   Looking into the matter, it turns out to be a known interaction between
> ezmlm, Microsoft mail clients, and SpamAssasssin:
> http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4678
> [...]

Perhas cgf will tweak local spamassassin scores to counter this
problem.


- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: FW: *SPAM*RE: Cygwin GDB crashes from cvs - solib

[Christopher Faylor]

On Tue, Apr 11, 2006 at 08:25:31AM -0400, Frank Ch. Eigler wrote:
>Hi -
>
>> [...]
>> > That may not be much but other users may have more restrict rules
>> > and may not see your mail. Just thought I mention it.
>
>This part is not a realistic concern: wise people don't configure
>their local email filters based on what headers *someone else's* spam
>filter may have left in the messages.  The problem here may be that,
>starting with this high a penalty, future messages carrying only a bit
>of extra spamlike cargo may get filtered at sourceware.
>
>
>>   Looking into the matter, it turns out to be a known interaction between
>> ezmlm, Microsoft mail clients, and SpamAssasssin:
>> http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4678
>> [...]
>
>Perhas cgf will tweak local spamassassin scores to counter this
>problem.

Perhaps I'm missing something but AFAICT this has nothing to do with spamassasin
on sourceware.  It sounds like someone else is flagging messages from gdb
as spam because they lack an X-Mailer field.  The headers from the quoted example
did not look like they came from sourceware.

I can (and will) stop stripping the x-mailer field but it sure sounds
like a spamassasin problem to me.  There are enough clues in an ezmlm
header that it shouldn't be triggered as microsoft spam.

So, really, if anyone should be tweaking spamasssasin scores, it is either the
spamassassin team or the person who's complaining.

cgf

Re: FW: *SPAM*RE: Cygwin GDB crashes from cvs - solib

[Frank Ch. Eigler]

[-- Attachment #1: Type: text/plain, Size: 335 bytes --]

Hi -

cgf wrote:

> Perhaps I'm missing something but AFAICT this has nothing to do with
> spamassasin on sourceware.  [...]  The headers from the quoted
> example did not look like they came from sourceware. [...]

Ah, you're right.  Sourceware's spamassassin runs at message intake
time, before ezmlm's header manipulations.

- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: FW: *SPAM*RE: Cygwin GDB crashes from cvs - solib

[Christopher Faylor]

On Tue, Apr 11, 2006 at 11:19:24AM -0400, Frank Ch. Eigler wrote:
>cgf wrote:
>> Perhaps I'm missing something but AFAICT this has nothing to do with
>> spamassasin on sourceware.  [...]  The headers from the quoted
>> example did not look like they came from sourceware. [...]
>
>Ah, you're right.  Sourceware's spamassassin runs at message intake
>time, before ezmlm's header manipulations.

...in most cases...

cgf

RE: FW: *SPAM*RE: Cygwin GDB crashes from cvs - solib

[Dave Korn]

On 11 April 2006 16:13, Christopher Faylor wrote:

> Perhaps I'm missing something but AFAICT this has nothing to do with
> spamassasin on sourceware.  

  Absolutely; it has to do with ezmlm on sourceware.  The SA issue is
elsewhere, but it's a knock-on impact kind of situation.

> It sounds like someone else is flagging messages from gdb 
> as spam because they lack an X-Mailer field.  The headers from the quoted
> example did not look like they came from sourceware.

  The big block of headers from the quoted example did come from sourceware.
The X-Spam-report headers indeed did not.

> I can (and will) stop stripping the x-mailer field but it sure sounds
> like a spamassasin problem to me.  There are enough clues in an ezmlm
> header that it shouldn't be triggered as microsoft spam.

  I think you've misinterpreted this slightly.  There's no "microsoft spam"
signature/detection going on here.  SpamAsssassin is trying to discriminate
between real-ms-outlook-generated-email and
ratware-generated-email-with-badly-forged-ms-headers-to-try-and-make-it-look-r
eal.  Those headers are the only discriminant available to it.  Stripping them
at sourceware removes the discriminant.  Adding new headers does not add a new
discriminant.

  SpamAssassin could of course be taught that if it doesn't find those headers
but it does find ezmlm headers it should assume the headers used to be there,
but then it would swallow any spam that someone sent to an ezmlm list using
the particular ratware in question.  IOW, the presence of ezmlm headers cannot
actually be used to infer the former presence of now-removed
X-Mailer/X-MimeOLE headers.  So it's going to be able to make a more accurate
discrimination if those headers aren't removed.

  Anyway, you already said you're happy to leave the X-Mailer field in, and
that will completely solve the problem to everyone's satisfaction.  Thanks!
 

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....