Re: thanks to thinking people.

[Brian Godette]

 On 7/22/2010 2:23 PM, Ted Mittelstaedt wrote:



On 7/22/2010 11:29 AM, Benny Pedersen wrote:

On tor 22 jul 2010 20:03:18 CEST, Charles Gregory wrote

A forged sender looks no different than a legitimate sender. Postfix
would have no way to be 'smart' about this (except for some instances
of SPF fail, but then why 'bounce'? Why not reject?).


and why not show logs ?

bounces is newer external since postfix change sender to mailer-daemon
with will end in some mailbox local if it was sent from local ip, if it
sent remotely its just a reject that makes the remote mta do the bounce,
but it will be the same that happend remotely when it bounces

if bounces go external then the mta is not configured correct, and it
can be other reasons it does bounce then just not used a reject



Nonsense.

You have internal users.

They are using auth-smtp.

One of those "internal" users is running a laptop

He takes laptop to starflucks and joins the wireless

He sends mail through your server.

How exactly does Postfix "know" that he is an "internal"
user.

Spammer in the wild sees a mail from your user with a
senders address of "ilovec...@example.com" originating
from your smtp-auth system

Spammer in the wild guesses user is using a UID of
"ilovecats" and a password of "pussy"

Spammer in wild authenticates into your auth-smtp
server and spams the world with a forged senders
address.

How exactly does Postfix "know" the difference between
Spammer and the internal user on the laptop at Starflucks?

The notion of "bouncing mail to inside users" is a joke.

Ted



You don't BOUNCE you SMTP REJECT. No DSNs, no backscatter, and any FP 
from a legit user ends up with a support call to the correct party. If 
the outbound message does not exceed your SMTP REJECT level you let it 
go out WITHOUT MODIFICATION, no markup, no nothing.

Re: thanks to thinking people.

[Brian Godette]

 On 7/20/2010 1:01 PM, Ted Mittelstaedt wrote:


You are mistaken.  I'm a proponent of port 25 blocks.  What I
am saying is that port 25 blocks work far better than attempting to
spamfilter outbound mail.  It is the other guy who is arguing that
spamfiltering outbound mail is better than port 25 blocks.

Ted

 You need to actually read what I'm writing instead of skimming. The 
subjects being discussed are outbound mail from your own MTA, not 
joe-user's IP address, your own mail server's IP address. How internal 
and/or authenticated users with an infection can cause your MTA to end 
up on blacklists (especially trap fed) regardless of your rate based 
tripwires/log scanning. And how dumb-bots nearly never send outbound (to 
the rest of the world) through your MTA, only the smarter ones that can 
use SMTP-AUTH usually do that. That all leads to needing something a bit 
more than log scanning and rate limiting.


Again, blocking outbound 25 from everything but your own MTA is all well 
and good for containing internal outbreaks from causing everyone else 
grief, but it has little impact on keeping your own MTA clean.

Re: thanks to thinking people.

[Brian Godette]

 On 7/19/2010 4:01 PM, RW wrote:

On Mon, 19 Jul 2010 13:25:26 -0700
Ted Mittelstaedt  wrote:



It's been our experience that spam-scanning outbound mail causes a lot
more problems than setting up mailserver monitoring and being
responsive to it.  Sooner or later one of your customers is going to
call you and bitch because their mail ended up in their
coorespondents spam folder due to them using HTML or including a bad
URL and if it was your server that tagged it spam,

What's the point of adding spam-filtering headers or markup to outgoing
mail?

Indeed, the point would be to score and SMTP reject outbound over some score, 
anything under would be sent unmodified. If it's a FP your own user contacts 
you.

Re: thanks to thinking people.

[Brian Godette]

 On 7/19/2010 2:25 PM, Ted Mittelstaedt wrote:



On 7/19/2010 12:56 PM, Brian Godette wrote:

On 7/19/2010 1:29 PM, Ted Mittelstaedt wrote:



On 7/19/2010 8:43 AM, Brian Godette wrote:

On 7/15/2010 6:55 PM, Alexandre Chapellon wrote:

Hi all,

Few months ago I asked this list if using SA on outgoing smtp was a
good idea (Thread: SA on outgoing SMTP).
This thread quickly moved to "Block direct port 25 for non-mta users!
I was really afraid of doing so and didn't really wanted to go this
way.
now about 6 months later I have to say: I was a fool! Today.
After spending some time trying to find a more user-friendly way to
clean up the mess around here, I came to the conclusion that port 25
blocking on the bound of my network was inevitable.
Today it's done, and I have followed few others advices given on 
list.

