date:20061218

RE: roaming users sending mail internally and dynamic IPs issue

2006-12-18 Thread Leon Kolchinsky



> -Original Message-
> From: Thomas Bolioli [mailto:[EMAIL PROTECTED]
> Sent: Monday, December 18, 2006 5:37 PM
> To: users@spamassassin.apache.org
> Subject: roaming users sending mail internally and dynamic IPs issue
> 
> Whenever our users travel outside the internal networks and send email
> to each other, the emails get tagged by the below reports (yes, I
> cranked up the default scores because of the botnet crap out there)
> because they are on dyn IPs and sending direct to the receiving MTA.
> 
> I see a couple of ways that this can be remedied, most of which is
> acceptable. a) Whitelist all of the users (or the entire domain) for
> every domain on the system [obviously bad since it allows spammers to
> spoof from headers with impunity even with SPF setup]. b) set up second
> machine to be a second MTA and have users send email from machine 2
> which then relays to machine 1 [waste of a machine and energy to run
> that machine]. or c) there is some configuration I am missing. Does
> anyone know what I can do to fix this?
> 
> Thanks,
> Tom
> 
> *  0.7 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP
> address
> *  [xx.xx.xx.xx listed in dnsbl.sorbs.net]
> *  2.5 RCVD_IN_NJABL_DUL RBL: NJABL: dialup sender did non-local SMTP
> *  [xx.xx.xx.xx listed in combined.njabl.org]

If you using postfix+amavis+SA, there are many ways to bypass SA checks for 
your users:
http://www200.pair.com/mecham/spam/bypassing.html



Regards,
Leon

Re: Boy, everything is getting spam protection these days.

2006-12-18 Thread Theo Van Dinter

On Tue, Dec 19, 2006 at 12:32:51AM -0500, Steve Lake wrote:
> spam, I get AIM spam, I get spam in my spam.  It's just nuts.  heh.  Even 
> my phone.  Now how sad is that.  Oh well, just thought I'd share that.

Leela: "Didn't you have ads in the 20th century?"
Fry: "Well sure, but not in our dreams! Only on tv and radio...and in
magazines...and movies. And at ball games, on buses, and milk cartons,
and t-shirts, and bananas, and written on the sky. But not in dreams!
No sirree."
- Futurama, "A Fishful of Dollars"


pgplSpSEmoNCa.pgp
Description: PGP signature

Boy, everything is getting spam protection these days.

2006-12-18 Thread Steve Lake

lol.  This is kind of OT, but does involve stopping spammers.  One 
thing I've noticed lately is that they're getting really desperate.  So 
much so that I've not only had to add spam protection to my forums, but 
I've also had to several of my web forms.  Yes, spammers were actually 
spamming me through my web forms.  Go figure that one out.  heh.  I get ICQ 
spam, I get AIM spam, I get spam in my spam.  It's just nuts.  heh.  Even 
my phone.  Now how sad is that.  Oh well, just thought I'd share that.



Steven Lake
Owner/Technical Writer
Raiden's Realm
www.raiden.net
A friendly web community

Re: Negative AWL on a spam & received from localhost?

2006-12-18 Thread Matt Kettler

Henry Kwan wrote:
> Hi,
>
> Running SA 3.17 on a CentOS 4.4 install with sendmail.  Am getting some spams
> that score negative AWL and was wondering why this was.  
Rule 1) just because the AWL scores negative, does NOT mean the AWL
thinks it is nonspam. The AWL is fundamentally a score averager, and the
only way for it to always assign positive scores to spam is if your
pre-awl scores are constantly decreasing. .that's a BAD thing.

In this case, the past average for the sender was approximately 7.7
(spam), this message came in at 11.5 (also spam), so the AWL split the
difference and took off 1.9 points to make it 9.6 (still spam). That's
100% normal.

See also:

http://wiki.apache.org/spamassassin/AwlWrongWay

http://wiki.apache.org/spamassassin/AutoWhitelist

Re: Rule that negative scores emails from blackberry.com, not spoofers

2006-12-18 Thread John D. Hardin

