Re: protocol is caSE sensitive, but should not be
On Tue 25 May 2010 10:01:12 PM CEST, Benny Pedersen wrote
# save rule as 99_local_bugs_331.cf
# SA = 3.3.1
if (version == 3.003001)
uri __PROTOCOL_OK m{^https?://\w+}
meta PROTOCOL_FIX (!__PROTOCOL_OK)
describe PROTOCOL_FIX protocol in uri is not lowercase
score PROTOCOL_FIX 5.0
endif # sa 3.3.1 only i hope
above rule is a imidate fix until 3.3.2, works for me
ups it hits when there is no url in body, how to fix this ?
--
xpoint http://www.unicom.com/pw/reply-to-harmful.html
Re: Arabic Spam
On 2010/05/25 7:02 PM, Karsten Bräckelmann wrote: On Wed, 2010-05-26 at 10:35 +1200, Jason Haar wrote: Not as far as ok_locales and the respective CHARSET_FARAWAY rules are concerned, IIRC. They have been written long ago to trigger on the char-sets used. They don't detect the char-set based on the actual payload. So where does that leave us? With the need for an update or addition to the FARAWAY rules? Also, what's the deal with normalize_charset? Can that have any impact on these cases where language/locale isn't detected? -- /Jason smime.p7s Description: S/MIME Cryptographic Signature
Spam not checked at all
Hello, for the first time two weeks ago I received a kind of spam that SA doesn't check at all. Similar ist always the URL one-liner and a faked yahoo.com sender. If manually checked by SA, it gets score 40: http://pastebin.com/4arTzeRu Setup: Postfix 2.7.0 with spampd proxy. Postfix seems to just don't send these mails to the proxy, without any warning in the logs. Unfortunately it's not really possible to run Postfix in debug mode, since the server has a througput of ~10.000 mails / day and I can't reproduce the problem. I'm sure that's not a kind of misconfiguration since the problem occurs only with exactly these mails. Sorry if you think that's a Postfix issue, but I'm not yet sure. Maybe someone has an idea. Jan-Kaspar
Re: protocol is caSE sensitive, but should not be
Benny Pedersen wrote:
On Tue 25 May 2010 10:01:12 PM CEST, Benny Pedersen wrote
# save rule as 99_local_bugs_331.cf
# SA = 3.3.1
if (version == 3.003001)
uri __PROTOCOL_OK m{^https?://\w+}
meta PROTOCOL_FIX (!__PROTOCOL_OK)
describe PROTOCOL_FIX protocol in uri is not lowercase
score PROTOCOL_FIX 5.0
endif # sa 3.3.1 only i hope
above rule is a imidate fix until 3.3.2, works for me
ups it hits when there is no url in body, how to fix this ?
That's what you told it to do.
(! __PROTOCOL_OK) == true if there is not a match on your uri rule.
Try something like this:
uri PROTOCOL_FIX m{^(?!https?://)[hH][tT][tT][pP][sS]?://}
There may be a more elegant way to do this, but it should match whenever
there is an uppercase letter in there somewhere.
--
Bowie
Re: Spam not checked at all
On Wed, 2010-05-26 at 16:05 +0200, Jan-Kaspar Münnich wrote:
Setup: Postfix 2.7.0 with spampd proxy.
Postfix seems to just don't send these mails to the proxy, without any
warning in the logs.
If, as you say, SA never gets these messages for scanning, it cannot be
a problem with SA or its configuration.
Unfortunately it's not really possible to run Postfix in debug mode,
since the server has a througput of ~10.000 mails / day and I can't
reproduce the problem. I'm sure that's not a kind of misconfiguration
since the problem occurs only with exactly these mails.
Sorry if you think that's a Postfix issue, but I'm not yet sure. Maybe
someone has an idea.
You need to check your other tools in the chain. Since the samples are
rather similar, maybe there's some config that causes these to be exempt
from the spam check.
guenther
--
char *t=\10pse\0r\0dtu...@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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
How to remove a domain from a stock or third-party 2tld ruleset?
Is there any way to take a domain listed with util_rb_2tld, and un-2tld it (similar to how you can unwhitelist stock whitelist entries if they don't work well with your mail)? I recently came across a free-subsite domain that seems to be part of a cluster of **very** similar sites which I've given up listing subdomains for locally; instead I've added the TLDs to a local blacklist. The domain that's in the stock 2tld list is bravepages.com; it seems to be Yet Another Face of 0catch.com, and I've seen these domains as well: 1accesshost.com bigheadhosting.net easyfreehosting.com envy.nu digitalzones.com And no doubt there are a fairly long list of others in the cluster. For now I've just added a regular uri rule, but I'm pretty sure that won't scale, and it doesn't help with some of the automation I've been using to extract URIs not listed on any DNSBL yet from missed-spam reports. -kgd
Re: url spam from Hotmail
On 05/26/2010 09:33 PM, Lennart Johansson wrote: My first post, please don't kill me for doing some things wrong. I see quite a few of these from hotmail orginating from China. http://pastebin.com/q308E7ZG SA score: Score Matching Rule Descriptioncached not result=0.002 4 krav spamautolearn=not 0.00BAYES_50Bayesian spam probability is 40 to 60% 0.00HTML_MESSAGEHTML included in message Perhaps this is simple to detect if you know how to write the right rule, but I don't. Right now it score very low, and I try to learn SA to detect. Anybody got any suggestion how to catch them directly? Best regards /Lelle I mostly catch these with Bayes training. Your example hit BAYES_95 here. I also score all mail FROM hotmail.com (2-3 points) and then whitelist legitimate hotmail senders. Hotmail are not to big to block here and I'm sick of the crap they spew. Finally, X-Originating-IP: [123.161.74.4] is listed in Spamhaus (SPL) and I deep parse headers so I got a hit on this. Unfortunately you can't simply write a rule to combine From Hotmail and has any URI as all mail from Hotmail has a URI in the footer.
Re: url spam from Hotmail
I see quite a few of these from hotmail orginating from China.
X-Originating-IP: [123.161.74.4]
is listed in Spamhaus (SPL) and I deep parse headers so I got a hit on this.
Unlike PBL and XBL, Spamhaus SBL is safe for deep-parsing. Which SA does
for this part (only) of ZEN.
Unfortunately you can't simply write a rule to combine From Hotmail and
has any URI as all mail from Hotmail has a URI in the footer.
A meta rule from Hotmail and originating from China might be possible,
though. If that really is a common pattern. *And* acceptable for your
user-base.
Also, these Hotmail injected footers always use long-ish URIs with a
path, no? In that case, a meta with __URI_NO_PATH could help. Something
like this.
uri __URI_NO_PATH m~^https?://[^/]+/?$~
--
char *t=\10pse\0r\0dtu...@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;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: Yerp connection issues
Hi, On Wed, May 26, 2010 at 6:59 PM, Philip Prindeville philipp_s...@redfish-solutions.com wrote: Anyone else seeing the following in their cron logs: http: GEThttp://yerp.org:8080/rules/stage/330948267.tar.gz request failed: 500 Can't connect to yerp.org:8080 (connect: Connection refused): 500 Can't connect to yerp.org:8080 (connect: Connection refused) Nope, same problem here on port 8080 ... but fine access on port 80. Any reason why you are uding 8080 ? I'm running spamassassin-3.3.1-2.fc12.x86_64 on Fedora 12. mvh
Re: Yerp connection issues
On 5/26/10 11:06 AM, Mikael Syska wrote: Hi, On Wed, May 26, 2010 at 6:59 PM, Philip Prindeville philipp_s...@redfish-solutions.com wrote: Anyone else seeing the following in their cron logs: http: GEThttp://yerp.org:8080/rules/stage/330948267.tar.gz request failed: 500 Can't connect to yerp.org:8080 (connect: Connection refused): 500 Can't connect to yerp.org:8080 (connect: Connection refused) Nope, same problem here on port 8080 ... but fine access on port 80. Any reason why you are uding 8080 ? I've not modified any of the config files, so it's using whatever the Fedora 12 rpm has in /etc/mail/spamassassin/channel.d/* files. -Philip I'm running spamassassin-3.3.1-2.fc12.x86_64 on Fedora 12. mvh
Re: Yerp connection issues
On Wed, 2010-05-26 at 11:22 -0600, Philip Prindeville wrote:
On 5/26/10 11:06 AM, Mikael Syska wrote:
Anyone else seeing the following in their cron logs:
http: GEThttp://yerp.org:8080/rules/stage/330948267.tar.gz request
failed:
500 Can't connect to yerp.org:8080 (connect: Connection refused): 500
Can't
connect to yerp.org:8080 (connect: Connection refused)
I've seen these, occasionally. Transient error, usually just works the
next time sa-update is being run by cron.
Nope, same problem here on port 8080 ... but fine access on port 80.
Any reason why you are uding 8080 ?
I've not modified any of the config files, so it's using whatever the
Fedora 12 rpm has in /etc/mail/spamassassin/channel.d/* files.
The correct answer to both these statements is -- because it is in the
mirrors list. ;)
/var/lib/spamassassin/$VERSION/$CHANNEL/MIRRORED.BY
Older systems may show a single mirror on the default port 80 only. The
current version is this:
$ dig +short TXT mirrors.sought.rules.yerp.org
http://yerp.org/rules/MIRRORED.BY;
$ lynx -dump http://yerp.org/rules/MIRRORED.BY
http://yerp.org:8080/rules/stage/ weight=10
http://yerp.org/rules/stage/
--
char *t=\10pse\0r\0dtu...@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;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: protocol is caSE sensitive, but should not be
On Tue, 25 May 2010 22:01:12 +0200
Benny Pedersen m...@junc.org wrote:
On Tue 25 May 2010 08:38:29 PM CEST, Karsten Bräckelmann wrote
On Tue, 2010-05-25 at 14:20 +0200, Benny Pedersen wrote:
i see spam mails that using Http://example.com
Yes, it is a known issue. Fixed in SVN already, and will be shipped
with the next release 3.3.2.
super
# save rule as 99_local_bugs_331.cf
# SA = 3.3.1
if (version == 3.003001)
uri __PROTOCOL_OK m{^https?://\w+}
meta PROTOCOL_FIX (!__PROTOCOL_OK)
describe PROTOCOL_FIX protocol in uri is not lowercase
score PROTOCOL_FIX 5.0
endif # sa 3.3.1 only i hope
above rule is a imidate fix until 3.3.2, works for me
IMO something like this should be added via sa-update and left there as
long as spammers are doing this - not just until 3.3.2 is released.
RE: Arabic Spam
From: Jason Bertoch [mailto:ja...@i6ix.com]
Sent: Wednesday, May 26, 2010 3:34 PM
On 2010/05/25 7:02 PM, Karsten Bräckelmann wrote:
On Wed, 2010-05-26 at 10:35 +1200, Jason Haar wrote:
Not as far as ok_locales and the respective CHARSET_FARAWAY rules are
concerned, IIRC. They have been written long ago to trigger on the
char-sets used. They don't detect the char-set based on the actual
payload.
So where does that leave us? With the need for an update or addition
to
the FARAWAY rules? Also, what's the deal with normalize_charset? Can
that have any impact on these cases where language/locale isn't
detected?
Jason, I may be completely wrong, but this is what I get grepping
'normalize_charset' in 3.3.1:
Util/DependencyInfo.pm: desc = 'If you plan to use the normalize_charset
config setting to detect
Conf.pm:=item normalize_charset ( 0 | 1)(default: 0)
Conf.pm:setting = 'normalize_charset',
Conf.pm: $self-{parser}-lint_warn(config: normalize_charset
requires Perl 5.8.5 or later);
Conf.pm: $self-{parser}-lint_warn(config: normalize_charset
requires HTML::Parser 3.46 or later);
Conf.pm: $self-{parser}-lint_warn(config: normalize_charset
requires Encode::Detect);
Conf.pm: $self-{parser}-lint_warn(config: normalize_charset
requires Encode);
Conf.pm: $self-{normalize_charset} = 1;
You may see {normalize_charset} can be set. But... where is it used, then?
It may be it is used in a way I can't catch with grep, tough...
Anyway, according to perldoc, normalize_charset would allow detecting the
character set used in a text content (which I believe is what you are looking
for) and eventually convert the text to unicode.
Now, to me the encoding detection phase is probably less than an issue here,
because a wrong encoding specified in the content's header would impair
readability of the spam text by the recipient, which is counter-productive to
spammers. So, the really used encoding is probably always specified in the
header and you may use it to score mail with foreign encodings right now.
I don't believe this is going to make any difference anyway, since nowadays
most legit mail *and* spam are moving toward utf-8 (which is probably the same
encoding used in the sample you supplied). You would end having a less than
useful rule, then.
You instead may want to guess the *language* used. Textcat is the reply if you
are looking for this. But please note its algorithm is a statistic approach to
the language detection problem: it often detects a text as being in more than
one language, especially when the sample is too short and/or when it is too
polluted with foreign or (intentionally) mistyped words.
Regards,
Giampaolo
Re: url spam from Hotmail
On 05/26/2010 05:29 PM, Karsten Bräckelmann wrote: Also, these Hotmail injected footers always use long-ish URIs with a path, no? In that case, a meta with __URI_NO_PATH could help. Something like this. uri __URI_NO_PATH m~^https?://[^/]+/?$~ That's possibly a good idea. I was thinking of trying to collate all known Hotmail Signature/footer URIs and do a meta for Hotmail with URI other than those that commonly appear in Hotmail footers. In the end I just decided From Hotmail was worth 3 points and whitelisted the 20 or so known hotmail sender addresses that appear in my logs.
RE: protocol is caSE sensitive, but should not be
Yes, it is a known issue. Fixed in SVN already, and will be shipped with the next release 3.3.2. when will 3.3.2 be pushed out? - rh
RE: protocol is caSE sensitive, but should not be
On Wed, 2010-05-26 at 11:14 -0700, R-Elists wrote:
Yes, it is a known issue. Fixed in SVN already, and will be
shipped with the next release 3.3.2.
when will 3.3.2 be pushed out?
We're gearing up towards a release. See the dev list. ;)
--
char *t=\10pse\0r\0dtu...@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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Confused Spamassin Postfix Procmail
Hello List Folks, I have used procmail in the past to move mail to a spam file on the server but I am wondering if there is another way. I found http://wiki.apache.org/spamassassin/IntegratedSpamdInPostfix?action=fullsearchcontext=180value=move+spam+to+foldertitlesearch=Titles and used that to setup spamassassin 3.3.1 from the download. It is working but I want the detected spam to move to a folder and not be delivered. Is there a way to do this without procmail? This is my email server that is for me and a handful of others. Thanks, Robert A. Ober
Re: protocol is caSE sensitive, but should not be
On Wed 26 May 2010 07:39:53 PM CEST, RW wrote
# save rule as 99_local_bugs_331.cf
# SA = 3.3.1
if (version == 3.003001)
uri __PROTOCOL_OK m{^https?://\w+}
meta PROTOCOL_FIX (!__PROTOCOL_OK)
describe PROTOCOL_FIX protocol in uri is not lowercase
score PROTOCOL_FIX 5.0
endif # sa 3.3.1 only i hope
above rule is a imidate fix until 3.3.2, works for me
IMO something like this should be added via sa-update and left there as
long as spammers are doing this - not just until 3.3.2 is released.
it just hits on no url aswell, and i dont know how to solve this :(
--
xpoint http://www.unicom.com/pw/reply-to-harmful.html
Re: Yerp connection issues
On Wed, 26 May 2010, Karsten Br?ckelmann wrote: The correct answer to both these statements is -- because it is in the mirrors list. ;) $ lynx -dump http://yerp.org/rules/MIRRORED.BY http://yerp.org:8080/rules/stage/ weight=10 http://yerp.org/rules/stage/ ...a botched attempt to set up Coral caching? It seems to me that should probably be: http://yerp.org.nyud.net:8080/rules/stage/ weight=10 http://yerp.org/rules/stage/ -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- You are in a maze of twisty little protocols, all written by Microsoft. -- 5 days until Memorial Day - honor those who sacrificed for our liberty
Re: Yerp connection issues
On 05/26/2010 07:32 PM, John Hardin wrote: On Wed, 26 May 2010, Karsten Br�ckelmann wrote: The correct answer to both these statements is -- because it is in the mirrors list. ;) $ lynx -dump http://yerp.org/rules/MIRRORED.BY http://yerp.org:8080/rules/stage/ weight=10 http://yerp.org/rules/stage/ ...a botched attempt to set up Coral caching? It seems to me that should probably be: http://yerp.org.nyud.net:8080/rules/stage/ weight=10 http://yerp.org/rules/stage/ I do not suggest that. Coral Cache does not play nicely with sa-update from my experiences (I seem to recall Justin saying the same a while ago). Since yerp is Justin's, I presume it's a different sort of experiment.
