You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Charles Gregory <cg...@hwcn.org> on 2010/05/04 21:48:48 UTC
Re: [sa] odd FPs
On Tue, 4 May 2010, Greg Troxel wrote:
> I use spamassass-milter and reject at about 8 points. Normally this is
> fine. I just got a few false positives.
> BAYES_40,DKIM_FORGED,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DOS_OUTLOOK_TO_MX,HELO_NO_DOMAIN,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_NONE,UNPARSEABLE_RELAY
Your list of 'matched' rules includes several DNS blacklists (PBL, SORBS).
Occasionally a gmail or earthlink server gets abused, and is temporarily
blacklisted. IF they dn't fix it themselves, you may have to write to the
blacklist maintainers and request removal of the IP....
- C
Re: [sa] odd FPs
Posted by Greg Troxel <gd...@ir.bbn.com>.
Charles Gregory <cg...@hwcn.org> writes:
> On Tue, 4 May 2010, Greg Troxel wrote:
>> Thanks - I did pretty much understand the tests. What I'm boggled
>> about is that they suddenly started firing, and then now suddenly do
>> not.
>
> This is perfectly consistent with the explanation I offered at the
> beginning of this thread. A legitimate Google MX was temporarily
> blacklisted. Given that it was hitting dialup Lists, I would guess
> that maybe Google was (re)assigned an IP block that was previously
> dynamic.
The problem was that the synthetic Received: line spamass-milter should
have added was not added, and thus SA thought this was direct-to-MX from
the person's computer. Adding '_' to milter_connect_macros fixed things.
Re: [sa] odd FPs
Posted by Charles Gregory <cg...@hwcn.org>.
On Tue, 4 May 2010, Greg Troxel wrote:
> Thanks - I did pretty much understand the tests. What I'm boggled about
> is that they suddenly started firing, and then now suddenly do not.
This is perfectly consistent with the explanation I offered at the
beginning of this thread. A legitimate Google MX was temporarily
blacklisted. Given that it was hitting dialup Lists, I would guess that
maybe Google was (re)assigned an IP block that was previously dynamic.
- Charles
Re: [sa] odd FPs
Posted by Greg Troxel <gd...@ir.bbn.com>.
Karsten Bräckelmann <gu...@rudersport.de> writes:
> On Tue, 2010-05-04 at 17:37 -0400, Greg Troxel wrote:
>> Karsten Bräckelmann <gu...@rudersport.de> writes:
>
>> > Translations of the rules? An Outlook user submitted directly to your MX
>> > without using his own SMTP. The SMTP HELO looks bad. The mail has been
>> > submitted from an IP, that's not supposed to do this: It's listed in
>> > PBL, the Policy Block List and DUL, a Dial-Up List.
>
> Greg, hope my explanation was insightful, and you now understand what
> they mean -- and that they all are playing in the same ball-park.
Thanks - I did pretty much understand the tests. What I'm boggled about
is that they suddenly started firing, and then now suddenly do not.
>> I don't have the headers because the mail was rejected. The users that
>
> Yeah, figured as much. But there isn't much we can do without the
> headers...
Understood - it was more "is anyone else suddenly seeing this, or is it
me"?
> Maybe add a specific rule, and have the user send a test message
> triggering that one rule, to offset the score? Get headers that way. Or,
> well, don't reject.
I added the person to the whitelist and had her retry. That message
came in at -100.9, so it was -0.9 without the whitelist points. I was
hoping to see all the same tests.
>> sent the mail are just normal people who wouldn't know how to configure
>
> Hmm, wait. PBL and SORBS DUL must not be used with deep parsing. And so
> we don't. Any chance, there's a bug with your MTA and generated Received
> headers? Or extensive trusted networks going berserk?
Everything has been stable, but Peter Alfredsen (thanks!) just pointed
me to:
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6103
which I am reading. Do people know if the consequence is occasional
unparseable received lines with this bug - certainly mostly it works.
But the line being missing can make it appear as direct-to-MX mail.
Re: [sa] odd FPs
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Tue, 2010-05-04 at 17:37 -0400, Greg Troxel wrote:
> Karsten Bräckelmann <gu...@rudersport.de> writes:
> > Translations of the rules? An Outlook user submitted directly to your MX
> > without using his own SMTP. The SMTP HELO looks bad. The mail has been
> > submitted from an IP, that's not supposed to do this: It's listed in
> > PBL, the Policy Block List and DUL, a Dial-Up List.
Greg, hope my explanation was insightful, and you now understand what
they mean -- and that they all are playing in the same ball-park.
> I don't have the headers because the mail was rejected. The users that
Yeah, figured as much. But there isn't much we can do without the
headers...
Maybe add a specific rule, and have the user send a test message
triggering that one rule, to offset the score? Get headers that way. Or,
well, don't reject.
> sent the mail are just normal people who wouldn't know how to configure
Hmm, wait. PBL and SORBS DUL must not be used with deep parsing. And so
we don't. Any chance, there's a bug with your MTA and generated Received
headers? Or extensive trusted networks going berserk?
> direct-to-MX sending. I did have the person send me the bounced mail,
> and I can see that the DSN was generated by googlemail.com
>
> headers in the bounce included:
>
> Received: by 10.231.171.83 with SMTP id g19mr1762180ibz.61.1272980385360;
> Tue, 04 May 2010 06:39:45 -0700 (PDT)
> Return-Path: <ja...@gmail.com>
> Received: from janePC (pool-x.y.z.w.bstnma.fios.verizon.net [redacted fios ip address that looks ok])
> by mx.google.com with ESMTPS id ct37sm1283572ibb.19.2010.05.04.06.39.42
> (version=TLSv1/SSLv3 cipher=RC4-MD5);
> Tue, 04 May 2010 06:39:43 -0700 (PDT)
>
> and it was received from
>
> mail-iw0-f173.google.com[209.85.223.173]
>
> so it seems that it really was google trying to send it to me.
>
> Both the google address and the fios address seem relatively clean (now)
> on blacklists.
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: [sa] odd FPs
Posted by Greg Troxel <gd...@ir.bbn.com>.
Karsten Bräckelmann <gu...@rudersport.de> writes:
> On Tue, 2010-05-04 at 15:48 -0400, Charles Gregory wrote:
>> On Tue, 4 May 2010, Greg Troxel wrote:
>> > I use spamassass-milter and reject at about 8 points. Normally this is
>> > fine. I just got a few false positives.
>
>> > DOS_OUTLOOK_TO_MX,HELO_NO_DOMAIN,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_NONE
>
> It appears the user sent the mail *directly* to your MX from his dial-up
> IP, which he sure is not supposed to. But to confirm this, we would need
> the message's full headers.
>
> Translations of the rules? An Outlook user submitted directly to your MX
> without using his own SMTP. The SMTP HELO looks bad. The mail has been
> submitted from an IP, that's not supposed to do this: It's listed in
> PBL, the Policy Block List and DUL, a Dial-Up List.
>
>> > UNPARSEABLE_RELAY
>
> Yup, need headers. Either the above is correct, or some broken Received
> header triggered all the rules.
I don't have the headers because the mail was rejected. The users that
sent the mail are just normal people who wouldn't know how to configure
direct-to-MX sending. I did have the person send me the bounced mail,
and I can see that the DSN was generated by googlemail.com
headers in the bounce included:
Received: by 10.231.171.83 with SMTP id g19mr1762180ibz.61.1272980385360;
Tue, 04 May 2010 06:39:45 -0700 (PDT)
Return-Path: <ja...@gmail.com>
Received: from janePC (pool-x.y.z.w.bstnma.fios.verizon.net [redacted fios ip address that looks ok])
by mx.google.com with ESMTPS id ct37sm1283572ibb.19.2010.05.04.06.39.42
(version=TLSv1/SSLv3 cipher=RC4-MD5);
Tue, 04 May 2010 06:39:43 -0700 (PDT)
and it was received from
mail-iw0-f173.google.com[209.85.223.173]
so it seems that it really was google trying to send it to me.
Both the google address and the fios address seem relatively clean (now)
on blacklists.
Re: [sa] odd FPs
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Tue, 2010-05-04 at 15:48 -0400, Charles Gregory wrote:
> On Tue, 4 May 2010, Greg Troxel wrote:
> > I use spamassass-milter and reject at about 8 points. Normally this is
> > fine. I just got a few false positives.
> > DOS_OUTLOOK_TO_MX,HELO_NO_DOMAIN,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_NONE
It appears the user sent the mail *directly* to your MX from his dial-up
IP, which he sure is not supposed to. But to confirm this, we would need
the message's full headers.
Translations of the rules? An Outlook user submitted directly to your MX
without using his own SMTP. The SMTP HELO looks bad. The mail has been
submitted from an IP, that's not supposed to do this: It's listed in
PBL, the Policy Block List and DUL, a Dial-Up List.
> > UNPARSEABLE_RELAY
Yup, need headers. Either the above is correct, or some broken Received
header triggered all the rules.
> Your list of 'matched' rules includes several DNS blacklists (PBL, SORBS).
> Occasionally a gmail or earthlink server gets abused, and is temporarily
> blacklisted. IF they dn't fix it themselves, you may have to write to the
> blacklist maintainers and request removal of the IP....
You'll have a really hard time getting dynamic, dial-up IP pool space
off of PBL or SORBS DUL... ;) Even more so, if you are not the owner
ISP.
Nope, de-listing is not the solution. The listings themselves are not
the problem.
guenther
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}