I wanted to testify the benfits of good designed network for thoose
who like me are afrais of annying customer with security (even more
blocking port 25 on the limits of the network is not really annoying
for most of customers).

Thanks to Ted Mittelstaedt, Matus UHLAR, Martin Gregorie, with your
help dudes, all I have to care about now is my mailservers
configuration!

--
Alexandre Chapellon mailto:alexandre.chapel...@mana.pf>>
Mana SAS



I hope you realize you still need to deal with the issues of users 
with

weak/guessable passwords and phishing of account info as well as the
newer bots that recover account info from Outlook/Outlook
Express/Thunderbird.

Blocking outbound 25 from the rest of your network, and disallowing
submission to your MX on 25 from your network, does very little for
keeping your own MX from sending spam which is what SA on outgoing 
SMTP

would be for. It's great from a policy standpoint and contains the
"simple" bots, but for keeping your outbound from MX clean, not so 
much.




That absolutely isn't true. Yes I agree that it's possible for a
spammer to write a virus that uses the submission port and
authenticated SMTP to send mail and runs on a user's PC. But if your
running even a simple log analysis script on your mailserver and you
READ the daily reports from it, then a user that sends many tens to
hundreds of thousands of e-mails will stick out like a sore thumb.

We have NEVER had a spammer do this to one of our users. I don't know
why because it seems to me like it's an obvious way to relay spam. What
we HAVE had happen is spammers guess weak passwords and relay spam
through the webmail interface. My guess is that it's just a lot
easier to do this for them. Of course, when they do that their outgoing
spam is stamped with the username that was used to relay, and it's
very easy to detect and change the password.

So far, all the spam viruses we have encountered on user systems are
of the variety where they infect the client and attempt to relay to
port 25.

Ted


So basically you're agreeing with what I said. It stops the simple bots,
but the other stuff, not so much.



No, you said it "does very little" and I said it only "does very little"
in THEORY, but in actual practice (right now) it does a tremendous 
amount.


In actual practice it does very little for YOUR OWN MX, the simple bots 
simply do not target internal mail servers, they send direct. Which is 
why I said it's good from a policy standpoint but does nothing to 
actually prevent YOUR OWN MX from ending up on an RBL because all the 
bots that can do that don't care that you've got outbound 25 from your 
internal network blocked.




I won't rule out that the spammers won't become smarter but right now
they are stupid.  I guess there's just too many wide-open servers still
out there for them to bother trying to get around one that's been 
tightened down.



I've seen bots use smtp-auth from inside, whether it's by injecting into
O/OE or recovered auth I can't say. I've seen bots use webmail as you
have, I've also seen them use smtp-auth vs submission/ssl (587/495). But
again, that's only after they've either guessed or phished the account
info. In either case you're still left with having to scan outbound from
your own MX, and/or rate limit, or accept being RBL'd for short periods
of time being reactive to log analysis and spam reports.


If you keep on top of the logs then you won't generally be RBLed.  And 
you can run a monitoring program like Big Sister and with a bit of 
scripting you can be notifed when your server starts spamming. 
Out-of-the-box the SMTP monitor in Big Sister will alarm if the 
mailserver starts slowing down - which is customary when a spammer 
commences a large spam run.  But you can also write a script that runs 
once an hour

and monitors your mailflow and alarms if it jumps.  If your graphing
your mailflow then spam runs will create spikes that are very obvious.


At which point it's alread

Re: thanks to thinking people.

[Brian Godette]

 On 7/19/2010 1:29 PM, Ted Mittelstaedt wrote:



On 7/19/2010 8:43 AM, Brian Godette wrote:

On 7/15/2010 6:55 PM, Alexandre Chapellon wrote:

Hi all,

Few months ago I asked this list if using SA on outgoing smtp was a
good idea (Thread: SA on outgoing SMTP).
This thread quickly moved to "Block direct port 25 for non-mta users!
I was really afraid of doing so and didn't really wanted to go this 
way.

now about 6 months later I have to say: I was a fool! Today.
After spending some time trying to find a more user-friendly way to
clean up the mess around here, I came to the conclusion that port 25
blocking on the bound of my network was inevitable.
Today it's done, and I have followed few others advices given on list.
I wanted to testify the benfits of good designed network for thoose
who like me are afrais of annying customer with security (even more
blocking port 25 on the limits of the network is not really annoying
for most of customers).

Thanks to Ted Mittelstaedt, Matus UHLAR, Martin Gregorie, with your
help dudes, all I have to care about now is my mailservers 
configuration!


--
Alexandre Chapellon mailto:alexandre.chapel...@mana.pf>>
Mana SAS



