Stopping HTML Spam mail using your own address
Does anyone know how to stop this menace? -- Member - Liberal International This is doc...@nl2k.ab.ca Ici doc...@nl2k.ab.ca God, Queen and country! Beware Anti-Christ rising! Merry Christmas 2008 NOT 2o8 and Happy New Year 2009 NOT 2o9 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: Stopping HTML Spam mail using your own address
On Fri, December 26, 2008 13:48, The Doctor wrote: > Does anyone know how to stop this menace? http://www.arschkrebs.de/postfix/postfix_restriction_classes3_en.shtml -- Benny Pedersen Need more webspace ? http://www.servage.net/?coupon=cust37098
Re: Bayes-SQL improvements
so you're basically sharding the bayes_token tables... could you open
a bug on the SpamAssassin bugzilla with this patch? thanks!
--j.
Thorsten Meinl writes:
>--nextPart9059977.pG6Pp7397c
>Content-Type: multipart/mixed;
> boundary="Boundary-01=_oj8UJ9IS8rBJw6M"
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline
>
>--Boundary-01=_oj8UJ9IS8rBJw6M
>Content-Type: text/plain;
> charset="iso-8859-15"
>Content-Transfer-Encoding: quoted-printable
>Content-Disposition: inline
>
>Hi all,
>
>We have an installation of Spamassassin that serves about 2000 users. Their=
>=20
>Bayes-data is stored inside a Postgres database which is of fairly large=20
>size, the bayes_token table holds about 100 million rows. This often leads =
>to=20
>high loads on the machine, especially if bayes_expire is running. Therefore=
> I=20
>wrote a patch to Spamassassin (3.2.4) that splits the bayes_token table int=
>o=20
>several tables. Which user is contained in which table is looked up from=20
>bayes_vars which has an additional column "token_table". New user are=20
>automatically assigned to one table by using their name's CRC32 checksum=20
>(could have been any other but this one was easiest as it gives an int whic=
>h=20
>can be used to derive a simple number for the token table). This patch lead=
>=20
>to considerably lower loads on the machine and bayes_expire now only takes=
>=20
>about 5 hours instead of 20 before when using 10 instead of 1 table.
>The patch is attached, if the developers feel that it is worth integrating=
>=20
>into the distribution, they are free to do so.
>
>Cheers,
>
>Thorsten
>
>--Boundary-01=_oj8UJ9IS8rBJw6M
>Content-Type: text/x-diff;
> charset="iso-8859-15";
> name="spamassassin-3.2.4-r1-token-table.patch"
>Content-Transfer-Encoding: quoted-printable
>Content-Disposition: attachment;
> filename="spamassassin-3.2.4-r1-token-table.patch"
>
>diff -ur Mail-SpamAssassin-3.2.4.orig/lib/Mail/SpamAssassin/BayesStore/MySQ=
>L.pm Mail-SpamAssassin-3.2.4/lib/Mail/SpamAssassin/BayesStore/MySQL.pm
>=2D-- Mail-SpamAssassin-3.2.4.orig/lib/Mail/SpamAssassin/BayesStore/MySQL.p=
>m 2008-01-05 22:10:35.0 +0100
>+++ Mail-SpamAssassin-3.2.4/lib/Mail/SpamAssassin/BayesStore/MySQL.pm 2008-=
>12-21 20:29:57.265157170 +0100
>@@ -75,7 +75,7 @@
> my $too_old =3D $vars[10] - $newdelta; # tooold =3D newest - delta
>=20
> # if token atime > newest, reset to newest ...
>=2D my $sql =3D "UPDATE bayes_token SET atime =3D ?
>+ my $sql =3D "UPDATE $$self{_token_table} SET atime =3D ?
> WHERE id =3D ?
> AND atime > ?";
>=20
>@@ -89,7 +89,7 @@
> }
>=20
> # Check to make sure the expire won't remove too many tokens
>=2D $sql =3D "SELECT count(token) FROM bayes_token
>+ $sql =3D "SELECT count(token) FROM $$self{_token_table}
>WHERE id =3D ?
> AND atime < ?";
>=20
>@@ -124,7 +124,7 @@
> }
> else {
> # Do the expire
>=2D$sql =3D "DELETE from bayes_token
>+$sql =3D "DELETE from $$self{_token_table}
> WHERE id =3D ?
>AND atime < ?";
>=20
>@@ -146,7 +146,7 @@
> last_atime_delta =3D ?,
> last_expire_reduce =3D ?,
> oldest_token_age =3D (SELECT min(atime)
>=2D FROM bayes_token
>+ FROM $$self{_token_t=
>able}
> WHERE id =3D ?)
> WHERE id =3D ?";
>=20
>@@ -415,7 +415,7 @@
>=20
> # shortcut, will only update atime for the token if the atime is less th=
>an
> # what we are updating to
>=2D my $sql =3D "UPDATE bayes_token
>+ my $sql =3D "UPDATE $$self{_token_table}
> SET atime =3D ?
> WHERE id =3D ?
> AND token =3D ?
>@@ -477,7 +477,7 @@
>=20
> return 1 unless (scalar(@{$tokens}));
>=20
>=2D my $sql =3D "UPDATE bayes_token SET atime =3D ? WHERE id =3D ? AND tok=
>en IN (";
>+ my $sql =3D "UPDATE $$self{_token_table} SET atime =3D ? WHERE id =3D ? =
>AND token IN (";
>=20
> my @bindings =3D ($atime, $self->{_userid});
> foreach my $token (@{$tokens}) {
>@@ -538,7 +538,7 @@
> # cleanup was needed, go ahead and clear the cleanup flag
> $self->{needs_cleanup} =3D 0;
>=20
>=2D my $sql =3D "DELETE from bayes_token
>+ my $sql =3D "DELETE from $$self{_token_table}
> WHERE id =3D ?
> AND spam_count <=3D 0
> AND ham_count <=3D 0";
>@@ -616,7 +616,7 @@
> return 0;
> }
>=20
>=2D $rows =3D $self->{_dbh}->do("DELETE FROM bayes_token WHERE id =3D ?",
>+ $rows =3D $self->{_dbh}->do("DELETE FROM $$self{_token_table} WHERE id =
>=3D ?",
> undef,
> $self->{_userid});
> unless (defined($rows)) {
>@@ -785,7 +785,7 @@
> # counts may have both reached 0
> $self->{needs_cle
Re: Stopping HTML Spam mail using your own address
The Doctor a écrit : > Does anyone know how to stop this menace? > Post a sample to pastebin so that we see which one(s) make it to your inbox. if your server does not need to allow unauthenticated access to your users, then you can configure your MTA to block such mail except from authenticated users or from trusted networks. This may break forwarding so make sure your users don't rely on forwarding (j...@yourdomain sends mail to j...@outside, which happens to have a .forward to j...@yourdomain).
A lot of spams go through, see example
http://igor.chudov.com/tmp/spam005.txt I get a lot of these, all seemingly sent by the same software and the same person, any way of filtering them out? i
Re: A lot of spams go through, see example
On Fri, December 26, 2008 20:06, Igor Chudov wrote: > http://igor.chudov.com/tmp/spam005.txt > > I get a lot of these, all seemingly sent by the same software and > the same person, any way of filtering them out? add the domain to http://uribl.com/ (you need a login there) currently http://newyearonline.info/ is not uribl listed please do if this is spam for you and you are sure you did not signup on that site your spamassassin learn it as ham :( can you make a spamassassin 2>&1 -D -t msg > spamtest.log and paste spamtest.log to http://igor.chudov.com/tmp/ ? -- Benny Pedersen Need more webspace ? http://www.servage.net/?coupon=cust37098
Re: A lot of spams go through, see example
Igor Chudov wrote:
> http://igor.chudov.com/tmp/spam005.txt
>
> I get a lot of these, all seemingly sent by the same software and the
> same person, any way of filtering them out?
>
The sending IP is currently blacklisted on FiveTenSig and ivmSIP/24.
Both of these are best used as "scoring" lists and not for outright
blocking. (though ivmSIP/24 could generally be scored rather high...
probably just below threshold.). Even when not used for outright
blocking, using either or both of these might have put the spam "over
the top" in combination with other things.
(Note that some consider FiveTenSig too risky to even score on. I
personally find FiveTenSig effective when adding about a point to the
spam score. But it may be that I'm somewhat insolated from FiveTenSig
FPs due to my vast IP whitelist?)
The domain name used by the spammer ("newyearonline DOT info") is NOT
listed on either surbl or uribl (at the time that I type this), but was
blacklisted on ivmURI almost exactly two minutes *before* the spam
sample you provided reached your server. However, propagations issues
would have probably made this a just-barely-missed spam in terms of
ivmURI's ability to block this. Still, that ivmURI caught it so early is
noteworthy. It may me that ivmURI might be helpful for others of this
series of spams.
One thing is for sure, you are getting the tip edge of some
hard-to-catch snowshoe spam. You probably have some addresses at the
very beginning of some snowshoe spammer's distribution list.
--
Rob McEwen
http://dnsbl.invaluement.com/
r...@invaluement.com
+1 (478) 475-9032
Re: A lot of spams go through, see example
At 11:06 26-12-2008, Igor Chudov wrote: http://igor.chudov.com/tmp/spam005.txt I get a lot of these, all seemingly sent by the same software and the same person, any way of filtering them out? Autolearning is categorizing that email as ham because of the zero score. Turn off autolearning or reduce the score for autolearning ham until you fix this problem. As a quick fix, add a header rule to catch the FreeCreditReports360.com in the From header. Regards, -sm
Re: sa-update damages existing SA installation
>> DNS seems to have been reporting 709395 as current for about eight weeks HK> If you want more up-to-date protection, use latest SVN (3.3). That's where HK> the development happens. It's been working fine here for a long time. All I know is I have $ crontab -l 33 3 * * * PATH=$HOME/bin:$PATH sa-update What should I now put there instead?
Re: sa-update damages existing SA installation
On Sat, Dec 27, 2008 at 04:31:48AM +0800, jida...@jidanni.org wrote: > >> DNS seems to have been reporting 709395 as current for about eight weeks > > HK> If you want more up-to-date protection, use latest SVN (3.3). That's where > HK> the development happens. It's been working fine here for a long time. > > All I know is I have > $ crontab -l > 33 3 * * * PATH=$HOME/bin:$PATH sa-update > What should I now put there instead? If SVN does not ring a bell, then better stick with the official version. :) Nothing you can do if no one pushes updates.
Re: sought rules updates
m> http://www.netoyen.net/sa/sa-update.sh.txt m> http://www.netoyen.net/sa/channel.conf They give 403 Forbidden.
Re: "I have a new email address!" spam
m> those I looked at triggered JM_SOUGHT_FRAUD_1. so make sure you use the m> sought channel in your sa-update. OK, I did all the research to find what it might be that you were talking about. I completed the steps (some of them exposing how sa-update fails to catch a bumbling user): $ wget http://yerp.org/rules/GPG.KEY $ sa-update -D --import GPG.KEY $ sa-update -D sought.rules.yerp.org $ sa-update -D --no-gpg sought.rules.yerp.org $ sa-update -D --channel sought.rules.yerp.org And at long last, finally, of course all was for naught: 403 Forbidden Forbidden You don't have permission to access /rules/stage/320729494.tar.gz on this server.
Re: sought rules updates
jida...@jidanni.org a écrit : > m> http://www.netoyen.net/sa/sa-update.sh.txt > m> http://www.netoyen.net/sa/channel.conf > They give 403 Forbidden. should be fixed now. sorry for the annoyance.
Re: "I have a new email address!" spam
jida...@jidanni.org a écrit : > m> those I looked at triggered JM_SOUGHT_FRAUD_1. so make sure you use the > m> sought channel in your sa-update. > > OK, I did all the research to find what it might be that you were > talking about. > > I completed the steps (some of them exposing how sa-update fails to > catch a bumbling user): > $ wget http://yerp.org/rules/GPG.KEY > $ sa-update -D --import GPG.KEY > $ sa-update -D sought.rules.yerp.org > $ sa-update -D --no-gpg sought.rules.yerp.org > $ sa-update -D --channel sought.rules.yerp.org > > And at long last, finally, of course all was for naught: > > 403 Forbidden Forbidden You don't > have permission to access /rules/stage/320729494.tar.gz on this > server. try again.
Re: A lot of spams go through, see example
Igor Chudov schrieb: http://igor.chudov.com/tmp/spam005.txt I get a lot of these, all seemingly sent by the same software and the same person, any way of filtering them out? i perhaps you can check it whith http://www.openrbl.org and then you can modificate your config on your mail server
Re: "I have a new email address!" spam
jida...@jidanni.org wrote: m> those I looked at triggered JM_SOUGHT_FRAUD_1. so make sure you use the m> sought channel in your sa-update. OK, I did all the research to find what it might be that you were talking about. I completed the steps (some of them exposing how sa-update fails to catch a bumbling user): $ wget http://yerp.org/rules/GPG.KEY $ sa-update -D --import GPG.KEY $ sa-update -D sought.rules.yerp.org $ sa-update -D --no-gpg sought.rules.yerp.org $ sa-update -D --channel sought.rules.yerp.org And at long last, finally, of course all was for naught: 403 Forbidden Forbidden You don't have permission to access /rules/stage/320729494.tar.gz on this server. It does that from time to time (well, quite frequently lately) - try again later and it should succeed :-)
what's the big risk with sa-update --nogpg?
So what's the worst thing that could happen to me with sa-update --nogpg? Just a little more spam getting through? Ha! > If you would just follow instructions, you wouldn't need --nogpg Yes, well, let's just say things didn't work out, and we want to use --nogpg just for that risky feel. Like smoking cigarettes or something. So what's the worst thing that could happen, our mailbox getting cancer?
Re: A lot of spams go through, see example
SM wrote: At 11:06 26-12-2008, Igor Chudov wrote: http://igor.chudov.com/tmp/spam005.txt I get a lot of these, all seemingly sent by the same software and the same person, any way of filtering them out? Autolearning is categorizing that email as ham because of the zero score. Turn off autolearning or reduce the score for autolearning ham until you fix this problem. Yes, and manually train Bayes with them so that Bayes will catch them in future. I manually train Bayes on ALL spam passing through the system (as well as any misclassified ham) as autolearning misses many of the more difficult to catch spam examples. On my system this example fails SPF and I see URIBL_BLACK is now catching it too.
Re: sa-update damages existing SA installation
HK> If SVN does not ring a bell, Oh, you mean like the example on http://svn.savannah.gnu.org/viewvc/trunk/grub2/docs/grub.texi?root=grub&view=log $ svn co svn://svn.sv.gnu.org/grub/trunk/grub2/docs/grub.texi svn: URL 'svn://svn.sv.gnu.org/grub/trunk/grub2/docs/grub.texi' refers to a file, not a directory HK> then better stick with the official version. :)
Re: what's the big risk with sa-update --nogpg?
jida...@jidanni.org a écrit : > So what's the worst thing that could happen to me with sa-update > --nogpg? Just a little more spam getting through? Ha! > >> If you would just follow instructions, you wouldn't need --nogpg > > Yes, well, let's just say things didn't work out, and we want to use > --nogpg just for that risky feel. Like smoking cigarettes or > something. So what's the worst thing that could happen, our mailbox > getting cancer? not clear whether you are asking for information or whether this is ironic. I'll assume the former. If your DNS is poisoned, you may get updates from another server. if there is a vulnerability in SA that can be triggered by specific rules, then you just opened your server to such attacks. you may say that attackers could own a channel server. but: - it is reasonable to assume that channel servers are "reasonably well run" - channels are used by a lot of people. so an attack on the channels will be detected sooner than an attack on your server ... Ok, that may look theoritical. but since it is easy to use sa-update without --nogpg, there is no point to use --nogpg. (The 403 problems you had have nothing to do with gpg.) PS. backscatter with supp...@dss.dounsix.local Unrouteable address has started again. I now blocked .orcon.net.nz (I am too lazy to find a "more appropriate" way). If a list admin could find the guilty member and remove him...
'sought' rules take three times longer to run
OK, I have just finished $ sa-update -D --no-gpg --channel sought.rules.yerp.org And would just like to warn other users that 'sought' rules take three times longer: $ time spamassassin --local -t < a_typical_spam_message > /dev/null real0m14.081s user0m13.489s sys 0m0.588s Up from real0m4.954s user0m4.836s sys 0m0.112s > you can sa-compile them, perhaps Well, just figuring out sa-update -D --no-gpg --channel sought.rules.yerp.org was hard enough.
Re: what's the big risk with sa-update --nogpg?
On Fri, December 26, 2008 22:44, jida...@jidanni.org wrote: > So what's the worst thing that could happen, our mailbox > getting cancer? cheers -- Benny Pedersen Need more webspace ? http://www.servage.net/?coupon=cust37098
Re: what's the big risk with sa-update --nogpg?
The point of the GPG sig check is to verify the authenticity of the source of the rules you're downloading. To get in the frame of mind as to what it means to skip this, consider what it would mean to have an unknown (obviously malicious) person masquerade as your wife/husband for a while. What might happen? If it goes undetected, there's probably very little you wouldn't reveal to them, little you wouldn't do for them, and they could do almost anything to you. Let's see... worst case scenario... Someone poisons the DNS caches near you (given the fairly recently announced huge vulnerability here, it would be a good idea security-wise to consider this "trivial"). Alternatively, someone cracks one of the channel servers directly, or fools them into accepting illicit rules. Your sa-update downloads the bad rules (either from the right server that has been compromised, or from the wrong server altogether). You're not checking the GPG key, so it happily downloads and installs the tainted rules. These rules do a few things: 1) They deliberately score all emails with big negative scores, thus destroying your spam filtering completely until you sort it out. This might be a bit too detectable for them, so instead maybe they settle for altering the scores on all the stock rules, making all sorts of things wrong. Either way, your filtering is going to be bad for a while. Really bad. Maybe they invert all the scores... scoring spam low and ham high. 2) Since you're basically downloading code that SA will run, let's say they've discovered a vulnerability in SA or Perl that allows them to run arbitrary perl code from these rules. They do so, and the arbitrary code they run downloads a rootkit and opens a reverse shell on a random port. The attacker connects to it and is logged in as root on your SA server. They use this hole to listen in on all traffic flowing through this box and in a short while have acquired all sorts of private information. They exploit any IP-based trust relationships it has with your other workstations/servers. Your whole network (or at least the part containing the SA server) is rootkitted, botnetted, and initiates mass spamming and worm propagation to the Internet. A few systems are completely destroyed (formatted, registries corrupted, whatever). In short, your entire IT infrastructure is completely hosed because you weren't checking the authenticity of code you were downloading and running on a regular basis. Okay, so (2) is a bit far-fetched. There's nothing there that isn't doable by anyone who cared enough to do it though. This might be fun to do on a honeypot machine, but it's not something I'd do willingly on any machine I was actually using for a legitimate purpose. Downloading and running unknown/untrusted code is just... a bad idea. :) Jake On Fri, Dec 26, 2008 at 2:44 PM, wrote: > So what's the worst thing that could happen to me with sa-update > --nogpg? Just a little more spam getting through? Ha! > >> If you would just follow instructions, you wouldn't need --nogpg > > Yes, well, let's just say things didn't work out, and we want to use > --nogpg just for that risky feel. Like smoking cigarettes or > something. So what's the worst thing that could happen, our mailbox > getting cancer? >
Re: 'sought' rules take three times longer to run
I took a look at Mail::SpamAssassin::Plugin::Shortcircuit, but what I really want to do is "if it is ham, run it through the expensive 'sought' extra tests, to see if it really is ham." I.e., if the end result is below required_score, continue on into the "sought" tests. Probably the only way to do that is via .procmailrc :0fw |spamassassin --cf 'Do not run sought-rules' :0 *^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* Mail/almost-certainly-spam/ :0 *^X-Spam-Status: Yes Mail/probably-spam/ :0fw |spamassassin :0 *^X-Spam-Status: Yes Mail/probably-spam/ The only problem (besides 'house of cards') is that there is no way to do --cf 'Do not run sought-rules' on the first spamassassin run. One must instead tamper with the files sa-update --channel sought.rules.yerp.org gets, removing sought_rules_yerp_org.cf and putting its contents into a --cf string on the second spamassassin run, thus complicating future sa-update runs.
