[Dovecot] deliver and qmail

[Rick Romero]

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
>