I hope you realize you still need to deal with the issues of users with
weak/guessable passwords and phishing of account info as well as the
newer bots that recover account info from Outlook/Outlook
Express/Thunderbird.

Blocking outbound 25 from the rest of your network, and disallowing
submission to your MX on 25 from your network, does very little for
keeping your own MX from sending spam which is what SA on outgoing SMTP
would be for. It's great from a policy standpoint and contains the
"simple" bots, but for keeping your outbound from MX clean, not so much.



That absolutely isn't true.  Yes I agree that it's possible for a 
spammer to write a virus that uses the submission port and 
authenticated SMTP to send mail and runs on a user's PC.  But if your 
running even a simple log analysis script on your mailserver and you 
READ the daily reports from it, then a user that sends many tens to 
hundreds of thousands of e-mails will stick out like a sore thumb.


We have NEVER had a spammer do this to one of our users.  I don't know
why because it seems to me like it's an obvious way to relay spam.  What
we HAVE had happen is spammers guess weak passwords and relay spam 
through the webmail interface.  My guess is that it's just a lot

easier to do this for them.  Of course, when they do that their outgoing
spam is stamped with the username that was used to relay, and it's 
very easy to detect and change the password.


So far, all the spam viruses we have encountered on user systems are
of the variety where they infect the client and attempt to relay to
port 25.

Ted

So basically you're agreeing with what I said. It stops the simple bots, 
but the other stuff, not so much.


I've seen bots use smtp-auth from inside, whether it's by injecting into 
O/OE or recovered auth I can't say. I've seen bots use webmail as you 
have, I've also seen them use smtp-auth vs submission/ssl (587/495). But 
again, that's only after they've either guessed or phished the account 
info. In either case you're still left with having to scan outbound from 
your own MX, and/or rate limit, or accept being RBL'd for short periods 
of time being reactive to log analysis and spam reports.

Indirectly related to SA.

[Brian Godette]

 Like some people I run a small internal spamtrap of never used by real 
users addresses for use in feeding Bayes as well as reporting to Razor 
and internal IXHASH. In addition I also have a database that returns 
"550 User unknown" for all email addresses that are "dead", with the 
date they were deactivated.


My question is, at what point would one consider such an address old 
enough for inclusion into a reviewed trap for further training and 
reporting, and at what point, if it were left returning "550 User 
unknown", where it could bypass review?

Re: thanks to thinking people.

[Brian Godette]

 On 7/15/2010 6:55 PM, Alexandre Chapellon wrote:

Hi all,

Few months ago I asked this list if using SA on outgoing smtp was a 
good idea (Thread: SA on outgoing SMTP).

This thread quickly  moved to "Block direct port 25 for non-mta users!
I was really afraid  of doing so and didn't really wanted to go this way.
now about 6 months later I have to say: I was a fool! Today.
After spending some time trying to find a more user-friendly way to 
clean up the mess around here, I came to the conclusion that port 25 
blocking on the bound of my network was inevitable.
Today it's done, and I have followed few others advices given on list. 
I wanted to testify the benfits of good designed network for thoose 
who like me are afrais of annying customer with security (even more 
blocking port 25 on the limits of the network is not really annoying 
for most of customers).


Thanks to  Ted Mittelstaedt, Matus UHLAR, Martin Gregorie, with your 
help dudes, all I have to care about now is my mailservers configuration!


--
Alexandre Chapellon >

Mana SAS



I hope you realize you still need to deal with the issues of users with 
weak/guessable passwords and phishing of account info as well as the 
newer bots that recover account info from Outlook/Outlook 
Express/Thunderbird.


Blocking outbound 25 from the rest of your network, and disallowing 
submission to your MX on 25 from your network, does very little for 
keeping your own MX from sending spam which is what SA on outgoing SMTP 
would be for. It's great from a policy standpoint and contains the 
"simple" bots, but for keeping your outbound from MX clean, not so much.

Re: giftcardsurveys.us.com

[Brian Godette]

Johnson, S wrote:
> I’ve done really good with blocking spam up until this one…
> 
> It looks like a “legitimate” e-mailer from both the system perspective
> and the system perspective.
> 
> When I look at my logs, the servers are reporting their domains
> correctly so their mailserver looks ok when attacking to my server. 
> Each email seems to be coming from numerous different servers so I can’t
> block on server address…
> 
> They say don’t do “spamming” but the area in the email that contains the
> link to remove yourself/unsubscribe is an image so you can’t click on
> it, instead you have to type it in by hand.  I normally don’t proceed
> down that path but I decided to try it anyway.  When I put in the email
> address of the user that was being sent these survey offers for gift
> cards I got a message stating please allow 10 days for removal which
> makes me think they are not legit.
> 
> The question is… Since everything is configured on their servers ok and
> the messages don’t contain words I can really create a rule on..  It’s
> not just home depot, it’s KFC, Macy’s and numerous other retailers. 
> Anyone have any ideas on how to block these?  The poor user is getting
> about 10 / day.
> 
> Thanks,
> 
>   Scott

