On Jan 28, 2009, at 11:32 AM, Matthias Andree wrote:
Rick Romero schrieb:
Some of the 'problem' concepts are opinions. For example, I use
qmail's unbundled sending to monitor mail throughput. (I run a free service) When the queue sizes shoot up, it's shut down and I remove the
spammer. A bundled email to 150 users would still be 1 email, and that does
me no good. The only place for Postfix would be a dumb relay for those providers that throttle connections (assuming that was a real
issue for me).Unbundling mail just for accounting? Seems a rather wasteful
approach to me. Other open-source MTAs I've looked at, including Sendmail,
Exim, and Postfix, that transport mail bundled, emit sufficient log
information to obtain the number of recipients. But that's a long way from the
topic...
It needs to be done 'in-process'. I suppose total concurrency could
be retrieved by some sort of combination of gathering and
multiplication, but logs also tend to be 'after the fact'. By
'lining up' multiple queues, with a delay, outgoing spam bursts can
be caught quickly.
So multiple SMTP transfers between internal systems could also be
considered 'wasteful', but then, the people who received the spam
that could have been stopped would disagree.
It's a crime to not specify AT LEAST what version of qmail you're complaining about.
Since that's a public complaint, I'll still respond to this
paragraph: The version (qmail 1.03, netqmail 1.05) is up front, and has been from the beginning.Or is it a bunch of different issues with different versions all crammed on one page? The first complaint acknowledges that it may no longer exist in 1.03 (released when?). If anyone
really reads beyond that, I'd be surprised.Irrelevant polemics, and if either you're overly susceptible to
surprise or your imagination is so limited, such may not transfer to everybody
else...The first complaint shows two examples, and I simply haven't
checked if the second example works against 1.03 or only older 1997 versions,
because it doesn't matter, the resource exhaustion vulnerability is there. I
don't care much, if someone presents evidence to one side or the other, I'll update the page, but I'm not doing further research myself.
You've listed two DIFFERENT versions, which may or may not include
the noted patches.
Which is the entire point - The page is just plain out of date. It's
equivalent to me saying I don't run Windows and link to a page with
Windows 98 issues. Will every Win98 issue be resolved in XP or
Vista? I doubt it, but that doesn't really make the page any more
relevant, and any issues listed that no longer exist are just plain
misleading. Do I dare say the 3 letter F word? :)
The bigger problem, other than a minor hardware/filesystem
upgrade, is does deliver obey .qmail files in the user's home directory?Dovecot's deliver certainly doesn't.
So back to the original question: Then it's pretty much useless in a qmail environment unless the admin has already changed those features to require maildrop or
procmail. If that has been done, then the directory lookup should already be done, and you can do deliver at the end of your maildrop or procmail
script.It's probably possible to plug deliver late in the delivery process of qmail-local (i. e. as default delivery), but I forgot the details -
let somebody else speak up who knows qmail better than your or me do
off-hand; or better ask the qmail list (but be prepared for crusades on the
list... BTST).As a pointer, check the various qmail examples on how procmail can be integrated into qmail and see if those can be adjusted for deliver.
or Sieve (which I should have added earlier) might be the better
solution, since dovecot has the plugin.
I use both maildrop and procmail with qmail/vpopmail. In my case,
vdelivermail has to be replicated by dovecot deliver, OR I need to
migrate the different ways I have of doing Spam scaning/real-time
useage allocation/vacations/forwards to single system. Not a bad
thing, and will happen eventually, but not something I personally
have time for at the moment.
Rick
-- Matthias Andree