Re: MTA comparison (postfix, exim4, ...)
On Sat, 17 Nov 2007 00:31:17 +0000
MJ Ray <mjr@phonecoop.coop> wrote:
> Thanks for the pointers. Can a policy server delay an incoming mail?
> I suspect that sleeping in the perl would delay all incoming mail and
> there's no access(5) response like Exim's delay, else I could do it
> another way. How can it be done? (I want to increase the connection
> cost to maybe-spammers of sending to my postfix...)
Well, you could write one that would handle the delay itself---slowing
its response to policy inquiries at various points---but that seems
like a bit of a rathole to start down. The data management necessary
to do that with an non-blocking daemon would be easy to get subtly
wrong. Subtly wrong and MTAs are a poor mix.
Hmmmm.
You could play with the tarpit controls that smtpd has ('man smtpd'
look for TARPIT), and set the limits so low that tarpiting would kick
in immediately. That might produce the result you're looking for. It
feels a _little_ hacky, but not totally so.
You could bug Weitse for an access(5) response that would cause those to
kick in---given that there are tarpit controls, the infrastructure is
obviously in there somewhere, you just need a button to push to
activate the mechanism---but that would obviously be a longer-term
solution.
I am personally skeptical of the value of tarpiting such hosts since
these days so many spam machines are zombies and the supply seems nigh
infinite---it seems like you're courting running your own host out of
resources, since each open connection does incur some cost, and the
real solution is to sever the connection the moment you know it's
crap---but if you really want it, I'm not sure postfix is your ideal
MTA.
> I don't believe it does. I don't want to verify the recipient address
> - I want to try delivering the redirected mail and avoid being left
> holding the baby if the destination MX doesn't want it or is MIA.
Hrm, you're right, it only does about half what you want---it won't
accept a mail unless it knows it can pass it on to that recipient, but
if there are other factors about the particular mail that would cause
the final destination to deny it, it's not gonna ferret those out.
I don't know of any pre-queue mechanism for doing exactly what you
want. The fact is, postfix wants to be fast, but even more,
it wants to be robust, so it was designed pretty much from the ground
up to get things to stable storage first and foremost. Things that
work pre-queue are newer, and consequently less comprehensive in
capabilities.
My solution for the blowback stuff was, simply, to write a perl script
to parse through the mailq output and delete the messages that were
obviously crap. I handle a couple of million messages a day through
postfix, relaying for several hundred small domains, and even when one
of those domains gets joe-jobbed, my queue cleaner (which is very
conservative) make sure I don't have to deal with a bunch of crap.
Mike.
Reply to: