Re: is DOS_OUTLOOK_TO_MX too low?

[Karsten Bräckelmann]

On Sat, 2008-01-26 at 20:37 -0500, Daryl C. W. O'Shea wrote:
> Jason Haar wrote:

> > I just got a spam msg with a score of 4/5 and for the first time noticed
> > the DOS_OUTLOOK_TO_MX rule.
> > 
> > For those that don't know it means "Delivered direct to MX with Outlook
> > headers". Sounds like a good rule: Outlook isn't a MTA so shouldn't be
> > able to connect directly to MX records - except for it's configured SMTP
> > server.
> 
> The rule does work good... 50% of its spam hits are on mail scored 5 or
> less.

Indeed, this rule seems to hit mostly on "low scoring" mail. Granted, I
checked against 2 weeks worth of spam only -- however, the hits in 15+
scoring spam are almost negligible. But it does hit a few percent in my
10-15 range. (Note: These results include some special, custom crafted
rules which apply to my env only.)

This does have some potential, to push a few more spams above the edge
of 15 points. No hits in my 0.08% of FNs, though.

Thanks, Daryl, for the rule and the reassuring explanation! And thanks
Jason for bringing it up in the first place. If you'd excuse me now,
I'll go raise that score. :)


> > But it only has a score of 1.0. I just looked through a weeks worth of
> > SA logs and all the emails we received that triggered DOS_OUTLOOK_TO_MX
> > - but didn't get tagged as spam - were spam. So it seems to me that rule
> > is a better indicator than it's given credit for?
> 
> When I wrote the rule and added it to the updates, in September, it was
> scoring poorly due to what I believe was probably dirty corpora.  I
> didn't have the tuits at the time to investigate it.  Current mass-check
> results show that it hit on 12 of 164,411 ham messages (all from zmi's
> corpus of 6175 ham messages), so not too bad.

Hmm, given these rare hits are isolated in a *single* corpus (0.2%, in
contrast of a whopping 0.0073% total) it would be really interesting to
investigate the reason for these hits.

Hey, it's checking 12 messages only! I'd even volunteer doing this. ;)


> > In fact, shouldn't that rule be generalized to DOS_MUA_TO_MX? I mean the
> > same rule applies for Thunderbird, mutt, etc...? If there's a X-Mailer:
> > header, then there should be an intermediary MTA before it hits yours?

I'm not sure about that generalization. What about web-site feedback
form mailers -- which "your" users might use? I've seen them add these
headers, too. Point is, they are no MUAs.

  guenther


-- 
char *t="[EMAIL PROTECTED]";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}

Re: sa-update error wrong gpg key...

[Daryl C. W. O'Shea]

Steve Monkhouse wrote:
> Hey guys.. 
> 
> We're seeing the same thing.. although slightly different..

Not really the same thing.  In the OPs case he wasn't using the key for
the channel.  In your case, your (I assume) recently updated version of
GPG refuses to use the non-cross-certified key.

> this error has
> only been happening for a week or so now.. everything's been fine before
> that.. it seems to be with the RSA key generated on 15Jan.. 

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

Daryl

Re: is DOS_OUTLOOK_TO_MX too low?

[Daryl C. W. O'Shea]

Jason Haar wrote:
> Hi there
> 
> I just got a spam msg with a score of 4/5 and for the first time noticed
> the DOS_OUTLOOK_TO_MX rule.
> 
> For those that don't know it means "Delivered direct to MX with Outlook
> headers". Sounds like a good rule: Outlook isn't a MTA so shouldn't be
> able to connect directly to MX records - except for it's configured SMTP
> server.

The rule does work good... 50% of its spam hits are on mail scored 5 or
less.

> But it only has a score of 1.0. I just looked through a weeks worth of
> SA logs and all the emails we received that triggered DOS_OUTLOOK_TO_MX
> - but didn't get tagged as spam - were spam. So it seems to me that rule
> is a better indicator than it's given credit for?

When I wrote the rule and added it to the updates, in September, it was
scoring poorly due to what I believe was probably dirty corpora.  I
didn't have the tuits at the time to investigate it.  Current mass-check
results show that it hit on 12 of 164,411 ham messages (all from zmi's
corpus of 6175 ham messages), so not too bad.

> As long as our network is configured to handle our own SMTP clients
> correctly (as it is: we don't run SA on locally generated mail), does
> anyone see a problem with pushing that score up to (say) 3.0?

Part of the reason I didn't initially increase the score was that it's
not unheard of for Outlook headers to show up in list mail... some
mailing lists strip all existing received headers before sending the
mail (the rule tries to detect that though) and there's the case of
people composing a message in Outlook and then sending it with their
mass email program directly to your MX.  So FPs are conceptually possible.

Current scoring suggests that 3.6 would be suitable (it's what would get
assigned if we cut a release today and made no manually adjustments), so
3.0 should be safe.

> In fact, shouldn't that rule be generalized to DOS_MUA_TO_MX? I mean the
> same rule applies for Thunderbird, mutt, etc...? If there's a X-Mailer:
> header, then there should be an intermediary MTA before it hits yours?

I targeted Outlook and OE headers since they are (and were at the time)
the ones most abused and were the only spams I had seen with MUA headers
and no extra received headers that were getting though SA.

Adding a rule for other MUAs wouldn't necessarily be a bad idea... it's
basically a free rule processing wise (you can probably do it entirely
with a meta rule... we already have rules for many MUAs).  You just have
to keep in mind that the more MUAs you accept for the rule the greater
the chance of the list mail style FPs.  I've yet to see spam that would
'benefit' from such a rule so haven't yet bothered with weighing this FP
risk.

Additionally, and as you've mentioned this doesn't apply to you, there's
the issue of releasing such a rule to everyone since there are s
many setups out there with completely broken trust configurations.

Daryl

Re: unsubscribe

[mouss]

Raquel wrote:

On Sat, 26 Jan 2008 14:26:22 +0100
mouss <[EMAIL PROTECTED]> wrote:

  

Matt Kettler wrote:


Post to the unsubscribe address, not the list.

See the headers of any message:

List-Unsubscribe:
 
  

I wonder if it would be bad to forge an unsubscribe requests in such
cases, but I'm not sure they will understand what to do when they
get the confirmation request ;-p




They knew what to do with the subscribe confirmation message.

  


depends on who is "They" :) Most people do, otherwise we would be 
inundated. but few will still post noise.


Starting a fight will benefit to nobody. educating people may help 
avoiding noise on other lists (or on the same list should the user 
resubscribe).


If only MUAs stop sending their "fancy" html stuff in such cases, a 
parser could easily detect such noise and send a confirmation request to 
the user...

is DOS_OUTLOOK_TO_MX too low?

[Jason Haar]

Hi there

I just got a spam msg with a score of 4/5 and for the first time noticed 
the DOS_OUTLOOK_TO_MX rule.


For those that don't know it means "Delivered direct to MX with Outlook 
headers". Sounds like a good rule: Outlook isn't a MTA so shouldn't be 
able to connect directly to MX records - except for it's configured SMTP 
server.


But it only has a score of 1.0. I just looked through a weeks worth of 
SA logs and all the emails we received that triggered DOS_OUTLOOK_TO_MX 
- but didn't get tagged as spam - were spam. So it seems to me that rule 
is a better indicator than it's given credit for?


As long as our network is configured to handle our own SMTP clients 
correctly (as it is: we don't run SA on locally generated mail), does 
anyone see a problem with pushing that score up to (say) 3.0?


In fact, shouldn't that rule be generalized to DOS_MUA_TO_MX? I mean the 
same rule applies for Thunderbird, mutt, etc...? If there's a X-Mailer: 
header, then there should be an intermediary MTA before it hits yours?


--
Cheers

Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +64 3 9635 377 Fax: +64 3 9635 417
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1

Re:

[Jeff Chan]

Quoting Giampaolo Tomassoni <[EMAIL PROTECTED]>:


From: Jeff Chan [mailto:[EMAIL PROTECTED]
Sometimes it's temporary, sometimes it's not.  Sometimes temporary
solutions remain in place for many years.


Then you're not obeying to the agreements with your registrar.



Delegation is a primary function of DNS.


You are misinterpreting what delegation is meant to, Jeff. I suggest you to
read the docs about it at IETF or ICANN: there is not even a single word
about delegation which is not related to sub-domains.


I worked on DNS (among other things) at the world's largest web host  
for several years.  I was regarded as one of the experts on DNS (among  
other things) there.  Every NS record is by definition a delegation,  
and real world practices by real people do not always strictly follow  
the RFCs.


Cheers,

Jeff C.

[no subject]

[Giampaolo Tomassoni]

> -Original Message-
> From: Jeff Chan [mailto:[EMAIL PROTECTED]
> Sent: Saturday, January 26, 2008 5:33 PM
> 
> Quoting Giampaolo Tomassoni <[EMAIL PROTECTED]>:
> 
> >> From: Jeff Chan [mailto:[EMAIL PROTECTED]
> >> There are lots of legitimate reasons to delegate zones, for example,
> >> migration to a new nameserver.  I suggest you ask someone who runs
> >> major nameservers.  I have.
> >
> > This is a temporary solution. Later you upgrade your registration
> records,
> > right?
> 
> Sometimes it's temporary, sometimes it's not.  Sometimes temporary
> solutions remain in place for many years.

Then you're not obeying to the agreements with your registrar.


> Delegation is a primary function of DNS.

You are misinterpreting what delegation is meant to, Jeff. I suggest you to
read the docs about it at IETF or ICANN: there is not even a single word
about delegation which is not related to sub-domains.

Have good scores...

Giampaolo


> Jeff C.

RE: whois plugin .. where to get it

[Jeff Chan]

Quoting Giampaolo Tomassoni <[EMAIL PROTECTED]>:


From: Jeff Chan [mailto:[EMAIL PROTECTED]
There are lots of legitimate reasons to delegate zones, for example,
migration to a new nameserver.  I suggest you ask someone who runs
major nameservers.  I have.


This is a temporary solution. Later you upgrade your registration records,
right?


Sometimes it's temporary, sometimes it's not.  Sometimes temporary  
solutions remain in place for many years.  Delegation is a primary  
function of DNS.


Jeff C.

Re: unsubscribe

[Raquel]

On Sat, 26 Jan 2008 14:26:22 +0100
mouss <[EMAIL PROTECTED]> wrote:

> Matt Kettler wrote:
> > Post to the unsubscribe address, not the list.
> >
> > See the headers of any message:
> >
> > List-Unsubscribe:
> >  
> 
> I wonder if it would be bad to forge an unsubscribe requests in such
> cases, but I'm not sure they will understand what to do when they
> get the confirmation request ;-p
> 

They knew what to do with the subscribe confirmation message.

-- 
Raquel

The care of human life and happiness, and not their destruction, is
the first and only legitimate object of good government.

  --Thomas Jefferson

RE: whois plugin .. where to get it

[Giampaolo Tomassoni]

> -Original Message-
> From: Jeff Chan [mailto:[EMAIL PROTECTED]
> Sent: Saturday, January 26, 2008 4:33 PM
> 
> 
> There are lots of legitimate reasons to delegate zones, for example,
> migration to a new nameserver.  I suggest you ask someone who runs
> major nameservers.  I have.

This is a temporary solution. Later you upgrade your registration records,
right?

Giampaolo

> 
> Jeff C.

RE: whois plugin .. where to get it

[Jeff Chan]

Quoting Jeff Chan <[EMAIL PROTECTED]>:


DNS works by delegation from parent zones to child zones.


Or more generally from one zone to another.  DNS is built on  
delegation.  Some spammers abuse delegation in unusual ways, but not  
all unusual delegation is abuse.


Jeff C.

RE: whois plugin .. where to get it

[Jeff Chan]

Quoting Giampaolo Tomassoni <[EMAIL PROTECTED]>:


-Original Message-
From: Jeff Chan [mailto:[EMAIL PROTECTED]
Sent: Saturday, January 26, 2008 12:23 PM

Quoting Jeff Chan <[EMAIL PROTECTED]>:

> Quoting Giampaolo Tomassoni <[EMAIL PROTECTED]>:
>
>> The TLD root servers delegate the control of the II level domain to
the NS
>> servers defined at registration time. That is delegation. But from
there,
>> warping the entire domain to different NSes is not delegation.
>
> It is delegation.


NSes authoritative for a domain delegating that whole domain to some other
NSes is "delegation"?


Yes.  DNS works by delegation from parent zones to child zones.


It is easy to do, but there is no need to unless you want to play ping-pong
with responsibilities when somebody files a claim statement against your
org...


There are lots of legitimate reasons to delegate zones, for example,  
migration to a new nameserver.  I suggest you ask someone who runs  
major nameservers.  I have.


Jeff C.

RE: whois plugin .. where to get it

[Giampaolo Tomassoni]

> -Original Message-
> From: Jeff Chan [mailto:[EMAIL PROTECTED]
> Sent: Saturday, January 26, 2008 12:23 PM
> 
> Quoting Jeff Chan <[EMAIL PROTECTED]>:
> 
> > Quoting Giampaolo Tomassoni <[EMAIL PROTECTED]>:
> >
> >> The TLD root servers delegate the control of the II level domain to
> the NS
> >> servers defined at registration time. That is delegation. But from
> there,
> >> warping the entire domain to different NSes is not delegation.
> >
> > It is delegation.

NSes authoritative for a domain delegating that whole domain to some other
NSes is "delegation"?

I would rather name it "abdication". "Zone warping" likes me more, however.


> And more specifically not all delegations of this type are
> illegitimate. Sometimes there are legitimate reasons why someone
> might want or need to delegate DNS authority for a given domain to
> another nameserver.

Agreed already. See <[EMAIL PROTECTED]@libero.it>:

> Then, of course there is people ... even that are somehow mandated
> to warp their zone, but I don't see big numbers here.


> Therefore using it as a spam test will probably result in false
> positives.

Agreed already. See <[EMAIL PROTECTED]@libero.it>:

> After all, every SA rule has its own FPs, isn't it?


> This type of delegation is very easy to do.  Normally if one registers
> a domain using dns1.foo.com and dns2.foo.com, the NS records would
> look like:
> 
> mydomain.com IN NS dns1.foo.com.
> mydomain.com IN NS dns2.foo.com.
> 
> In order to delegate them elsewhere, the NS record for the domain is
> changed:
> 
> mydomain.com IN NS dns1.bar.com.
> mydomain.com IN NS dns2.bar.com.

It is easy to do, but there is no need to unless you want to play ping-pong
with responsibilities when somebody files a claim statement against your
org...

Giampaolo

> Jeff C.

Re: unsubscribe

[mouss]

Matt Kettler wrote:
> Post to the unsubscribe address, not the list.
>
> See the headers of any message:
>
> List-Unsubscribe: 
>   

I wonder if it would be bad to forge an unsubscribe requests in such
cases, but I'm not sure they will understand what to do when they get
the confirmation request ;-p

p0f not catching Windows XP

[McDonald, Dan]

I'm using amavisd-new and p0f with BOTNET.pl, and some Windows XP
machines are not being caught.
Here are my rules:
header L_P0F_WXP   X-Amavis-OS-Fingerprint =~ /^Windows XP(?![^(]*\b2000 SP)/
score  L_P0F_WXP   2.3
header L_P0F_W X-Amavis-OS-Fingerprint =~ /^Windows(?! XP)/
score  L_P0F_W 1.0
header L_P0F_UNKN  X-Amavis-OS-Fingerprint =~ /^UNKNOWN/
score  L_P0F_UNKN  0.8
header L_P0F_Unix  X-Amavis-OS-Fingerprint =~ 
/^((Free|Open|Net)BSD|Solaris|HP-UX|Tru64)/
score  L_P0F_Unix  -1.0
header L_P0F_Linux X-Amavis-OS-Fingerprint =~ /^Linux/
score  L_P0F_Linux -0.1


I had a message with the following header:
X-Amavis-OS-Fingerprint: Windows XP SP1+, 2000 SP3 (NAT!), (distance 20,
link: unknown-1490), [83.11.64.39]

It doesn't appear to match either the L_P0F_WXP or the L_P0F_W rule:
[EMAIL PROTECTED] ~]$ grep -P '/^Windows(?! XP)/' Download/foo.eml 
[EMAIL PROTECTED] ~]$ grep -P '/^Windows XP(?![^(]*\b2000 SP)/' 
Download/foo.eml 


Does anyone have rules that catch this?


-- 
Daniel J McDonald, CCIE #2495, CISSP #78281, CNX
Austin Energy
http://www.austinenergy.com



signature.asc
Description: This is a digitally signed message part

RE: whois plugin .. where to get it

[Jeff Chan]

Quoting Jeff Chan <[EMAIL PROTECTED]>:


Quoting Giampaolo Tomassoni <[EMAIL PROTECTED]>:


The TLD root servers delegate the control of the II level domain to the NS
servers defined at registration time. That is delegation. But from there,
warping the entire domain to different NSes is not delegation.


It is delegation.


And more specifically not all delegations of this type are  
illegitimate.  Sometimes there are legitimate reasons why someone  
might want or need to delegate DNS authority for a given domain to  
another nameserver.  Therefore using it as a spam test will probably  
result in false positives.


This type of delegation is very easy to do.  Normally if one registers  
a domain using dns1.foo.com and dns2.foo.com, the NS records would  
look like:


mydomain.com IN NS dns1.foo.com.
mydomain.com IN NS dns2.foo.com.

In order to delegate them elsewhere, the NS record for the domain is changed:

mydomain.com IN NS dns1.bar.com.
mydomain.com IN NS dns2.bar.com.

Jeff C.

RE: whois plugin .. where to get it

[Jeff Chan]

Quoting Giampaolo Tomassoni <[EMAIL PROTECTED]>:


The TLD root servers delegate the control of the II level domain to the NS
servers defined at registration time. That is delegation. But from there,
warping the entire domain to different NSes is not delegation.


It is delegation.

Jeff C.

RE: whois plugin .. where to get it

[Giampaolo Tomassoni]

> -Original Message-
> From: Jeff Chan [mailto:[EMAIL PROTECTED]
> Sent: Saturday, January 26, 2008 8:39 AM
> 
> Quoting Giampaolo Tomassoni <[EMAIL PROTECTED]>:
> >> From: Jeff Chan [mailto:[EMAIL PROTECTED]
> 
> >> Yes, delegation is the other, more usual, way that the nameserver in
> >> the whois and  TLD root server may differ.  Some spammers do make
> use
> >> of a lot of delegation, more than usual and sometimes in long chains
> >> of delegation, but delegation beyond the typical glue records is not
> >> necessarily the sign of a spam domain.
> >
> > It is not delegation. Delegation is when you delegate the handling of
> DNS
> > requests on a subdomain of your domain to a different DNS server, not
> the
> > handling of the domain itself. The latter is fooling your
> registration data:
> > you register your domain specifying a couple of nameservers, then
> instead
> > use others. Basically, wherever (in the world) you are, your
> registrar asks
> > you to specify "at least two *authoritative* nameservers for your
> domain" in
> > your registration. Then, that nameservers says they are not
> authoritative
> > for the domain. See the conflict?
> 
> It is delegation.

The TLD root servers delegate the control of the II level domain to the NS
servers defined at registration time. That is delegation. But from there,
warping the entire domain to different NSes is not delegation. It is a
practice that the DNS infrastructure support, but it is not strictly
correct. Even for the reasons I just said.


> You may want to review how DNS works.

Wuff!


Giampaolo

> Jeff C.

Re: Redo: Upgrade 3.2.3->3.2.4 breaks rule override

[Matthias Leisi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Kris Deugau schrieb:

|> I appreciate the advice to hack our DNS configuration, but I'd prefer
|> to keep all my SpamAssassin tweaks in the SpamAssassin config file and
|> not have to document and (subsequently remember to actually look at
|> the documentation ;) ) that I had to hack DNS as well.
|
| Well, if you're keeping a local mirror of the zone, it makes sense to
| tweak your DNS to return local data on queries to the "real" zone,
| because what if someone decides later on to add a DNSBL check in
| sendmail?  What if someone finds some other use in some other place for

I *strongly* support Kris' advice. We see an awful lot of
misconfigurations of people who use their rsync'ed copy of dnswl.org
data *without* configuring their DNS servers.

Yes, I'm aware that - especially in company environments - it can be
tedious (often, at least network and mail teams need to talk to each
other...), but it is indispensible to get this right -- otherwise, the
whole rsync'ing exercise provides more trouble(shooting) than it's worth.

- -- Matthias, for dnswl.org

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (Darwin)

iD8DBQFHmuijxbHw2nyi/okRApkqAKC606su45A7396ycEC5p9EEdrc1QACfZOVT
Eu/hNFg6qPNfGevQ/5qtvXY=
=YF4Y
-END PGP SIGNATURE-