Welcome to snowshoe spam.

The only effective defense I've seen against this is to have a greylist
with more than an hour temp fail time so each new spam run has time to
hopefully show up in DCC and possibly RAZOR/Pyzor/Spamcop/URIBL.

The content really can't be matched against since the URIs are old
enough to not be in something like DOB, haven't been used before so
aren't in the URIBLs, and look like real rebate/coupon mail so
BAYES/phrase matching is useless unless you want to nuke or manually
whitelist the legit stuff. The websites are of course a CC scam/PI phish.

You can block the servers, a class C or whois allocation at a time, if
you're willing to deal with the occasional "why am I not getting mail
from ABC who's decided to host with sleazy hosting XYZ" if the space
ever gets reassigned.

Re: Blacklist mail

[Brian Godette]

Johnson, S wrote:
> The only reason I ask about if I should "learn" the messages is that
> my users have a hard time putting good email into the good email
> folder.  Everyone is quick to put in spam messages though.  My filter
> is getting about 50 to 1 spam to ham right now.  Everything I've
> read/heard states that I should try to be close to 1 to 1 for optimum
> spam hits.  If I add this into the learn then I'll be shooting up the
> filter to close to 100 to 1 (or more).  Should I be worried about
> that?
> 

About that only thing you can do to get more ham learned, without
invading your user's illusion of email privacy, is turn on auto-learning
and adjust bayes_auto_learn_threshold_spam to something reasonably high
since you have a user driven spam feed, and maybe adjust
bayes_auto_learn_threshold_nonspam to be a little more free with what it
considers ham (shouldn't need to tho).

Re: Question - How many of you run ALL your email through SA?

[Brian Godette]

Marc Perkel wrote:
> As opposed to preprocessing before using SA to reduce the load. (ie. 
> using blacklist and whitelist before SA)
> 

We don't.

We use a locally modified MaRBL that uses weighted scoring, RHSBLs
against helo/sender domain/reverse, and the BOTNET plugin (each
meta-rule gets its own weight), then greylisting (gld policy server),
then clamav w/sane+msrbl, then finally SA. All this does for us is
reduce the load on the spamd servers and bayes database, the amount of
marked spam that would actually get to a user that /dev/null's over a
certain score does not change significantly.

This brings the detected spam rate to about 2% of all delivery attempts
or 14.8% of what SA sees; what the user sees may be much less depending
on what they set their /dev/null score to.

We used to use just greylisting, but it was becoming far less effective
over time (~8 months ago), by adding weighted rbl lookups to reject at
SMTP time and then greylist the rest, the amount of spam as seen by SA
dropped to 12% of what it was with just greylisting alone.

At some point we should add in SPF checks to MaRBL and maybe integrate
p0f from its latest release.

Re: RBL tests on MTA vs. RBL rules on SA

[Brian Godette]

Oenus Tech Services wrote:
> After much testing, we have decided to put the RBLs on Postfix for
> performance reasons. Before checking with those RBLs, our system does
> EHLO checks against a known-spammer blacklist database as well to filter
> the most obvious cases. Then we use zen.spamhaus.org,
> safe.dnsbl.sorbs.net, and bl.spamcop.net, in this order. Next we do

safe.dnsbl.sorbs.net includes new.spam.dnsbl.sorbs.net which is not very
safe at all. bl.spamcop.net isn't all that safe either. Both will
routinely hit on the free email providers and major ISPs outgoing MTAs.
This is because both have automatic systems generating them.

Its fairly hard for any sizable ISP or mail provider to not constantly
be going on and off new.spam and spamcop lists given harvested/weak
passwords and the newer bots that will use the MTA configured in the
default mail client of the zombied system including being able to do
SMTP-AUTH.

"safe" sorbs would be something along the lines of:
dul.dnsbl.sorbs.net + relays.dnsbl.sorbs.net + zombie.dnsbl.sorbs.net

Re: Greylisting

[Brian Godette]

On Monday 20 November 2006 19:06, Rick Macdougall wrote:
> John Andersen wrote:
> ... the spammers are not actually
> storing the email addresses on the infected machines, they just send an
> email to go out).
>
> I'm not saying they won't do it, I'm saying they aren't doing it currently.