On Mon, 18 Dec 2006, Kelly Jones wrote:

> The obvious:
> 
> Received =~ /.*blackberry\.com$/
> 
> doesn't work, because someone could "HELO blackberry.com" or spoof a
> blackberry.com received header somewhere in the message headers prior
> to the last hop.

...so add enough to it to match only on Received headers that *your* 
MTA inserts.

--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 [EMAIL PROTECTED]FALaholic #11174 pgpk -a [EMAIL PROTECTED]
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  "Bother," said Pooh as he struggled with /etc/sendmail.cf, "it never
  does quite what I want. I wish Christopher Robin was here."
   -- Peter da Silva in a.s.r
---
 7 days until Christmas

Botnet 0.7 soon

2006-12-18 Thread John Rudd

New things:

1) BOTNET_SOHO -- If the sender's (chosen from Envelope-From,
Return-Path, or From, in that order) mail domain (the part after the @
sign) resolves back to the relay's IP address, or has an MX host which
resolves back to the IP address, AND the sender's mail domain does NOT
match the PTR record for the relay, then we'll assume this is a "small
office/home office" mail server. We'll exempt them from BOTNET being
triggered. (note: someone suggested that this check also try to resolve
the HELO string, I make a note in my code as to why this is an extremely
bad idea, and have a commented out block of code there for anyone who
wants to go down that path ... but, really, don't)

2) Botnet API -- want to include the Botnet.pm module in other Perl
code? Maybe call "check_botnet" from mimedefang-filter so you can block
before a message gets to SpamAssassin? I've made an API for it. The
routines that SA calls use this API, so it's the _exact_same_ code.
There's now an included perl program "Botnet.pl" which takes an IP
address CLI argument, and an optional main-domain CLI argument. It will
tell you which rules do and don't get triggered. It also serves as an
example of using the API. (you will still need to have SpamAssassin
installed in order to use Botnet.pm in this fashion, even if you're
using the API in a program that doesn't call SA)

3) BOTNET_CLIENT and BOTNET are now actual rules instead of meta rules.
The individual rules are still there, just with zero'd scores. You
can now easily pick between 1 big rule (BOTNET doing eval:botnet()),
meta rules (detailed in the file Botnet.variations.txt), or piece-meal
calling of the individual checks (also detailed in Botnet.variations.txt).

4) config option: botnet_pass_trusted (all|public|private|ignore)
This defaults to "public". If you have any public IP addresses in your
relays-trusted list, then Botnet wont trigger. Private means "any
private IP addresses", where that includes 127.*, 10.*, etc.. All means
either of those two. Ignore means "do what Botnet used to do: not even
look at the trusted relays, just look past them". The idea is: if you
got this from a trusted relay, we can assume it wasn't a Botnet.

5) botnet_pass_auth now looks at the trusted relays. It probably should
have been doing that all along. It no longer looks at the untrusted relays.

6) Rules that get triggered now use $permsgstatus->test_log to record
information. The individual rules just list
"[rulename,ip=$ip,hostname=$host,maildomain=$domain]" or an appropriate
subset of that based on which rule it is. BOTNET_CLIENT and BOTNET also
include a list of sub-rule names that were triggered. So, you might see
this:

[botnet,ip=1.2.3.4,host=dsl-1-2-3-4.isp.net,domain=spammer.com,baddns,ipinhostname,clientwords,client]

[botnet_nordns,ip=2.3.4.5]

[botnet_soho,ip=3.4.5.6,hostname=3.4.5.6.isp.net,maildomain=non-spammer-soho.org]

(once I'm more comfortable with the output, I'll probably take out the
leading rule name, but for now, I'm keeping it there)

7) shawcable.net and ocn.ne.jp seem to also be botnet sources, but their
hostnames don't fit any of my other patterns. Luckily, they DO fit some
pattern, and it's simple enough to not need a code based rule, just a
regular conventional expression based rule. I've created
BOTNET_SHAWCABLE and BOTNET_OCNNEJP rules to cover these two.

73 matches

Mail list logo