blog.iloaf.com » Spam

Mailchannels TrafficControl update

Chris — Mon, 02 Jun 2008 20:02:59 +0000

Having spent an interesting evening chatting with Dave from MailChannels, I’ve now spent well over a week traffic shaping SMTP for some 200k connections and it’s time for a few observations:

The installer is very Solaris-a-like. I’m not a fan. I do remember a few far worse, but only a few

Upgrades are somewhat clunky, since the installer A) takes settings saved in ~/.something rather than the running config (weird) & B) buggers about with your config file removing all those logical line breaks you put in to define sections once you enabled some of the disabled features.

I did wonder why the hell it wasn’t a direct replacement smtpd for postfix at one point. XCLIENT functionality might cut the mustard though.

FP’d disastrously on a finance site I use quite a bit. I had to whitelist it

It annoyed my kids by FP’ing on a very popular music site they use a lot

>90% of rejections were RBL related.

I’ve a suggestion list a few pages long, but raised enough bugs already. I’m not really a grumpy-old-man

It appears not to like the popular catalog shops, this isn’t so much of a problem because I can’t afford the wifes shopping habits at the moment.

There is a setting to turn off the feedback & Ken made a change to the license to exclude addressing info but my preference is to opt out on my personal box

It appears to be catching less (or I’ve been noticing a lot more) and I’m relying on SpamAssassin more since the upgrade

I’ve a hunch that most of these issues come down to bulkers postmasters setting short timeouts and increasing parallelism to get the greatest bang-for-the-buck-come-instant-gratification from their listservs in the zero hour. Postfix and qmail come with excellent defaults that cope with sods like me greylisitng or traffic shaping spammers connections – don’t fuck with them eh?

This is after all my personal mailhost, it runs a few small spamtraps and a bunch of mailboxes but not scientific empirical datasets. My mailbox has been hard to manage this week and I’m not aware of anything out of the ordinary happening. My public self seeding site is getting more english junk: This week then the same week last month. Pure observation but interesting none the less.

If I had to sum it up: At the moment, I’m sorry to say it’s not as effective as the decent greylisting implementation I was running, it appears to be FP’ing more but nevertheless it has far fewer drawbacks in normal use since the delays appear more usual than the arbitrary 3^rd party retry timeouts greylisting causes. It could be excellent. (Edit: added the dot. Is anyone else trying it? )

The Granddaddy of rejections was very interesting though natwest.co(m|.uk) WTF is going on with all that phish?

Mailchannels first impressions & its feedback loop

Chris — Sun, 25 May 2008 22:09:22 +0000

I love the idea of abusing the fact that spammers are in a hurry. Traffic Control checks all the geeky check-boxes of a SMTP proxy I should take a closer look at.
So the first thing I do once I can netcat to the proxy and check it’s running is fire up a “tcpflow -c -i eth0 not port 22” to watch it in action. I could immediately see how it slows connections (sweet), and then the instant phone home traffic or feedback mechanism.
I’m not so sure I like the feedback mechanism. The main issue is “but not be limited to” statement in the license as usual not the fact that they aggregate logs, over http on port 25.

Exhibit #1 – License snippet :

17.Feedback. The Software may periodically submit statistics about its
operation to servers operated by MailChannels and other parties
authorized by MailChannels (the “Feedback”). The Feedback shall
include but not be limited to the IP addresses of email senders,
server memory usage, server CPU usage, and various attributes of
email sending hosts such as operating system type.

Exhibit #2 – Stream capture : feedback.mailchannels.com port 25 gets sent a log line per email as a http post.

rd.42946-feedback.mailchannels.com.00025: POST /et/capture HTTP/1.1
Host: feedback.mailchannels.com
Content-Length: 402
Connection: keep-alive