Actually they have been for some time as an anti-botnet surveillance measure. 
The newer spambots do a bulk download of recipients and payload, then some 
time later (hours/days?) start the run after having been disconnected from 
the controlling irc channel/web page. By the time the spam run is noticed all 
that's left is a autonomous zombie with nothing but smtp traffic.

In fact I would guess that passive spam-relays, that the spammer just connects 
to as an open relay, are less common due to a large percentage of broadband 
users being behind NATs. I'm also starting to see more "behave like a real 
MTA" as well slowly making greylisting less effective.

Re: Amazon / RFCI false positives

[Brian Godette]

Seems pretty accurate to me since I have accounts that have been 
returning "550: User Unknown" smtp rejects for 2+ years that still receive 
mail from Amazon on a weekly/monthly basis. Same thing for several airline 
mileage programs, big name stock brokerages, etc.

On Friday 03 November 2006 08:23, Tony Finch wrote:
> On Fri, 3 Nov 2006, Ralf Hildebrandt wrote:
> > * Tony Finch <[EMAIL PROTECTED]>:
> > > Amazon.co.uk was listed by RFC-Ignorant at the start of this week, and
> > > it is now scoring more than 5: DNS_FROM_RFC_DSN 2.87, DNS_FROM_RFC_POST
> > > 1.44, FROM_EXCESS_BASE64 1.05.
> >
> > Amazon.co.uk is not listed:
> > http://www.rfc-ignorant.org/tools/lookup.php?domain=Amazon.co.uk
>
> My mistake: I cited the wrong domain. Try bounces.amazon.com which they
> use in the return path of their messages (I guess for all their
> international domains)
> http://www.rfc-ignorant.org/tools/lookup.php?domain=bounces.amazon.com
>
> Tony.

Re: New bayes busting method.

[Brian Godette]

On Friday 23 June 2006 15:28, Michael Monnerie wrote:
> Are you sure about that? It would have to be a message that was ham,
> have (nearly) the same content, autolearn must be on and the message
> must have been learned. That's a lot of "if...and.." statements. I use
> sitewide bayes (hand trained), and got BAYES_99. Yes, I have autolearn
> on, but I do a lot of hand crafted training, and modified the default
> values for learn_as_(spam|ham).
>
> mfg zmi

Which basically means you've never trained or autolearned on airmiles rewards 
ham, which we happen to see a fair number of. And again, it still got flagged 
as spam, just didn't get a BAYES_99 like it would have had it not had a *real 
ham* plain text included in an html comment.

Re: New bayes busting method.

[Brian Godette]

On Friday 23 June 2006 13:24, Michael Monnerie wrote:
> On Freitag, 23. Juni 2006 20:56 Brian Godette wrote:
> > Spammer is using a ham corpus message and including the entire plain
> > text inside an HTML comment (<-- -->).
>
> Seems to be "pas problem" for SA:
> X-Spam-Status: Yes, hits=16.9 required=5.0
> tests=BAYES_99=3.5,DCC_CHECK=2.17,
> DIGEST_MULTIPLE=0.765,FORGED_RCVD_HELO=0.135,HTML_90_100=0.113,
> HTML_MESSAGE=0.001,MIME_HTML_ONLY=0.001,RAZOR2_CF_RANGE_51_100=0.5,
> RAZOR2_CF_RANGE_E8_51_100=1.5,RAZOR2_CHECK=0.5,SARE_UNI=0.591,
> SPF_NEUTRAL=1.069,URIBL_BLACK=3,URIBL_OB_SURBL=3.008 autolearn=spam
> bayes=1.
>
> mfg zmi

Uh no. It still got marked as spam here, for other reasons. However the 
spammer is trying to lower the bayes score by including a ham corpus message 
inside an HTML comment. Also note that a large amount of your score was from 
DCC, Razor, and URIBLs that didn't hit at the initial receipt of this 
message.

This is only really an issue for people who use site-wide bayes as per-user 
bayes has a lower chance of having seen true ham similar to the encapsulated 
ham.

New bayes busting method.

[Brian Godette]

So far this is the first time I've seen this be used.

