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'
!DSPAM:524c18fb34284707794799!
