On 10/01/2013 06:30 PM, Charles Sprickman wrote:
Simple question I hopeā€¦

Some yes, some no. ;)

What's the recommendation on the vpopmail side on integrating Dovecot's LDA for 
final delivery?

I'm not aware of any recommendation per se.

In the QMail-Toaster community (I am the project leader there FWIW), we've informally implemented dovecot with vpopmail for imap/pop3, but have yet to implement Dovecot's LDA, which will come after formal adoption of Dovecot imap/pop3 in the forthcoming QMT release.

So I'm very interested in the best way to replace vdelivermail/maildrop with dovecot's Deliver and Pigeonhole. I'm especially looking forward to implementing server-side message filtering.

I've seen various suggestions, including just calling it from the user's .qmail 
file.  In that particular case, it's not at all clear to me how other tools 
that would touch that file (like qmailadmin) would be taught to not alter the 
call to dovecot_lda.  I imagine it would get munged everytime a user went to 
setup a vacation message or forward.

I imagine you're correct. qmailadmin, vqadmin et al would need to be modified for this. Off hand, I've expected that this will be the method used. It might be more suitable (simpler) though to develop a vdelivermail replacement which would simply pass the message on to Deliver. I really haven't thought about this much.

Also I'm in the midst of upgrading from 5.4.10 to 5.4.33.  I see that there's 
new support to have vdelivermail handle the call to spamc for tagging, and also 
support to have maildrop handle the filtering.  A few questions regarding this 
setup if vpopmail is configured to use spamc and maildrop:

QMT was upgraded from 5.4.17 to 5.4.33 not too long ago. It's not using spamc at the delivery stage though.

* Is maildrop always doing the final delivery?

Afaik, yes.

* What's the message flow when a .qmail file is encountered that has a forward?

Forwards are handled in the database now. I'm not sure exactly how that works, but I expect that vdelivermail (could be maildrop though) checks the database and forwards accordingly by putting the message back into the queue with a new recipient. Now that I think of it, I wonder how Deliver would handle forwards. Can Deliver handle forwards at all? More specifically, vpopmail-type forwards?

* What's the message flow when a .qmail file is encountered that's piping to 
maildrop (we have a ton of these on the old system, I assume I'd have to find 
and nuke all of them)?

This is the standard mechanism in QMT. I'm guessing that maildrop passes messages on to vdelivermail. I'm not positive about this though.

* Does this limit qmailadmin's abilities at all?

qmailadmin pretty much controls the .qmail files (again, ttbomk). On a side note, I am aware that there's a bug in qmailadmin where if the name is changed, a 2nd delivery record is created in the .qmail file causing duplicate deliveries. It'd be nice to get this fixed at some point. I imagine that there might be a few other bugs in there which need fixing.

I imagine that vqadmin may touch these as well, but I'm not really familiar with vqadmin (it was a bit broken on QMT until we upgraded to 5.4.33).

* If using valias, do we filter a message before forwarding offsite?

I don't know anything about this off hand.

Hoping the list is still alive, didn't even realize I'm still subscribed here!

Yeah, barely. ;)

You might want to consider joining us on the QMT list. Lots of friendly help there. :)

Good luck Charles, and please let us know about your endeavors with Deliver.

-Eric 'shubes'


Reply via email to