Spammer is using a ham corpus message and including the entire plain text 
inside an HTML comment (<-- -->).
Return-Path: <[EMAIL PROTECTED]>
X-Original-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Received: by mailhost.idcomm.com (Postfix, from userid 89)
id 47FC810D7A269; Thu, 22 Jun 2006 21:51:36 -0600 (MDT)
X-Original-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Received: from orval.sprint.ca (unknown [209.5.194.98])
by mailhost.idcomm.com (Postfix) with ESMTP id 144D310D7A254
for <[EMAIL PROTECTED]>; Thu, 22 Jun 2006 21:51:35 -0600 (MDT)
Received: from sympatico.ca ([149.99.160.159]) by orval.sprint.ca
  (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP
  id <[EMAIL PROTECTED]>
  for <[EMAIL PROTECTED]>; Thu, 22 Jun 2006 22:01:00 -0400
Message-ID: <[EMAIL PROTECTED]>
From: "Emily_1988" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Confirmation of Membership Cancellation (ID:# 1294884376KP)
Date: 22 Jun 2006 19:00:58 -0700
MIME-Version: 1.0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Errors-To: [EMAIL PROTECTED]


http://www.ivcam.com/index.html"; target=3D"_blank=
"> Hey, [EMAIL 
PROTECTED] Me=
 On.lin.e Get [EMAIL PROTECTED] ... 

Gen. Casey: U.S. forces in Iraq to shrink
House approves weaker line-item veto
Pre-launch strike on North Korea unlikely
High court affirms sex discrimination award
San Jose mayor arrested after indictment
Canada plans to raise age of consent to 16
Spelunker's 41-year-old remains to surface
RegardsRoymand

Re: Image-only stock spam -- nice try!

[Brian Godette]

On Tuesday 17 January 2006 02:52 pm, Justin Mason wrote:
> Brian Godette writes:
> > On Tuesday 17 January 2006 01:02 pm, Justin Mason wrote:
> > > yeah, we were chatting about that on John-Graham Cumming's weblog. All
> > > I can think of is that they're attempting to evade another anti-spam
> > > product, one that uses OCR, but is secret/proprietary hence *we* don't
> > > know about it.
> >
> > Or the image could be randomly skewed to break hash based detection? Does
> > pyzor/razor/dcc even hash attachments?
>
> 1. there are many other, easier ways that spammers can break (and are
> currently breaking) image-hash schemes; colour LUT shuffling, random
> borders, random colour perturbation.

Rotation isn't any harder/easier than those. OCR vs image only spam seems like 
a logical thing to do, until one considers the processing time involved and 
how unreliable (easy to confuse/break) it is. Which is what makes me think 
rotation is just yet another hash busting method.

>
> 2. the second technique JGC posts -- whereby each line of text is cut in
> half, in two separate images -- is useless as a checksum defeating scheme,
> since the two halves would always sum to the same value; but *is* useful
> as an anti-OCR scheme.
>
> > > I'm surprised you had no XBL or SURBL hits either, btw!
> >
> > Pump & dumps don't need URLs.
>
> image spams often do -- to load the image ;)

I can't think of a current email application, including MSO/E, that still 
loads external image links by default. However considering that the target is 
uninformed/naive users, I would suppose the assumption they've actually done 
their software updates is a bit much to expect. 

As far as the current trend for inline vs external links image spam is 
concerned, I've only ever seen phishes use external links, all the 
traditional stuff (stock/pills/porn) use inline, at least as far as the stuff 
that makes it thru greylisting.
>
> --j.

Re: Image-only stock spam -- nice try!

[Brian Godette]

On Tuesday 17 January 2006 01:02 pm, Justin Mason wrote:
> yeah, we were chatting about that on John-Graham Cumming's weblog. All I
> can think of is that they're attempting to evade another anti-spam
> product, one that uses OCR, but is secret/proprietary hence *we* don't
> know about it.

Or the image could be randomly skewed to break hash based detection? Does 
pyzor/razor/dcc even hash attachments?

>
> I'm surprised you had no XBL or SURBL hits either, btw!

Pump & dumps don't need URLs.

>
> --j.

Re: Pump and dump stock Blacklist?

[Brian Godette]

On Monday 16 January 2006 04:27 pm, [EMAIL PROTECTED] wrote:
> Hi!
>
> > Im curious if there are any intitiatives to collect pump and dump stock
> > symbols and names to check against incomming spam.  I've looked around
> > but have yet to find anything.  I think some sort of database would be
> > nice to have to do lookups on and just have it check agains the body of
> > the message for the symbol and/or company name and score accordingly, and
> > maybe have tohe records expire every 3-4 weeks.
>
> Yes there are, a SARE rule is about to be released, i heard ;)
>
> Bye,
> Raymond.

Step 1: Obtain list of penny stocks
Step 2: ???
Step 3: Profit!

We all know what step 2 is unfortunately.

Re: dealing with SPF and external authenticated users

[Brian Godette]

