#haraka

[13Haraka] 15msimerson opened pull request #2082: add get/set to conn/txn.notes (06master...06haraka-notes) 02https://github.com/haraka/Haraka/pull/2082

_smf_: Option 1 is basically sending a 400 error back to the sending server so they will resend again producing a second copy of the message ? This doesnt sound like a great solution as if the message has >10 recipients the final message processing time would be 10 x the retry time of the sending server.

Is that correct or have I misunderstood ? My understanding was that denysoft issues a SMTP 400 temp error and a reject would produce a SMTP 500 error?

[13Haraka] 15greenkeeper[bot] created 06greenkeeper/haraka-test-fixtures-1.0.20 (+1 new commit): 02https://github.com/haraka/Haraka/commit/f2b9f...

13Haraka/06greenkeeper/haraka-test-fixtures-1.0.20 14f2b9f4c 15greenkeeper[bot]: chore(package): update haraka-test-fixtures to version 1.0.20

we are using haraka as front facing spam filter and we are using the queue/smtp_forward plugin to relay to itself on port 2525. On the same box we have exim running as a relay to then send on the emails to the final destination using MX routing. We can configure exim to use static routing however I find exim MX routing is pretty reliable so far.

I am struggling to understand how denysoft will force the sender to split the message into two? and what sort of behaviour to expect if there was 10-20 recipients?

[13Haraka] 15greenkeeper[bot] 04deleted 06greenkeeper/haraka-test-fixtures-1.0.20 at 14f2b9f4c: 02https://github.com/haraka/Haraka/commit/f2b9f4c

stezzzle: that's exactly how it works. Deferring each recipient forces the message to be split by the sender.

I'd frankly be amazed if you had non-spam external messages sending to any more than a couple of recipients at a time.

What you're doing with the subject simply isn't feasible without this as SMTP was designed to transport messages by domain.

Unless you're really proficient with SMTP and understand in-depth how e-mail works - you shouldn't even consider Option 2. I've done e-mail for 10 years and even I would hesitate to even try it as it's so tricky to do correctly.

[13Haraka] 15smfreegard pushed 1 new commit to 06master: 02https://github.com/haraka/Haraka/commit/578b5...

13Haraka/06master 14578b54d 15Matt Simerson: discard: discard when txn.queue.wants = discard (#2067)...

Wow - my spam trap is doing 60 connections per second today with a peak of 253 connection/sec today.

Crikey

Not bad for a cheap shit DigitalOcean droplet.

Peak now 417 connections/sec...

magical

Yeah - it's pretty incredible seeing as the spamtrap is running rspamd.

Normally at volumes like that plugins running on hook_data_post are usually too slow, but rspamd is handling it well.

_smf_: how much config have you done w/ rspamd?

Not that much.

I'm actually reporting message hashes to rspamd.com that everyone uses.

I've disabled a few odds and ends, but it's otherwise stock.

e.g. I've disabled chartable, dkim, spf

I should probably disable surbl too, but I needed it to check on a new list.

There's no possible way I could run SpamAssasin on this box. Even after disabling a load of stuff it would still be too slow.

[13Haraka] 15smfreegard closed pull request #2082: add get/set to conn/txn.notes (06master...06haraka-notes) 02https://github.com/haraka/Haraka/pull/2082

Busy day on my spam trap today. 1.2m messages so far with a maximum of 1607 connections per second and 3578 messages per second!

wowsers.

Do you send it all to /dev/null?

!

Haha - no. rspamd is processing it all to generate fuzzy hashes

And I collect samples of anything that rspamd doesn't classify as spam.

As you'd expect there's mountains of duplicates.

5189 ? Rsl 114:53 Haraka (master) cn=1146768 cc=1711 cps=77/50.3/1607 msgs=1230646 mps=78/53.98/3578 out=0/0/1 respawn=82

That's since I restarted it this morning.

Nice.

That's on really crappy hardware too.

wow

👌

Digital Ocean droplet with 4Gb RAM, 2 CPUs and a 24Gb SSD

I always worry as we keep adding stuff to Haraka that we'll somehow make it slow, but it seems to be holding up pretty well.

_smf_: how do you get your trap so popular?

Although you're quite a few versions behind I suspect.

EyePulp_: it's all about the domains.

baudehlo: *nod*

baudehlo: actually in this case it isn't.

We managed to get a few at Messagelabs that were insanely high traffic.

We ran regularly at about 50k concurrency.

(that was running Qpsmtpd-async though).

EyePulp_: I have got a handful of domains - things like popular_freemail_domainNOSPAM.com etc.

We had a project to get hold of domains that might be spammed.

But I wrote a plugin that looks like a semi-open relay, but intentionally fails a select percentage of messages.

Basically would check things like leaked email lists for expired domains, and buy them.

Then the plugin with also accept a percentage of AUTH attempts automatically.

And also I had a bunch of those web sites with email addresses placed on them.

and had hidden links from messagelabs.com and eventually symantec.com

And finally it creates an HTTP and SOCKS open proxy, but redirects any port 25 traffic locally.

Building spamtrap traffic is a bit of an art, and a lot of luck.

Any inbound traffic has 50% accepted (and processed/discarded/quarantined), 25% rejected and 25% tempfailed.

So it tries to look semi-legit.

That's not even close to legit, legit would be rejecting 80%. ;)

I did say semi ;-)

touché

Looking at Grafana - most of todays traffic has come in via the SOCKS proxy.

baudehlo: yeah - I wish there was a better way to find trap domains. I've bought domains hoping they'll get decent traffic e.g. > 10 msgs/sec, but I'm usually disappointed.

Yup. We had some donated to us. Those were usually the best.

I've got a customer with a defunct school district in the US that he's having to keep running (but reject 99% of the mail) and I've been trying to get them to loan me it.

*nod* - donated stuff rocks.

*sniff* I think I'm going to cry: http://imgur.com/a/k5T3T

Wait, does this mean I have to support any of the terrible commits I've made?

dammit.

=P

worse, it means you have to support some of the terrible commits *I've* made.

here's a good one to cut your teeth on: https://github.com/haraka/Haraka/pull/2073 ;-)

#2073 AKA "Scariest Pull Request evar!"

I did a mini-version of that yesterday in haraka-test-fixtures, more-or-less to see how much stuff blew up

And?

It blows up badly in node 0.4.x =)

The only failures were test suites that hasn't been updated to node 8 (still on node 4)