#haraka

On that note, I think we should stick with grunt.

:)

oh, and in case you missed yesterdays xkcd: http://xkcd.com/1520/

Since Steve is here, I won't post a link to todays xkcd.

I enjoyed today's xkcd :)

baudehlo: a quick yay or nay on #951 would be appreciated when you have a minute.

Given the length of the discussion, I doubt a quick yay or nay will be possible :)

baudehlo: honestly - you can skip the discussion entirely; it's mostly irrelevant to the actual proposed change except for Matt's initial comment.

FTR, I don't object to it.

So long as it's not being proposed *instead* of having a connect_pre hook (which it's not, AFAICT), then this helps scratch one of Steve's itches

it adds a little extra control to a presently difficult problem

Does it have docs? :)

A part of me wishes that instead of serial, each hook was run with async.parallel, and then a final callback decided what to do

I don't :)

Last thing I'd want is uribl running in parallel with spamassassin.

that already happens, just not to the same message at the same time

that's the point

I want to reject for uribl before SA runs.

Yeah - concurrent hooks would be a nightmare.

I can see that ultimatt2 would want them for karma.

but I don't use karma.

Me neither.

But I'm getting close to looking at it - although I'll probably rip a lot of it out and just implement it as a generic way to score stuff that I don't want to reject outright.

e.g. something like 'host was greylisted' AND 'has an attachment' then 'reject'

And I couldn't do that if things were concurrent.

Just checked - and I've got a whole bunch of stuff that wouldn't work or code that I'd have to duplicate if hooks were run in parallel. example: my MX lookup code runs and sets a whole bunch of notes for other plugins that run on the same hook then use.

I wouldn't want to have to run the MX lookup code in all of those plugins - it would be really inefficient which is why I did it like that in the first place.

I'm getting a message on one of the plugins I'm running stating "delaying response for 1 seconds". It's an SMTP Auth plugin which inherits auth/auth_base'. My code doesn't include any message like this. Is this something built into Haraka that I'm missing?

nevermind - figured it out

has anyone stress tested haraka with the queued messages?

just wondering if it could handle 1,000,000 + messages queued at once

or would be better to send it to postfix to be queued