On Tuesday 10 January 2006 01:21 am, [EMAIL PROTECTED] wrote:
> >> >What would be the correct way of dealing with this situation ? As a
> >> > workaround I have used whitelist_from_rvc [EMAIL PROTECTED], which seems
> >> > to be a great workaround, because I have rules in postfix that do not
> >> > allow external users that do NOT authenticate to send messages with my
> >> > own domain, not even to my local  users.
> >>
> >> There's nothing wrong with that solution since you have Postfix setup to
> >> refuse mail to local address from un-auth'd users.
>
> I implemented a similar setup a while ago, and it turned out that some
> legit (although suspiciously looking) mails from ebay were blocked.
> I had to whitelist ebay there..
> This particular user is no longer there, so I dont know whether ebay have
> revised these mails since
>
> Wolfgang Hamann

AFAIK ebay, paypal, and quickbooks all (can) send mail on behalf of a user 
using their (real) email address, and is one of the gotchas of SPF. My 
solution was to include ebay/paypal's SPF records in our own on the 
assumption that they're unlikely to joe-job.

Looks like we have someone doing auto-spam-reports on this list.

[Brian Godette]

[EMAIL PROTECTED] appears to be not only running this mailing 
list thru spamassassin (bad idea) but also auto-reporting any positive hits 
(incredibly bad idea).

Better late than never.

[Brian Godette]

Or maybe they're just early for next year?
--- Begin Message ---






  

  
  




  
  He's got your eyes, Dad's nose and his own busy little feet which can 
  lead to an occasional unexpected accident. But never fear, PayDayOK is 
  there with a quick and affordable cash advance whenever you need it. 
  Apply now and have funds as early as tomorrow!
  

Finance charges are calculated on the basis of $10 per $100 borrowed 
for each 14 day period, which is equivalent to an APR of 260.71%.
  
  
  


  


  
  Priceless gift ideas for Mother's Day that won't cost you a dime.
 
1. Breakfast in bed.
  Let Mom sleep late and treat her to breakfast in bed - make sure 
to 
  clean the kitchen after! Let children participate by keeping 
things 
simple with a bowl of cereal and juice.
 
2. A special poem or drawing.
  Nothing touches Mom like something personal and from the heart. A 
few 
  thoughtful words or cute picture from a younger child can totally 
make 
her day.
 
3. Picnic in the park.
Create a special "Mother's Day Picnic," and take your Mom out to the 
  park or even under a tree in the back yard to relax on a blanket 
and 
enjoy a fun assortment of goodies.
 
4. "Favor For Mom" coupon.
  The gift that gives almost as much as Mom does. Present her with a 
gift 
  coupon of your making with items such extra chores, back rubs and 
hugs. 
Sign your name to let her know that you're serious.
 The 
nicest thing about gifts like these is that they can't be bought 
at a store, and to a Mother those are memories that will last 
forever.


  

  
  





--- End Message ---

Re: Side-warning about the new proxy zombies...

[Brian Godette]

On Tuesday 08 February 2005 2:14 pm, Kenneth Porter wrote:
> --On Tuesday, February 08, 2005 11:14 AM -0700 Brian Godette
>
> <[EMAIL PROTECTED]> wrote:
> > care must be taken to have the expiry times
> > reasonable or the iptables rule lists becomes much too large and
> > eventually  chews up all available CPU.
>
> Have you seen the "ipset" stuff on the netfilter-devel list? This is a new
> set of modules that works with sets of addresses. It should allow you to
> have a much larger rejection list.

The rejection list can be pretty huge as it is, however since the script 
doesn't aggregate IP addresses there is a possibility of it becoming 
excessively large (8 figures or more) if addresses stay in the list for very 
long periods of time (months) before being expired. That's completely 
theoretical since I doubt there's 10's of millions of zombie proxies/open 
relays out there, but still expiration times that long are IMO excessive.

Re: Side-warning about the new proxy zombies...

[Brian Godette]

On Thursday 03 February 2005 4:22 pm, Matt Kettler wrote:
> At 06:13 PM 2/3/2005, Brian Godette wrote:
> >Those sorts of mail servers end up in my firewall rules till some point in
> >the
> >future.
>
> I started off using a shun on them as a short-term fix, but then went to a
> 500 error message for all mail from the server in /etc/mail/access.
>
> They seem to behave properly upon getting a 5xx and go away until a new
> spam is queued, so it's less bandwidth for me if I do that then let them
> continually try to reconnect and fail to get any answer. It also gives me
> an opportunity to bounce back a message about why I'm blocking them.

My observations indicate the opposite, they just keep trying, often very 
rapidly. Plus a silent firewall drop of SYNs behaves as a mini-tarpit, the 
thread attempting to connect to you is blocked until connect() times out.

>
> In general doing a 5xx is better than a firewall block, unless the server
> is so broken it doesn't respond to 5xx's and keeps retrying anyway.

