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


Reply via email to