Re: Clearly bogus false positives -- on abuse contact point, no less

2008-02-19 Thread Kris Deugau

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

2008-02-18 Thread Philip Prindeville

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

2008-02-18 Thread Karsten Bräckelmann
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=[EMAIL PROTECTED];
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128  (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

2008-02-18 Thread Philip Prindeville

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

2008-02-18 Thread Justin Mason

Karsten =?ISO-8859-1?Q?Br=E4ckelmann?= writes:
 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.

Exactly -- this has been a design principle of SpamAssassin for quite a
while...

--j.


Re: Clearly bogus false positives -- on abuse contact point, no less

2008-02-17 Thread Michael Scheidell


 From: Philip Prindeville [EMAIL PROTECTED]
 Date: Sat, 16 Feb 2008 18:44:55 -0800
 To: Spamassassin Mailing List users@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
_


Re: Clearly bogus false positives -- on abuse contact point, no less

2008-02-17 Thread Matt Kettler

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

2008-02-17 Thread Matt Kettler

Michael Scheidell wrote:
  

From: Philip Prindeville [EMAIL PROTECTED]
Date: Sat, 16 Feb 2008 18:44:55 -0800
To: Spamassassin Mailing List users@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

2008-02-17 Thread Philip Prindeville

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

2008-02-17 Thread Matt Kettler

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

2008-02-17 Thread Philip Prindeville

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

2008-02-17 Thread Daryl C. W. O'Shea
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

2008-02-17 Thread Matt Kettler

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

2008-02-16 Thread Karsten Bräckelmann
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=[EMAIL PROTECTED];
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128  (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

2008-02-16 Thread Philip Prindeville

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

2008-02-16 Thread hamann . w
Karsten Bräckelmann wrote:
 
 
 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?
 
..

  
  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... ;)

When it finally gets through, they will probably send you an autoreply that 
they cannot handle
abuse complaints without the necessary evidence, e.g. the original piece of 
spam, included.
Back to square 1 ... or the fax machine

Wolfgang Hamann