I should probably explain how IPs end up in my mail server firewall. I use a 
slightly modified version of watch-maillog 
(http://taz.net.au/postfix/scripts/watch-maillog.pl) to automatically 
add/remove IPs based on regexs on a tailed mail log.

This stops dead any dictionary attack or any other 100% spam-source thing you 
can make your MTA log such as rejecting invalid HELOs using your MX's own IP 
or hostname(s). Yes it's kinda like grey-listing, but without the initial 
first time penalty, however care must be taken to have the expiry times 
reasonable or the iptables rule lists becomes much too large and eventually 
chews up all available CPU.

The "too many" firewall rules case is one of the modifications I made, I 
limited the max rules, removing the next due before is was supposed to 
happen.

Re: Side-warning about the new proxy zombies...

[Brian Godette]

On Thursday 03 February 2005 3:32 pm, Matt Kettler wrote:
> I encountered one ISP who's legitimate mail gateway is freaking out under
> the load of all the proxy spam.
>
> It's now retrying temp-fail messages immediately without any delay... 24+
> times per second.
>
> Since I have Sendmail set up to verify sender domains exist, a lot of spam
> gets a 451 error.. Unfortunately, this server doesn't give up. Since Monday
> they tried to deliver a small number of different messages a total of 1.6
> million times.
>
> "reject=451 4.1.8 Domain of sender address [EMAIL PROTECTED] does not
> resolve". Over and over and over again..
>
> Needless to say, my maillog is rather huge this week with about 300mb of
> the above messages tacked on top of my normal logging.
>
> Other admins might want to watch out for this kind of garbage..

Those sorts of mail servers end up in my firewall rules till some point in the 
future.

Re: Are spammers finally feeling some pain?

[Brian Godette]

On Monday 03 January 2005 01:09 pm, Andy Jezierski wrote:
> Probably not. Every year around the holidays our spam hits a yearly low
> usually the week of Christmas, then goes right back up to the previous
> levels.  I think some of the spammers may be taking a holiday break as
> well.
>
> Andy

Perhaps some of the 5437986034 zombied Windows boxes were turned off over the 
holidays? :P

Re: How to rewrite spamc in Perl

[Brian Godette]

Docs for the spamd protocol are in the source tree.
Mail-SpamAssassin-3.0.0/spamd/PROTOCOL

On Wednesday 06 October 2004 03:11 pm, [EMAIL PROTECTED] wrote:
> I'm interested in restructuring my MIMEDefang/SpamAssassin setup. 
> Currently each MIMEDefang slave carries around its own SpamAssassin object.
> I want to use spamd instead.
> I could use `spamc ...` inside mimedefang-filter but that could be
> unnecessarily expensive in process startup costs etc.
>
> Is there any documentation for the spamd client interface?  MIMEDefang can
> talk to clamd.sock directly, using the commands in man clamd, rather than
> spawning `clamdscan` processes.  I checked man spamd and man spamc but
> couldn't find anything.  I tried browsing the spamc source code but it's
> pretty hard going.
>
> Can anyone illustrate the spamc<->spamd conversation, so I can have
> MIMEDefang emulate spamc (talking to the socket directly using IO::Socket
> perl commands?)
>
> [EMAIL PROTECTED]  805.964.4554 x902
> Hispanic Business Inc./HireDiversity.com Software Engineer
> perl -e"map{y/a-z/l-za-k/;print}shift" "Jjhi pcdiwtg Ptga wprztg,"

Re: [OT] Uptime was [scan times up!]

[Brian Godette]

And I hope you're taking that opportunity to update IOS on it as well.
 
On Tuesday 05 October 2004 05:58 pm, Nate Schindler wrote:
> A sad day is coming on Thursday, I have to re-boot a router at one of our
> remote locations to install a new card.
> I always loved showing this to people who insisted that you should re-boot
> equipment periodically.
>
> anrtr1>sh ver
> Cisco Internetwork Operating System Software
> IOS (tm) 3600 Software (C3640-JS-M), Version 12.1(5)T,  RELEASE SOFTWARE
> (fc1)
> Copyright (c) 1986-2000 by cisco Systems, Inc.
> Compiled Sat 11-Nov-00 07:24 by ccai
> Image text-base: 0x60008950, data-base: 0x61476000
>
> ROM: System Bootstrap, Version 11.1(20)AA2, EARLY DEPLOYMENT RELEASE
> SOFTWARE (fc1)
>
> anrtr1 uptime is 3 years, 23 weeks, 1 day, 15 hours, 58 minutes
> System returned to ROM by power-on
> System restarted at 23:10:31 PDT Thu Apr 26 2001
> System image file is "flash:c3640-js-mz.121-5.T.bin"
>
>
> Heavy Sigh...
>
> Andy