You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Philip Prindeville <ph...@redfish-solutions.com> on 2008/02/17 03:44:55 UTC
Clearly bogus false positives -- on "abuse" contact point, no less
Hmmm. I think we need a BL for reporting ISP's that are clueless as to
run filtering on their "abuse" mailbox (or the mailbox that's listed for
their ARIN/RIPE AbuseEmail attributes).
Anyway, I have no idea why I'm seeing some of these scores. URL matches
when there aren't even URL's in my message?
A 2.6 score on BAYES_00? URIBL_JP_SURBL and URIBL_OB_SURBL? And what
the heck is DNS_FROM_OPENWHOIS???
TVD_STOCK1? There's no mention of stock anywhere in the message. Why am I seeing all of these bogus matches?
I looked on the wiki for some of these, but couldn't find descriptions.
What should I do? Just block their domain? I don't want to deal with their misconfiguration issues.
-Philip
========
Received: from localhost (localhost)
by mail.redfish-solutions.com (8.14.1/8.14.1) id m1H2M5XP027602;
Sat, 16 Feb 2008 19:22:05 -0700
Date: Sat, 16 Feb 2008 19:22:05 -0700
From: Mail Delivery Subsystem <MA...@mail.redfish-solutions.com>
Message-Id: <20...@mail.redfish-solutions.com>
To: <ab...@redfish-solutions.com>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="m1H2M5XP027602.1203214925/mail.redfish-solutions.com"
Subject: Returned mail: see transcript for details
Auto-Submitted: auto-generated (failure)
This is a MIME-encapsulated message
--m1H2M5XP027602.1203214925/mail.redfish-solutions.com
The original message was received at Sat, 16 Feb 2008 19:22:01 -0700
from pool-71-112-32-245.sttlwa.dsl-w.verizon.net [71.112.32.245]
----- The following addresses had permanent fatal errors -----
<cu...@ukdomains.com>
(reason: 550-"This email has been automatically tagged as spam)
<po...@ukdomains.com>
(reason: 550-"This email has been automatically tagged as spam)
----- Transcript of session follows -----
... while talking to alpha.inbound.mercury.spaceservers.net.:
>>> DATA
<<< 550-"This email has been automatically tagged as spam
<<< 550-Spam detection software, operated by UKDomains limited, has
<<< 550-identified this incoming email as possible spam.
<<< 550-contact postmaster@ukdomains.com for details and error reports.
<<< 550-pts rule name description
<<< 550----- ---------------------- --------------------------------------------------
<<< 550-1.1 DNS_FROM_OPENWHOIS RBL: Envelope sender listed in
<<< 550-bl.open-whois.org.
<<< 550--0.0 SPF_PASS SPF: sender matches SPF record
<<< 550--2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1%
<<< 550-[score: 0.0000]
<<< 550-1.5 URIBL_JP_SURBL Contains an URL listed in the JP SURBL
<<< 550-blocklist
<<< 550-[URIs: chalturs.com]
<<< 550-1.5 URIBL_OB_SURBL Contains an URL listed in the OB SURBL
<<< 550-blocklist
<<< 550-[URIs: chalturs.com]
<<< 550-0.5 WHOIS_DMNBYPROXY Contains URL registered to Domains by Proxy
<<< 550-[URIs: redfish-solutions.com]
<<< 550 3.4 AWL AWL: From: address is in the auto white-list"
554 5.0.0 Service unavailable
--m1H2M5XP027602.1203214925/mail.redfish-solutions.com
Content-Type: message/delivery-status
Reporting-MTA: dns; mail.redfish-solutions.com
Received-From-MTA: DNS; pool-71-112-32-245.sttlwa.dsl-w.verizon.net
Arrival-Date: Sat, 16 Feb 2008 19:22:01 -0700
Final-Recipient: RFC822; customercare@ukdomains.com
Action: failed
Status: 5.2.0
Remote-MTA: DNS; alpha.inbound.mercury.spaceservers.net
Diagnostic-Code: SMTP; 550-"This email has been automatically tagged as spam
Last-Attempt-Date: Sat, 16 Feb 2008 19:22:05 -0700
Final-Recipient: RFC822; postmaster@ukdomains.com
Action: failed
Status: 5.2.0
Remote-MTA: DNS; alpha.inbound.mercury.spaceservers.net
Diagnostic-Code: SMTP; 550-"This email has been automatically tagged as spam
Last-Attempt-Date: Sat, 16 Feb 2008 19:22:05 -0700
--m1H2M5XP027602.1203214925/mail.redfish-solutions.com
Content-Type: message/rfc822
Return-Path: <ab...@redfish-solutions.com>
Received: from [192.168.10.120] (pool-71-112-32-245.sttlwa.dsl-w.verizon.net [71.112.32.245])
(authenticated bits=0)
by mail.redfish-solutions.com (8.14.1/8.14.1) with ESMTP id m1H2M0XQ027599
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Sat, 16 Feb 2008 19:22:01 -0700
Message-ID: <47...@redfish-solutions.com>
Date: Sat, 16 Feb 2008 18:21:27 -0800
From: Abuse Department <ab...@redfish-solutions.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: customercare@ukdomains.com
CC: postmaster@ukdomains.com
Subject: Of course it's spam: it's an "abuse" mailbox
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.63 on 192.168.1.3
Of course it's spam. It's a copy of an offending message (that
originated from *your* site) being reported back to you, and do you
"abuse" mailbox.
If it weren't spam, there'd hardly be a point in reporting it now, would
there?
What other brilliant deductions are to follow? That there are "a lot of
sick people in a hospital"?
Get a clue. Better yet, if you were as good at detecting *outbound*
spam coming from your site as you are incoming spam, we wouldn't be
having this discussion now, would we?
The original message was received at Sat, 16 Feb 2008 19:15:17 -0700
from pool-71-112-32-245.sttlwa.dsl-w.verizon.net [71.112.32.245]
----- The following addresses had permanent fatal errors -----
<cu...@ukdomains.com>
(reason: 550-"This email has been automatically tagged as spam)
----- Transcript of session follows -----
... while talking to alpha.inbound.mercury.spaceservers.net.:
>>> >>> DATA
>>>
<<< 550-"This email has been automatically tagged as spam
<<< 550-Spam detection software, operated by UKDomains limited, has
<<< 550-identified this incoming email as possible spam.
<<< 550-contact postmaster@ukdomains.com for details and error reports.
<<< 550-pts rule name description
<<< 550----- ---------------------- --------------------------------------------------
<<< 550-1.1 DNS_FROM_OPENWHOIS RBL: Envelope sender listed in
<<< 550-bl.open-whois.org.
<<< 550--0.0 SPF_PASS SPF: sender matches SPF record
<<< 550-3.1 UNCLAIMED_MONEY BODY: People just leave money laying around
<<< 550-3.8 TVD_STOCK1 BODY: TVD_STOCK1
<<< 550--2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1%
<<< 550-[score: 0.0000]
<<< 550-1.5 URIBL_JP_SURBL Contains an URL listed in the JP SURBL
<<< 550-blocklist
<<< 550-[URIs: chalturs.com]
<<< 550-1.5 URIBL_OB_SURBL Contains an URL listed in the OB SURBL
<<< 550-blocklist
<<< 550-[URIs: chalturs.com]
<<< 550-0.5 WHOIS_DMNBYPROXY Contains URL registered to Domains by Proxy
<<< 550 [URIs: redfish-solutions.com]"
554 5.0.0 Service unavailable
--m1H2M5XP027602.1203214925/mail.redfish-solutions.com--
Re: Clearly bogus false positives -- on "abuse" contact point, no
less
Posted by Kris Deugau <kd...@vianet.ca>.
Philip Prindeville wrote:
> I'd rather suffer a few broken applications, or in this case, a user
> having to cut a domain name out of an email and paste it into a web
> browser and not be able to simply "click through" the message body, if
> it helps maintain the clear distinction between well-formed messages and
> gray area ham/spam.
When did you last work an ISP helpdesk?
Users will go to great lengths to avoid technical operations like cut
and paste. <g> *sigh*
-kgd
Re: Clearly bogus false positives -- on "abuse" contact point, no
less
Posted by Philip Prindeville <ph...@redfish-solutions.com>.
Matt Kettler wrote:
> Philip Prindeville wrote:
>> Matt Kettler wrote:
>>> Philip Prindeville wrote:
>>>> Matt Kettler wrote:
>>>>> Philip Prindeville wrote:
>>>>>>>
>>>>>>
>>>>>> Depends on whether you equate bare domains with URL's, I suppose.
>>>>> If MUA's equate them with URLs, spammers will use this, and
>>>>> SpamAssassin will use it.
>>>>
>>>> There is only so much braindeath in UA's that you can bend the
>>>> rules for. Clearly, this involves breaking them.
>>> Erm.. What rule does this actually break? Is there a rule in an RFC
>>> somewhere specifying you MUST not interpret bare domains as URIs in
>>> text emails?
>>
>> There is an RFC that defines what a URL looks like. A bare domain
>> doesn't cut it.
> Yes, but there's nowhere that says you can't interpret any text you
> want as a URL.
>
> RFCs in general are interpreted with "be strict about what you
> generate, and liberal with what you accept". URLizing text segments
> fits with that spirit, and it does not violate the letter of any RFC
> I'm aware of.
There are lots of caveats to this rule, and security is certainly one
region where you'll find being "liberal what you accept" to be antithetical.
>
> If you can prove otherwise, please do so.
>
>> You want to forbid bare domains in email? Go ahead. You can forbid
>> anything you like.
>>
>> But don't call it a test for URL's, since it's clearly not.
> Well, they don't.. they call it a test for URIs, which is actually
> slightly different, but not really to the point here.
>
> However, in general, it is intended to be a "test for anything most
> MUA's will interpret as a URI".
Ok, conceded. So the fix is to stop the UA's broken behavior, so we
don't have to copy it.
>
>>>
>>> Besides, when this "braindeath" is more the norm than the exception,
>>> it's a de facto standard. Particularly in the absence of any rules
>>> against it.
>>
>> Yeah, I'll talk to the Outlook folks, and file a bug against
>> Thunderbird... (I think the latter only does it to be compatible with
>> the former...)
> I'd venture to guess neither started it. Eudora predates both products
> by quite an extensive period of time. It could have originated there,
> or in Netscape mail.
>
> Sorry, but I highly doubt you can blame this on microsoftism, nor do I
> think it's any kind of wild incorrectness as you so strongly
> postulate. This has been a very standard feature in email for a very
> long time. It's not a recent development.
Long standing hardly equates to "correct". If that were the case,
day-one bugs would never get fixed. :-)
>
> It's also a feature that is quite important to accuracy in
> spamassassin. Spammers regularly take advantage of MUA's urlizing
> text. Regularly.. Every day. Adding the ability to detect those
> domains increases SA's hit rate for spam, and that's a good thing.
> Yes, it causes SA to trigger on spam reports, but it generally will do
> that for other parts of spam messages anyway.
>
> Let's face it, your problem isn't with SA detecting a spam domain,
> it's with some idiot filter/rejecting their abuse box.
>
Not at all.
A lot of spam uses constructs that aren't well-formed according to
standards. Like broken "Date:" lines.
I'm happy to reject email that can't get something simple as a Date:
line correct.
If Kintata (or whatever it's called) emails get bounced, I'm fine with
that. Maybe it will light a fire beneath them to get it fixed. They're
in the minority anyway.
Same applies to interpreting URI's.
I'd rather suffer a few broken applications, or in this case, a user
having to cut a domain name out of an email and paste it into a web
browser and not be able to simply "click through" the message body, if
it helps maintain the clear distinction between well-formed messages and
gray area ham/spam.
-Philip
Re: Clearly bogus false positives -- on "abuse" contact point, no less
Posted by Matt Kettler <mk...@verizon.net>.
Philip Prindeville wrote:
> Matt Kettler wrote:
>> Philip Prindeville wrote:
>>> Matt Kettler wrote:
>>>> Philip Prindeville wrote:
>>>>>>
>>>>>
>>>>> Depends on whether you equate bare domains with URL's, I suppose.
>>>> If MUA's equate them with URLs, spammers will use this, and
>>>> SpamAssassin will use it.
>>>
>>> There is only so much braindeath in UA's that you can bend the rules
>>> for. Clearly, this involves breaking them.
>> Erm.. What rule does this actually break? Is there a rule in an RFC
>> somewhere specifying you MUST not interpret bare domains as URIs in
>> text emails?
>
> There is an RFC that defines what a URL looks like. A bare domain
> doesn't cut it.
Yes, but there's nowhere that says you can't interpret any text you want
as a URL.
RFCs in general are interpreted with "be strict about what you generate,
and liberal with what you accept". URLizing text segments fits with that
spirit, and it does not violate the letter of any RFC I'm aware of.
If you can prove otherwise, please do so.
> You want to forbid bare domains in email? Go ahead. You can forbid
> anything you like.
>
> But don't call it a test for URL's, since it's clearly not.
Well, they don't.. they call it a test for URIs, which is actually
slightly different, but not really to the point here.
However, in general, it is intended to be a "test for anything most
MUA's will interpret as a URI".
>>
>> Besides, when this "braindeath" is more the norm than the exception,
>> it's a de facto standard. Particularly in the absence of any rules
>> against it.
>
> Yeah, I'll talk to the Outlook folks, and file a bug against
> Thunderbird... (I think the latter only does it to be compatible with
> the former...)
I'd venture to guess neither started it. Eudora predates both products
by quite an extensive period of time. It could have originated there, or
in Netscape mail.
Sorry, but I highly doubt you can blame this on microsoftism, nor do I
think it's any kind of wild incorrectness as you so strongly postulate.
This has been a very standard feature in email for a very long time.
It's not a recent development.
It's also a feature that is quite important to accuracy in spamassassin.
Spammers regularly take advantage of MUA's urlizing text. Regularly..
Every day. Adding the ability to detect those domains increases SA's hit
rate for spam, and that's a good thing. Yes, it causes SA to trigger on
spam reports, but it generally will do that for other parts of spam
messages anyway.
Let's face it, your problem isn't with SA detecting a spam domain, it's
with some idiot filter/rejecting their abuse box.
Re: Clearly bogus false positives -- on "abuse" contact point, no
less
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Mon, 2008-02-18 at 09:51 -0800, Philip Prindeville wrote:
> Daryl C. W. O'Shea wrote:
> > Philip Prindeville wrote:
> >> Yeah, I'll talk to the Outlook folks, and file a bug against
> >> Thunderbird... (I think the latter only does it to be compatible with
> >> the former...)
> >
> > Yeah, good luck with that.
> >
> > Do you really have an issue with SA, or is it just that you're pissed
> > off that somebody rejected spam sent to their abuse account and you're
> > taking your frustration out on how SA detected that spam?
>
> I don't like going down the slippery slope of "Well, it's not really an
> URI, but Outlook treats it like one, so we will too." (substitute URI
> and Outlook with an number of alternate permutations here).
>
> Half of the security holes that viri, etc. exploit probably exist
> because of woolly-minded thinking and bent definitions like that in the
> first place. So what could be a well-intentioned attempt to make things
> better just ends up making them worse.
While this might be true, it is entirely irrelevant.
SA is a security and privacy tool. The users are exposed to the threat
by their MUAs, and SA is here to protect them.
There is no point in arguing over MUA behavior. Whatever they do that
exposes the users to a risk, SA needs to do, too.
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; }}}
Re: Clearly bogus false positives -- on "abuse" contact point, no
less
Posted by Philip Prindeville <ph...@redfish-solutions.com>.
Daryl C. W. O'Shea wrote:
> Philip Prindeville wrote:
>
>> There is an RFC that defines what a URL looks like. A bare domain
>> doesn't cut it.
>>
>> You want to forbid bare domains in email? Go ahead. You can forbid
>> anything you like.
>>
>
> I don't, and I doubt Matt wants to either.
>
>
>> But don't call it a test for URL's, since it's clearly not.
>>
>
> FWIW, you're the only one who's been calling it a URL. The SA headers
> say it's a URI, which isn't accurate either, unless of course you
> consider SURBL to be a Schemeless URI Realtime Blocklist.
>
>
>>> Besides, when this "braindeath" is more the norm than the exception,
>>> it's a de facto standard. Particularly in the absence of any rules
>>> against it.
>>>
>> Yeah, I'll talk to the Outlook folks, and file a bug against
>> Thunderbird... (I think the latter only does it to be compatible with
>> the former...)
>>
>
> Yeah, good luck with that.
>
> Do you really have an issue with SA, or is it just that you're pissed
> off that somebody rejected spam sent to their abuse account and you're
> taking your frustration out on how SA detected that spam?
>
> Daryl
>
I don't like going down the slippery slope of "Well, it's not really an
URI, but Outlook treats it like one, so we will too." (substitute URI
and Outlook with an number of alternate permutations here).
Half of the security holes that viri, etc. exploit probably exist
because of woolly-minded thinking and bent definitions like that in the
first place. So what could be a well-intentioned attempt to make things
better just ends up making them worse.
-Philip
Re: Clearly bogus false positives -- on "abuse" contact point, no
less
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
Philip Prindeville wrote:
> There is an RFC that defines what a URL looks like. A bare domain
> doesn't cut it.
>
> You want to forbid bare domains in email? Go ahead. You can forbid
> anything you like.
I don't, and I doubt Matt wants to either.
> But don't call it a test for URL's, since it's clearly not.
FWIW, you're the only one who's been calling it a URL. The SA headers
say it's a URI, which isn't accurate either, unless of course you
consider SURBL to be a Schemeless URI Realtime Blocklist.
>> Besides, when this "braindeath" is more the norm than the exception,
>> it's a de facto standard. Particularly in the absence of any rules
>> against it.
>
> Yeah, I'll talk to the Outlook folks, and file a bug against
> Thunderbird... (I think the latter only does it to be compatible with
> the former...)
Yeah, good luck with that.
Do you really have an issue with SA, or is it just that you're pissed
off that somebody rejected spam sent to their abuse account and you're
taking your frustration out on how SA detected that spam?
Daryl
Re: Clearly bogus false positives -- on "abuse" contact point, no
less
Posted by Philip Prindeville <ph...@redfish-solutions.com>.
Matt Kettler wrote:
> Philip Prindeville wrote:
>> Matt Kettler wrote:
>>> Philip Prindeville wrote:
>>>>>
>>>>
>>>> Depends on whether you equate bare domains with URL's, I suppose.
>>> If MUA's equate them with URLs, spammers will use this, and
>>> SpamAssassin will use it.
>>
>> There is only so much braindeath in UA's that you can bend the rules
>> for. Clearly, this involves breaking them.
> Erm.. What rule does this actually break? Is there a rule in an RFC
> somewhere specifying you MUST not interpret bare domains as URIs in
> text emails?
There is an RFC that defines what a URL looks like. A bare domain
doesn't cut it.
You want to forbid bare domains in email? Go ahead. You can forbid
anything you like.
But don't call it a test for URL's, since it's clearly not.
>
> Besides, when this "braindeath" is more the norm than the exception,
> it's a de facto standard. Particularly in the absence of any rules
> against it.
Yeah, I'll talk to the Outlook folks, and file a bug against
Thunderbird... (I think the latter only does it to be compatible with
the former...)
>
> *EVERY* graphical MUA I've used in the past 10 years does this.
> Thunderbird, Outlook, Groupwise, Eudora, they all do it. I'm sure
> there are MUAs that don't, but there's an awful lot that do. Most
> webmails seem to do it too. Outlook web access, Comcast and Yahoo all
> do, but I'll concede that Verizon's webmail doesn't.
>
Re: Clearly bogus false positives -- on "abuse" contact point, no less
Posted by Matt Kettler <mk...@verizon.net>.
Philip Prindeville wrote:
> Matt Kettler wrote:
>> Philip Prindeville wrote:
>>>>
>>>
>>> Depends on whether you equate bare domains with URL's, I suppose.
>> If MUA's equate them with URLs, spammers will use this, and
>> SpamAssassin will use it.
>
> There is only so much braindeath in UA's that you can bend the rules
> for. Clearly, this involves breaking them.
Erm.. What rule does this actually break? Is there a rule in an RFC
somewhere specifying you MUST not interpret bare domains as URIs in text
emails?
Besides, when this "braindeath" is more the norm than the exception,
it's a de facto standard. Particularly in the absence of any rules
against it.
*EVERY* graphical MUA I've used in the past 10 years does this.
Thunderbird, Outlook, Groupwise, Eudora, they all do it. I'm sure there
are MUAs that don't, but there's an awful lot that do. Most webmails
seem to do it too. Outlook web access, Comcast and Yahoo all do, but
I'll concede that Verizon's webmail doesn't.
Re: Clearly bogus false positives -- on "abuse" contact point, no
less
Posted by Philip Prindeville <ph...@redfish-solutions.com>.
Matt Kettler wrote:
> Philip Prindeville wrote:
>> Karsten Bräckelmann wrote:
>>> Please, do not paste a gigantic blob of multipart MIME messages. Put it
>>> up somewhere, raw, and simply provide a link.
>>>
>>>
>>> On Sat, 2008-02-16 at 18:44 -0800, Philip Prindeville wrote:
>>>
>>>> Anyway, I have no idea why I'm seeing some of these scores. URL
>>>> matches when there aren't even URL's in my message?
>>>>
>>>
>>> There are. Self-inflicted. The ones in square brackets with the leading
>>> 550 code, which you seem to keep sending back and forth. :)
>>>
>>
>> And just *mentioning* the domain name, without any sort of valid URL
>> (ftp: or http: or anything of the sort) is going to match it as a
>> URL? That's highly bogus.
>>
>> A domain name alone does not a URL make.
> You tell that to most windows-based clients, which will automatically
> make clickalble URLs out of things like www.google.com in text sections.
>
> <snip>
>>
>>> Oh, and DNS_FROM_OPENWHOIS probably is http://open-whois.org/, which
>>> gives you a hint about what it actually is. The hit itself pretty much
>>> mentions this...
>>>
>>
>> Yeah, I read this. And I don't get that either.
>>
>> How does having your domain be anonymous (for whatever reason...
>> maybe you're a small company operating below the radar) make your
>> email any more likely to be spam????
> Decidedly so. The people with the strongest reason to hide their
> contact information are the spammers, and other shady businesses.
>
> That's not to say they're aren't some legitimate folks that use this
> kind of anonymization. However, the "domains by proxy" model is a
> questionable practice, as it violates the spirit of the whois
> requirements. Also, many of them violate the letter of the
> requirements, such as the phone issue noted on the open-whois main
> page. (ie: anyone registered using securewhois is not correctly
> reigstered, per ICANN requirements for whois)
Well, what's ironic here is this:
I go to the open-whois web-site, and read their blurb:
"What do you have against privacy?
"In a word: nothing. This is not about privacy, but about
accountability. The Internet is built upon cooperation and
accountability, anything which undermines accountability is a bad thing.
The usability of the WHOIS database is seriously undermined by anonymous
domains."
Ah... But filtering your spam reports so no one can ever report spam to
you... that's a lot more accountable, clearly. :-)
>
>>
>>>> TVD_STOCK1? There's no mention of stock anywhere in the message.
>>>>
>>>
> Not sure, you migth want to try running it with debugging on.
> The debug message from the code would be:
>
> dbg("eval: stock info hit: $1");
>
> That should tell you what exact substring matched the stock info code.
>
>>> From a quick glimpse of the code, it appears to identify common words
>>> used in stock (as in stock exchange, pump-n-dump penny stocks) spam. It
>>> does not search for the word "stock". Just as pretty much no rule in SA
>>> ever searches for single words only...
>>>
>>
>> Again, I didn't see anything that should legitimately be causing this
>> rule to fire, and certainly not with such a high score for such an
>> unreliable rule.
>
>>
>>
>>>> Why am I seeing all of these bogus matches?
>>>>
>>>
>>> From what I can tell, and what you sent us, they don't appear to be
>>> bogus.
>>>
>>
>> Depends on whether you equate bare domains with URL's, I suppose.
> If MUA's equate them with URLs, spammers will use this, and
> SpamAssassin will use it.
There is only so much braindeath in UA's that you can bend the rules
for. Clearly, this involves breaking them.
>
>>
>>>> I looked on the wiki for some of these, but couldn't find
>>>> descriptions.
>>>>
>>>> What should I do? Just block their domain? I don't want to deal with
>>>> their misconfiguration issues.
>>>>
>>>
>>> Apparently you already exchanged messages? Try not sending the
>>> offensive
>>> mail in question. Put it up somewhere as reference, if need be. Hmm,
>>> sounds familiar... ;)
>>>
>>> guenther
>>>
>>>
>>>
>>
>> No, I sent them back the offending email, initially. Which they
>> marked as spam (bloody brilliant, of course it's spam, otherwise I
>> wouldn't be bothering to report it.... what else do they expect to
>> come to their "Abuse" mailbox, anyway???).
>>
>> So I sent back the SA scores back to them, and that's the part that I
>> pasted previously.
>>
>> How do you report Spam to such a site that's going to block your Spam
>> reports for being... well, Spam!
> Well, it's stupid, and probably a RFC violation to perform such
> filtering on your abuse box. So, I'm not saying the domain in question
> isn't behaving foolishly. You might want to point this out to them,
> and suggest they whitelist their abuse address. At the very least, ask
> them if they have an alternate reporting address that isn't filtered.
>
I'll give it another try. If not, their CIDR range and domain name will
go into my blacklist. I don't want to open myself up to them if I can't
reasonably expect them to respond to spam issues when/if they occur (again).
-Philip
Re: Clearly bogus false positives -- on "abuse" contact point, no less
Posted by Matt Kettler <mk...@verizon.net>.
Philip Prindeville wrote:
> Karsten Bräckelmann wrote:
>> Please, do not paste a gigantic blob of multipart MIME messages. Put it
>> up somewhere, raw, and simply provide a link.
>>
>>
>> On Sat, 2008-02-16 at 18:44 -0800, Philip Prindeville wrote:
>>
>>> Anyway, I have no idea why I'm seeing some of these scores. URL
>>> matches when there aren't even URL's in my message?
>>>
>>
>> There are. Self-inflicted. The ones in square brackets with the leading
>> 550 code, which you seem to keep sending back and forth. :)
>>
>
> And just *mentioning* the domain name, without any sort of valid URL
> (ftp: or http: or anything of the sort) is going to match it as a
> URL? That's highly bogus.
>
> A domain name alone does not a URL make.
You tell that to most windows-based clients, which will automatically
make clickalble URLs out of things like www.google.com in text sections.
<snip>
>
>> Oh, and DNS_FROM_OPENWHOIS probably is http://open-whois.org/, which
>> gives you a hint about what it actually is. The hit itself pretty much
>> mentions this...
>>
>
> Yeah, I read this. And I don't get that either.
>
> How does having your domain be anonymous (for whatever reason... maybe
> you're a small company operating below the radar) make your email any
> more likely to be spam????
Decidedly so. The people with the strongest reason to hide their contact
information are the spammers, and other shady businesses.
That's not to say they're aren't some legitimate folks that use this
kind of anonymization. However, the "domains by proxy" model is a
questionable practice, as it violates the spirit of the whois
requirements. Also, many of them violate the letter of the requirements,
such as the phone issue noted on the open-whois main page. (ie: anyone
registered using securewhois is not correctly reigstered, per ICANN
requirements for whois)
>
>>> TVD_STOCK1? There's no mention of stock anywhere in the message.
>>>
>>
Not sure, you migth want to try running it with debugging on.
The debug message from the code would be:
dbg("eval: stock info hit: $1");
That should tell you what exact substring matched the stock info code.
>> From a quick glimpse of the code, it appears to identify common words
>> used in stock (as in stock exchange, pump-n-dump penny stocks) spam. It
>> does not search for the word "stock". Just as pretty much no rule in SA
>> ever searches for single words only...
>>
>
> Again, I didn't see anything that should legitimately be causing this
> rule to fire, and certainly not with such a high score for such an
> unreliable rule.
>
>
>>> Why am I seeing all of these bogus matches?
>>>
>>
>> From what I can tell, and what you sent us, they don't appear to be
>> bogus.
>>
>
> Depends on whether you equate bare domains with URL's, I suppose.
If MUA's equate them with URLs, spammers will use this, and SpamAssassin
will use it.
>
>>> I looked on the wiki for some of these, but couldn't find descriptions.
>>>
>>> What should I do? Just block their domain? I don't want to deal with
>>> their misconfiguration issues.
>>>
>>
>> Apparently you already exchanged messages? Try not sending the offensive
>> mail in question. Put it up somewhere as reference, if need be. Hmm,
>> sounds familiar... ;)
>>
>> guenther
>>
>>
>>
>
> No, I sent them back the offending email, initially. Which they
> marked as spam (bloody brilliant, of course it's spam, otherwise I
> wouldn't be bothering to report it.... what else do they expect to
> come to their "Abuse" mailbox, anyway???).
>
> So I sent back the SA scores back to them, and that's the part that I
> pasted previously.
>
> How do you report Spam to such a site that's going to block your Spam
> reports for being... well, Spam!
Well, it's stupid, and probably a RFC violation to perform such
filtering on your abuse box. So, I'm not saying the domain in question
isn't behaving foolishly. You might want to point this out to them, and
suggest they whitelist their abuse address. At the very least, ask them
if they have an alternate reporting address that isn't filtered.
Re: Clearly bogus false positives -- on "abuse" contact point, no
less
Posted by Philip Prindeville <ph...@redfish-solutions.com>.
Karsten Bräckelmann wrote:
> Please, do not paste a gigantic blob of multipart MIME messages. Put it
> up somewhere, raw, and simply provide a link.
>
>
> On Sat, 2008-02-16 at 18:44 -0800, Philip Prindeville wrote:
>
>> Anyway, I have no idea why I'm seeing some of these scores. URL matches
>> when there aren't even URL's in my message?
>>
>
> There are. Self-inflicted. The ones in square brackets with the leading
> 550 code, which you seem to keep sending back and forth. :)
>
And just *mentioning* the domain name, without any sort of valid URL
(ftp: or http: or anything of the sort) is going to match it as a URL?
That's highly bogus.
A domain name alone does not a URL make.
>> A 2.6 score on BAYES_00? URIBL_JP_SURBL and URIBL_OB_SURBL? And what
>> the heck is DNS_FROM_OPENWHOIS???
>>
>
> Well, if you don't mind having a second look, that is MINUS 2.6 for
> Bayes. What's wrong with that?\
>
Oh, sorry, read over the scores too quickly. Never mind the BAYES_00.
> Regarding your SURBL questions... Yes. Wait, you where hoping for more?
> Without any actually asked question? OK, good then. The domain
> chalturs.com is listed in these RBLs, as the results tell you. See
> http://surbl.org/ for more.
>
I read the top-level page, but didn't see anything really pertinent. I
get the idea. But naming the domain in a message, again, is not the
same as embedding an entire URL containing the domain. The two aren't
equivalent.
> Oh, and DNS_FROM_OPENWHOIS probably is http://open-whois.org/, which
> gives you a hint about what it actually is. The hit itself pretty much
> mentions this...
>
Yeah, I read this. And I don't get that either.
How does having your domain be anonymous (for whatever reason... maybe
you're a small company operating below the radar) make your email any
more likely to be spam????
>> TVD_STOCK1? There's no mention of stock anywhere in the message.
>>
>
> From a quick glimpse of the code, it appears to identify common words
> used in stock (as in stock exchange, pump-n-dump penny stocks) spam. It
> does not search for the word "stock". Just as pretty much no rule in SA
> ever searches for single words only...
>
Again, I didn't see anything that should legitimately be causing this
rule to fire, and certainly not with such a high score for such an
unreliable rule.
>> Why am I seeing all of these bogus matches?
>>
>
> From what I can tell, and what you sent us, they don't appear to be
> bogus.
>
Depends on whether you equate bare domains with URL's, I suppose.
>> I looked on the wiki for some of these, but couldn't find descriptions.
>>
>> What should I do? Just block their domain? I don't want to deal with
>> their misconfiguration issues.
>>
>
> Apparently you already exchanged messages? Try not sending the offensive
> mail in question. Put it up somewhere as reference, if need be. Hmm,
> sounds familiar... ;)
>
> guenther
>
>
>
No, I sent them back the offending email, initially. Which they marked
as spam (bloody brilliant, of course it's spam, otherwise I wouldn't be
bothering to report it.... what else do they expect to come to their
"Abuse" mailbox, anyway???).
So I sent back the SA scores back to them, and that's the part that I
pasted previously.
How do you report Spam to such a site that's going to block your Spam
reports for being... well, Spam!
(Yes, I'm shocked too to hear there's gambling going on in Casablanca...)
Re: Clearly bogus false positives -- on "abuse" contact point, no
less
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
Please, do not paste a gigantic blob of multipart MIME messages. Put it
up somewhere, raw, and simply provide a link.
On Sat, 2008-02-16 at 18:44 -0800, Philip Prindeville wrote:
> Anyway, I have no idea why I'm seeing some of these scores. URL matches
> when there aren't even URL's in my message?
There are. Self-inflicted. The ones in square brackets with the leading
550 code, which you seem to keep sending back and forth. :)
> A 2.6 score on BAYES_00? URIBL_JP_SURBL and URIBL_OB_SURBL? And what
> the heck is DNS_FROM_OPENWHOIS???
Well, if you don't mind having a second look, that is MINUS 2.6 for
Bayes. What's wrong with that?
Regarding your SURBL questions... Yes. Wait, you where hoping for more?
Without any actually asked question? OK, good then. The domain
chalturs.com is listed in these RBLs, as the results tell you. See
http://surbl.org/ for more.
Oh, and DNS_FROM_OPENWHOIS probably is http://open-whois.org/, which
gives you a hint about what it actually is. The hit itself pretty much
mentions this...
> TVD_STOCK1? There's no mention of stock anywhere in the message.
>>From a quick glimpse of the code, it appears to identify common words
used in stock (as in stock exchange, pump-n-dump penny stocks) spam. It
does not search for the word "stock". Just as pretty much no rule in SA
ever searches for single words only...
> Why am I seeing all of these bogus matches?
>>From what I can tell, and what you sent us, they don't appear to be
bogus.
> I looked on the wiki for some of these, but couldn't find descriptions.
>
> What should I do? Just block their domain? I don't want to deal with
> their misconfiguration issues.
Apparently you already exchanged messages? Try not sending the offensive
mail in question. Put it up somewhere as reference, if need be. Hmm,
sounds familiar... ;)
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; }}}
Re: Clearly bogus false positives -- on "abuse" contact point, no
less
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Sun, 2008-02-17 at 08:41 -0500, Michael Scheidell wrote:
> There is, but due to complaints, it was taken out of SA. (some thought that
> just because you ignore abuse@ or postmaster@ email wasn't enough of a sign
> that you were a spammer. And it is 'Spam' assassin, not 'lame-admin'
> assassin ;-)
>
> See www.rfc-ignorant.org.
> Abuse, postmaster, whois, dsn, bogusmx
> (every messagelabs client is listed in bogusmx due to the phusked up way
> message labs assigns mx records)
> Several LARGE isp's are listed in the abuse@ due to their bouncing of abuse
> complaints, or requiring you to fill our forms on their web site.
> Maybe you don't want to 100% block them, but you can look for old RFCI rules
> and score them higher.
Yeah, though at the very least, one should be careful which scores to
bump. After all, they don't list only domains, but entire TLDs.
The ccTLD .de for example is listed in their whois. So Heise is deemed
spammy or ignoring RFCs? Go figure. There isn't much a domain owner can
do here...
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; }}}
Re: Clearly bogus false positives -- on "abuse" contact point, no less
Posted by Matt Kettler <mk...@verizon.net>.
Michael Scheidell wrote:
>
>> From: Philip Prindeville <ph...@redfish-solutions.com>
>> Date: Sat, 16 Feb 2008 18:44:55 -0800
>> To: Spamassassin Mailing List <us...@spamassassin.apache.org>
>> Subject: Clearly bogus false positives -- on "abuse" contact point, no less
>>
>> Hmmm. I think we need a BL for reporting ISP's that are clueless as to
>> run filtering on their "abuse" mailbox (or the mailbox that's listed for
>> their ARIN/RIPE AbuseEmail attributes).
>>
>>
> There is, but due to complaints, it was taken out of SA. (some thought that
> just because you ignore abuse@ or postmaster@ email wasn't enough of a sign
> that you were a spammer. And it is 'Spam' assassin, not 'lame-admin'
> assassin ;-)
>
Actually, it was removed due to lack of accuracy. If a rule can't
maintain a S/O of over 0.80, or under 0.20, it's removed.
Re: Clearly bogus false positives -- on "abuse" contact point, no
less
Posted by Michael Scheidell <sc...@secnap.net>.
> From: Philip Prindeville <ph...@redfish-solutions.com>
> Date: Sat, 16 Feb 2008 18:44:55 -0800
> To: Spamassassin Mailing List <us...@spamassassin.apache.org>
> Subject: Clearly bogus false positives -- on "abuse" contact point, no less
>
> Hmmm. I think we need a BL for reporting ISP's that are clueless as to
> run filtering on their "abuse" mailbox (or the mailbox that's listed for
> their ARIN/RIPE AbuseEmail attributes).
>
There is, but due to complaints, it was taken out of SA. (some thought that
just because you ignore abuse@ or postmaster@ email wasn't enough of a sign
that you were a spammer. And it is 'Spam' assassin, not 'lame-admin'
assassin ;-)
See www.rfc-ignorant.org.
Abuse, postmaster, whois, dsn, bogusmx
(every messagelabs client is listed in bogusmx due to the phusked up way
message labs assigns mx records)
Several LARGE isp's are listed in the abuse@ due to their bouncing of abuse
complaints, or requiring you to fill our forms on their web site.
Maybe you don't want to 100% block them, but you can look for old RFCI rules
and score them higher.
--
Michael Scheidell, CTO
>|SECNAP Network Security
Winner 2008 Network Products Guide Hot Companies
_________________________________________________________________________
This email has been scanned and certified safe by SpammerTrap(tm).
For Information please see http://www.spammertrap.com
_________________________________________________________________________