[2008-05-25 16:58:53 +0100] [22019] i=78.149.112.169:52371 h= o=N u= a= t= p=0 d=0
x=”ClientACL t=0,0|EarlyTalker t=0|RBL action=reject;cbl.abuseat.org=no_data;hul.habeas.com=no_data; query.bondedsender.org=no_data;sbl-xbl.spamhaus.org=no_data; t=0.11,0.17,0.04,0.28,0.17;zen.spamhaus.org=127.0.0.11.reject”
l=ACCEPT c=550 z=”Found on zen spamhaus” e=”[550,Found on zen spamhaus]”
q= n=1/0/1 b=0/0/0/1 v=

^{CR’s added for readability}

I completely understand why they want the spy-in-the-box (having worked with Justin I know the possibilities are endless) but that license is a bit too lax for me. It’s just a niggle but I’d feel more comfortable if it was defined explicitly, and explained in full and have the option to disable it on privacy grounds.

You need to disable SPF in your mailserver too, since the postfix sees the proxy ip, spf hard fails result in a reject … I should have thought of that Maybe thats where my license file has gone Woops.

Just in case Ken reads this..

Kudos for the non commercial licensing

I’ve mailed free-beer and am still waiting for a key.

Being a typical old school QA guy I’ve a heap of suggestions, but for the time being this image of my mailbox shows the performance in the first hour or two with the default config.

...eww, but you should see what happens without it.
In fact if you look at the graph below you can see the effect is that the server is relaying more mail and rejecting less.

^{E&OE plus the fact I’m in a rotten mood, I’m blaming the prescription(s)}

MailChannels “Free Beer” edition

Chris — Tue, 20 May 2008 07:58:59 +0000

I looked at the MailChannels “free beer” edition yesterday and decided that 10k/day is not enough for my personal mailhost.

$ grep -c connect /var/log/mail.log.1 28652

...and yesterday wasn’t a busy day either.

IMHO it’d have much better adoption if it had been free for non-commercial use like MT Etc. since it has wide appeal to the hobbyist lower middle class sysadmin type. Tried it at home and bought it for work isn’t a bad sales model after all for geeks.

I wonder if they cope with PayPals’ silly/borked SPF records? .. I wonder if they process SPF at all for that matter.

New spam graphing

Chris — Sat, 18 Aug 2007 09:47:16 +0000

Here is a sneak peek at the next tool in the rrd-client suite. A daemon that monitors your MTA’s logs real-time and feeds stats into rrd-server.

Plenty of TODO’s still to be completed but it’s dead neat so far.

Not sending all that mail through spamassassin is really helping my CPU usage too. This is really going to help when I get my colo box next week.

Jobbed again

Chris — Sat, 04 Aug 2007 11:06:55 +0000

It would appear that some 3-4 hours of spam was cluelessly sent with a fake from address aimed at me, but this time there was no grief with it unlike the last big last time. This attack was about half the size of the awesome flood a year ago.

So this gave me an excellent opportunity to test out many mail servers sending me ‘ham’ via the greylist service (set to accept after 40 seconds). So here is a small random selection:

X-Greylist: delayed 1107 seconds (postfix)
X-Greylist: delayed 95 seconds (sendmail)
X-Greylist: delayed 169 seconds (sendmail)
X-Greylist: delayed 1295 seconds (postfix)
X-Greylist: delayed 400 seconds (qmail)
X-Greylist: delayed 1208 seconds (nplex)
X-Greylist: delayed 1307 seconds (postfix)
X-Greylist: delayed 400 seconds (qmail)
X-Greylist: delayed 400 seconds (qmail – hmmm a pattern)
X-Greylist: delayed 318 seconds (sendmail)
X-Greylist: delayed 63 seconds (microsoft )
X-Greylist: delayed 400 seconds (qmail)
X-Greylist: delayed 62 seconds (unknown – suspect MS p0f gave “Windows 2000 SP4, XP SP1”)
X-Greylist: delayed 400 seconds (qmail)
X-Greylist: delayed 64 seconds (microsoft)
X-Greylist: delayed 840 seconds (sendmail)
X-Greylist: delayed 65 seconds (microsoft)
X-Greylist: delayed 2353 second (postfix)
X-Greylist: delayed 970 seconds (symantec)
X-Greylist: delayed 2616 seconds (sendmail)
X-Greylist: delayed 400 seconds (qmail)
X-Greylist: delayed 162 seconds (unknown – Linux)
X-Greylist: delayed 917 seconds (sendmail)
X-Greylist: delayed 64 seconds (microsoft)
X-Greylist: delayed 399 seconds (qmail)
X-Greylist: delayed 363 seconds (postfix)
X-Greylist: delayed 69 seconds (microsoft)
X-Greylist: delayed 69 seconds (microsoft)
X-Greylist: delayed 915 seconds (MS IMS)
X-Greylist: delayed 395 seconds (qmail)
X-Greylist: delayed 445 seconds (sendmail)

