on 4/8/05 9:31 AM, James Whitt <[EMAIL PROTECTED]> wrote: > Thanks for this, I was in middle of implementing something like this > when I read the post and realized it would work. It did raise a > question for me though. If I'm using the valias with mysql, how > would I enable those accounts to be check for viruses since > vdelivermail would need to be called to have it forward it according > to the mysql table?
I've never used valias, and I can't speak to that feature, but I'm kind of assuming the following logic applies regardless. So bear with this... > I can't use a .qmail-<alias> file that sends it > to the script which then sends it to vdelivermail for the reason you > had mentioned. Hmm. Well Tom says its not good to do that (to call vdelivermail anywhere besides in .qmail-default), but prior to hearing him say that, I was calling vdelivermail from .qmail-<alias> files all over the place. This is how I prototyped my filtering awaiting a better way to do it. I saw it as problematic because QmailAdmin didn't know what to do with it, mainly, but also because it would have bo be done per-alias and thus doesn't guarantee consistent behavior for a particular user destination. But it strikes me that if a .qmail-<alias> file contains for example exactly the same thing as .qmail-default, this would not hurt system behavior at all. Qmail looks for a .qmail-<alias> file first and if it finds one it does not look at .qmail-default. So there is no issue of .qmail-default recursion in that case. The recursion problem only comes up in the ".qmail" files (which are really vpopmail files, not seen by QMail) inside user directories. These files are called *from* vdelivermail. In any case if you can put your filter hook inside the user directory in the file called ".qmail" you get a much cleaner solution which remains compatible with whatever aliases you use elsewhere to point to that user, and does not require any filtering at the alias level. I'd think that would be true whether you use .qmail-alias or valias, because both mechanisms work at a level that occurs prior to what happens inside the user directory. > On Apr 7, 2005 12:41 AM, Kurt Bigler <[EMAIL PROTECTED]> wrote: >>> If I were to implement this, as a option to vdelivermail, say: >>> -d Deliver only. Do not preline and skip all .qmail processing >>> would you find this to be something worth integrating? I'm not sure that >>> I'd have time now, but it seems worth asking the question. >> >> I actually implemented this in my copy of vdelivermail.c. It was actually >> easier than I thought, and there were fewer issues, apparently, although I'm >> not intimately familiar enough to know that I haven't missed something. >> >> Here's what I did: >> I tentatively reclaimed the unused there-for-compatibility command-line >> argument 1. If that argument equals '-d', intended to mean "Deliver Only" >> (but could also mean Disable .qmail processing), then processing proceeds as >> if the .qmail file did not exist, which I guess is just what Kyle Wheeler >> was suggesting. That appears to be all there is do it. >> >> This change allows you do basic filtering in your .qmail files without >> needing any of: >> procmail >> maildrop >> maildir/safecat >> >> In my book this is a very good thing. It not only avoids the need for >> dependencies on extra packages, but offers all the advantages that >> vdelivermail already provides, including quota checking. As README.quotas >> says: >>> NOTE: Non-system domain quotas are only enforcable when vdelivermail is the >>> local delivery agent. If you pipe your mail into anything else, like >>> maildrop, then the non-system domain quota will be ignored. >> So with this change, you can now have the following line in your user/.qmail >> file: >> >> | myfilter | vdelivermail -d bounce-no-mailbox >> >> and it will not result in infinite vdelivermail recursion. And so you can >> have a pure-vpopmail solution for your QmailAdmin-enabled Spam Detection >> option.
