Re: [vchkpw] qmailadmin and forwards
On 08/28/2014 02:26 PM, Eric Shubert wrote: Thanks for this explanation Rick. Now knowing how this actually works, I think I'll join you in being peeved about it. Not knowing any better, I would have presumed that the user d-q files would have been processed before the domain d-q files. Makes me wonder what the rationale is/was for processing the domain files first. It has to do with the way vpopmail uses qmail hooks to do its job. When you create the example.com domain, vpopmail modifies the /var/qmail/users/assign database so that qmail-local delivers the mail according to the instructions in ~/vpopmail/domains/example.com . So what reads your .qmail-* files in the domain directory is not vdelivermail, it's simply qmail-local. What vpopmail does is put a vdelivermail invocation in .qmail-default in the domain directory. vdelivermail then extracts the user name, looks it up in its vpasswd database to find the correct directory (most of the time ~vpopmail/domains/example.com/user) and delivers the mail according to the instructions in that directory. If you put a .qmail file in the domain directory, that takes precedence over .qmail-default, then vdelivermail will be bypassed entirely. So don't do that - let vpopmail do its black magic on the domain directory and only use user directories to put your .qmail files into. There are 2 things I'm not satisfied with, but they have nothing to do with the domain-wide .qmail files. The first thing is that vdelivermail duplicates most of the work of qmail-local for parsing .qmail files. It would be much more elegant to have vdelivermail just perform the vpopmail-specific stuff (extract user name, check the vpasswd database, go to user directory) then exec into qmail-local itself. The second thing is that vdelivermail does not make all the black magic transparent: the .qmail files in a user directory cannot be written exactly as if the user was a system user instead of a vpopmail user. I have a program, vsanitize, to be called in .qmail files in vpopmail user directories, that moves around a few environment variables to provide such transparency. -- Laurent !DSPAM:54008ad456445328810183!
Re: [vchkpw] qmailadmin and forwards
One thing to remember, and one of my pet peeves... Out of all of the files in ~vpopmail/domains/example.com/ only one, .qmail-default has anything to do with the vpopmail delivery process. When qmail-local tries to deliver a message to the domain it looks at all of the .qmail-* files in the domain directory, and processes the .qmail* file that best matches the incoming address. If no other .qmail file matches .qmail-default is processed, which is where vdelivermail gets control. see:man dot-qmail .qmail files in ~vpopmail/domains/example.com/username will be handled by vdelivermail depending on compiler options. Vpopmail and qmailadmin do manage the .qmail files in the domain directory, but during the delivery process qmail does not pass control to vpopmail unless none of the other .qmail files match. !DSPAM:53fecb3a56448570372193!
Re: [vchkpw] qmailadmin and forwards
On 08/27/2014 11:24 PM, Rick Widmer wrote: One thing to remember, and one of my pet peeves... Out of all of the files in ~vpopmail/domains/example.com/ only one, .qmail-default has anything to do with the vpopmail delivery process. When qmail-local tries to deliver a message to the domain it looks at all of the .qmail-* files in the domain directory, and processes the .qmail* file that best matches the incoming address. If no other .qmail file matches .qmail-default is processed, which is where vdelivermail gets control. see:man dot-qmail .qmail files in ~vpopmail/domains/example.com/username will be handled by vdelivermail depending on compiler options. Vpopmail and qmailadmin do manage the .qmail files in the domain directory, but during the delivery process qmail does not pass control to vpopmail unless none of the other .qmail files match. Thanks for this explanation Rick. Now knowing how this actually works, I think I'll join you in being peeved about it. Not knowing any better, I would have presumed that the user d-q files would have been processed before the domain d-q files. Makes me wonder what the rationale is/was for processing the domain files first. -- -Eric 'shubes' !DSPAM:53ff2e0956448319919131!
Re: [vchkpw] qmailadmin and forwards
On 8/28/2014 7:26 AM, Eric Shubert wrote: On 08/27/2014 11:24 PM, Rick Widmer wrote: One thing to remember, and one of my pet peeves... Out of all of the files in ~vpopmail/domains/example.com/ only one, .qmail-default has anything to do with the vpopmail delivery process. When qmail-local tries to deliver a message to the domain it looks at all of the .qmail-* files in the domain directory, and processes the .qmail* file that best matches the incoming address. If no other .qmail file matches .qmail-default is processed, which is where vdelivermail gets control. see:man dot-qmail .qmail files in ~vpopmail/domains/example.com/username will be handled by vdelivermail depending on compiler options. Vpopmail and qmailadmin do manage the .qmail files in the domain directory, but during the delivery process qmail does not pass control to vpopmail unless none of the other .qmail files match. Thanks for this explanation Rick. Now knowing how this actually works, I think I'll join you in being peeved about it. Not knowing any better, I would have presumed that the user d-q files would have been processed before the domain d-q files. Makes me wonder what the rationale is/was for processing the domain files first. You don't know it is a user until you have verified the incoming address does not match any aliases or mailing lists. Actually I consider the way it works to be an elegant design. You use the standard facilities in qmail to handle the domain directory, and only fire up vdelivermail to lookup individual users and forwards within the domain. This is especially important for mailing lists because ezmlm and qmail are tightly coupled. What I am peeved about was people on the qmail list complaining about the 'strange' way that vpopmail handles .qmail files, or wanting them to be renamed to .vpopmail files when the fact of the matter is that qmail only hands off delivery for individual users after qmail-local can't find any matching .qmail files in the domain directory. (.qmail-default) The humorous part is that the 'strange' behavior they complain about is the standard behavior of qmail and vpopmail may not be involved in the delivery at all. (Aliases and mailing lists are controlled by the .qmail files in the domain directory.) !DSPAM:53ff7e7856441903219601!
Re: [vchkpw] qmailadmin and forwards
Rick, At issue was that qmail only processes the .qmail-alias files in the domain directory. It then hands off to vdelivermail via the .qmail-default file in the domain directory. The vdelivermail program is what parses the user/.qmail file for delivery instructions. While that file follows the same format as other .qmail-alias files, I would agree that it would have been clearer to use .vpopmail as the filename so users would know that the qmail programs weren't responsible for processing it. If we had remained true to the qmail way, shouldn't it have been user/.qmail-default and supported user/.qmail-alias files to handle email addressed to user-al...@example.com? -Tom On Aug 28, 2014, at 12:09 PM, Rick Widmer wrote: What I am peeved about was people on the qmail list complaining about the 'strange' way that vpopmail handles .qmail files, or wanting them to be renamed to .vpopmail files when the fact of the matter is that qmail only hands off delivery for individual users after qmail-local can't find any matching .qmail files in the domain directory. (.qmail-default) The humorous part is that the 'strange' behavior they complain about is the standard behavior of qmail and vpopmail may not be involved in the delivery at all. (Aliases and mailing lists are controlled by the .qmail files in the domain directory.) !DSPAM:53ffc37156441140448696!
Re: [vchkpw] qmailadmin and forwards
On Aug 27, 2014, at 10:00 AM, Eric Shubert e...@shubes.net wrote: On 08/25/2014 05:48 PM, Charles Sprickman wrote: I block the spam before it enters the system using simscan. Thanks - not an option here since I need to allow users to opt in or out, etc. The simcontrol file allows you to customize settings per email address. I presume that this would be the initial (forward) address, since the true destination wouldn't be available yet at that point. The issue with that is we already have a bunch of stuff in webmail and internal web apps that deal with per-user settings and such (including some neat postscreen things for when I finish standing Postfix up in front of the primary mxer), so switching scanning is not really an option. All alias/forward traffic seems to find its way to qmail via vdelivermail piping it to qmail-inject, so I put a wrapper in place of qmail-inject last night and that’s looking good. It’s just a shell script, and it’s a bit hokey, but the volume on forwards/aliases is about 5% of our total volume. Basically it makes a few decisions: • Is the calling UID 89? If not, throw the message to real qmail-inject immediately • If it is UID 89, is this offsite or local final delivery? If local, throw message to qmail-inject • If it is UID 89 and offsite, pipe through spamc to temporary file, look at exit status of spamc. If it’s spam, discard, exit 0. If it’s not spam, read the file into qmail-inject So far so good. It’s really hackish though. Charles -- -Eric 'shubes' !DSPAM:53fdfe8556446577118687!
Re: [vchkpw] qmailadmin and forwards
Charles, It's been a long time since I've worked in that code, but here are some quick thoughts: 1) There's already code reading the headers, searching for mail loops by looking at the Delivered-To header. You could tap into that code. 2) You could look at simscan.c to see how they're interfacing with spamc. -Tom On Aug 25, 2014, at 5:48 PM, Charles Sprickman wrote: Off to try to follow vdelivermail.c… :) !DSPAM:53fc20e356441762611622!