So a revisit time of 580-620 seconds might be worth a spamassassin point or two.

One observation that also caught my eye is that yahoo are sending a lot of user-unknown messages out of the SMTP session. Yahoo are whitelisted on postgrey and hence have no greylist header added (though I wish it would with the reasoning) so I caught a lot of their blow-back for user unknown errors. Thats just wrong Y! guys!

Botspam vs. Greylisting - 1 : 0

Chris — Sun, 15 Jul 2007 13:38:13 +0000

With nothing better to do on a dull/hungover Sunday morning I thought I’d investigate a rumor I’d heard in the week regarding greylisting.
Now don’t get me wrong, I’m no fan of delaying email. I just want to see if what I’d heard was true…

I’m a bit of a tree-hugging Debian/postfix junkie so getting everything going was literally childs-play. Postgrey being the implementation of choice this time round and I had it running and tested in under 2 minutes.

sudo apt-get install postgrey

Then a quick edit of postfix’s main.cf.

At this time I also reduced the timeout from 5 minutes to 40 seconds since all I’m interested in is if they come back at all.

At the same time I deliberately turned off all rbl’s so that I’d get a big & fair dataset on the trap server. Then all I had to do is sit and watch.

Now of course this let through all the spam being sent via ISP’s relays but looking for direct sending bots running on DSL’s is pretty easy because they don’t have Wanadoo/Orange or Tiscali in the headers (only kidding).

So after a quick cuppa I had the results I was expecting. Here are the log highlights:

X-Greylist: delayed 651 seconds by postgrey;  
These were all definitely dialup/dsl pools. The interesting thing is how long they all took to come back but nevertheless it shows that at least some bots are well wise to greylisting.

The worst place for spam?..Your bug tracker

Chris — Fri, 04 May 2007 21:25:16 +0000

I was taking a look at lighthouse just now as a lightweight task tracker. Functional, attractive and tight email integration all looked good until I stumbled upon their spam problem. Gah, that almost put me off.

Prank or scam?

Chris — Fri, 09 Mar 2007 13:56:24 +0000

“You’ve been spotted using your mobile phone whilst driving and you have been traced through your car registration”
The number to call is 07666000###. At the end of the call ~5minutes the message ends:
“You’ve been had, HA HA!!”

Sounds like the usual prank calls but they usually involve a premium rate number, and that’s what got me wondering, could this be the start of mobile DID scams?

SPAM FREE or die!

Chris — Wed, 07 Feb 2007 09:32:38 +0000

I know it’s old but I can’t resist a reminder of the Anti-Spam anthem. Enjoy!

Fscked domain rule

Chris — Thu, 25 Jan 2007 23:20:34 +0000

So I’ve just read this bug (way too late I know..) and wondered why I think about these things a bit differently. Maybe it’s a good thing, maybe it’s bad but this has been killing the badsite*foo.tld spam since day 1 one for me, about 5 days now IIRC. The idea is that is spots any weirdness in a URL before the domain name terminator (or end of the string if one is not present).

Rule File.

Adjust your score as you see fit. It will FP on IDNs and such.

Feel free to drop me your masses results for it in a comment.