Re: Abuse of SARE whitelist

[Justin Mason <jm...@jmason.org>]

It's worth checking this; that rule should fire only if the
mail really *did* come from Vonage.  I suspect a bug in how your
mailserver's Received headers are parsed.

Could you post:

  - a sample of a spam that passed this, with all headers
  - output of "spamassassin -D -L -t < spam", the lines with
    'received-header' and 'metadata' at least

--j.

Paul Boven writes:
> Hi everyone,
> 
> Paul Boven wrote:
> 
> > One of my users just spotted a FN that had managed to slip trough. 
> > They're abusing 70_sare_whitelist.cf, specifically:
> > 
> > whitelist_from_rcvd   *@vm.vonage.com                 vonage.com
> >       # Vonage voice mail notification
> 
> I'm now catching these on several mailservers that we run, so I'm 
> assuming this is getting abused quite a bit. And it's very effective 
> because the default score for whitelist_from_rcvd is -100. What worries 
> me is that whitelist_from_rcvd gets triggered, even though the mail 
> obviously is forged, unless vonage sends their mails from China.
> 
> So my question is, still, why does the email (see my previous posting 
> for headers) hit the whiltelist_from_rcvd? Is my trusted networks 
> confused? Does it get hit because the mail was processed by the 
> (trusted) backup-MX first?
> 
> Regards, Paul Boven.

Re: Abuse of SARE whitelist

[Theo Van Dinter <fe...@apache.org>]

On Thu, Jul 13, 2006 at 11:21:09AM +0100, Justin Mason wrote:
> ok -- there's the bug ;)  SpamAssassin is misinterpreting your
> MX's Received headers.
[...]
> Could you open a bug on the SpamAssassin bugzilla about that?  Attach
> the debug output and sample again (it can be tricky to find posts to
> the mailing list when fixing the bug later otherwise).  cheers,

For anyone else following this, the bug was already fixed in 3.1.2 via
bug 4813.

-- 
Randomly Generated Tagline:
"Is blue supposed to be soothing when I lose my data?"      - Dave DeMaagd

Re: Abuse of SARE whitelist

[Paul Boven <p....@chello.nl>]

Hi Justin, everyone,

Justin Mason wrote:

> It's worth checking this; that rule should fire only if the
> mail really *did* come from Vonage.  I suspect a bug in how your
> mailserver's Received headers are parsed.
> 
> Could you post:
> 
>   - a sample of a spam that passed this, with all headers
>   - output of "spamassassin -D -L -t < spam", the lines with
>     'received-header' and 'metadata' at least

Sure, see attachements for the the original and the output.

debug: received-header: parsed as [ ip=127.0.0.1 rdns=localhost 
helo=localhost by=a48046.upc-a.chello.nl ident= envfrom= intl=0 
id=k6D6gfSl010610 auth= ]
debug: found fetchmail marker, restarting parse
debug: received-header: parsed as [ ip=220.166.39.177 rdns=vm.vonage.com 
helo=vm.vonage.com by=amsfep14-int.chello.nl ident= envfrom= intl=0 
id=20060713063346.DQLW12552.amsfep14-int.chello.nl@vm.vonage.com auth= ]
debug: received-header: relay 220.166.39.177 trusted? no internal? no
debug: metadata: X-Spam-Relays-Trusted:
debug: metadata: X-Spam-Relays-Untrusted: [ ip=220.166.39.177 
rdns=vm.vonage.com helo=vm.vonage.com by=amsfep14-int.chello.nl ident= 
envfrom= intl=0 
id=20060713063346.DQLW12552.amsfep14-int.chello.nl@vm.vonage.com auth= ]
debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x9d2fc4) 
implements 'parsed_metadata'
debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x9d2fc4) 
implements 'parsed_metadata'
debug: is DNS available? 0

Just to clarify: This also happens on mailservers that are directly 
listening on port 25, not trough fetchmail. 'DNS available 0' is a 
surprise to me, because I've hardcoded it to 'yes' in local.cf. The 
server that I pop the email from is listed as 'trusted' in my local.cf.

Regards, Paul Boven.