anosh: Right? It's taken me years to perfect that level of string concatenation mastery.
anosh
we ended up finding bottlenecks in Haraka :(
but they're msg size related
_smf_
anosh: how so?
anosh
if we get 70 bccs w/ 25mb messages on our 4gb box, it'll just consume all the memory basically
each transaction
not the same
we do read the attachment
this is .15 though, not the latest
we can't update because of the patches we've done to fix bugs
_smf_
Yeah - that's expected.
anosh
haha
i'm benchmarking w/ various instances now
_smf_
I'm serious - that's just how Haraka is going to work. If you have a message that is 25Mb, then Haraka is going to use 25Mb RAM.
anosh
yeah
we just need to know a good instance size for the amount of mail our clients send
_smf_
You could try setting the spool_after=25Mb setting in smtp.ini that I introduced.
Although I haven't tested it in ages, so it might have been broken by various changes.
That will cause Haraka to use a temporary file to store the message in if it exceeds the spool_after size.
But obviously - that will cause considerably more disk IO.
anosh
yeah
maybe it'll work
idk
_smf_
I can think of another way - but it's a bit puke.
anosh
might as well share it, immortalise it in botbot logs
_smf_
You'd have to track in-flight message size inside Haraka (e.g. each child) where you add the data as it comes in and then remove it when the transaction finishes. Then you'd write a plugin that runs on hook_rcpt that defers the recipients if the inflight_size > limit.
You'd therefore get a slight delay in incoming messages if someone decides to dump 1.7Gb of BCC'd messages in individual transactions.
Which to be honest - would be absolutely fine with me.
EyePulp
anosh: do you have evidence that those sort of large message sizes are at all typical for your user base? The spool_after sounds like a decent failover if large messages are more of a corner case in your traffic.
(if I understand its behavior)
anosh
EyePulp: it's why we've started doing this test
get some numbers
_smf_
spool_after was a bit of a hack though. And it's going to kill performance either way.
anosh
yeah i don't think that's going to work
we'll just go big
EyePulp
heh
_smf_
If someone sends you 1.7Gb of mail all at once, then it's always going to be a bit shit.
anosh
haha
EyePulp
When all else fails - more metal.
_smf_
Heck - try the same thing with Postfix.
anosh
we limit to 250mb per message anyways
:^)
_smf_
You mean 25Mb right...
anosh
nah, o365 lets you do some weird shit to attachment sizes
250
_smf_
That's just crazy.
I have a limit of 50Mb here as that is pretty much the standard.
e.g. Gmail limits to that.
anosh
yeah
it's no issue anyways
_smf_
250Mb is just going to open you up to easy DoS.
anosh
since the public cannot connect
_smf_
Famous last words.
anosh
lmao
if the IP isn't in the list, we just flat out refuse the connection
_smf_
I once had a e-mail user that sent a fuckin' ISO image to a bunch of people from her Mac.
anosh
o365/gmail would deal w/ that
we don't email out
only back
_smf_
A bug in the Mac integration with Exchange caused her Mac to send the ISO endlessly to the Exchange server which brought it down and flooded the subnet with traffic.
anosh
lmao exchange
rip
anyways, we'll see
not my problem anyways
_smf_
I'm actually quite liking my idea of tracking in-flight message data size. It would prevent Haraka from chewing up a lot of RAM and hitting swap.
At least tracking this via the process_title plugin e.g. current/average/max in-flight would be interesting.