Hi all,
ok, after looking at all of the posts that I've found, and trying numerous settings, I am a little stumped as to how to set up the deliver program with qmail to get everything correct.
Ultimately, I really don't want to do a lookup of the home dir if I don't have to. I'd rather specify the stuff in the .qmail-user file for that particular user to avoid the extra step.
In looking in the wiki, it says for users without a lookup to use
HOME=/path/to/user/homedir deliver -f $FROM_ENVELOPE
but I can't do that in the .qmail file, which would normally look something like this :
|/var/qmail/bin/preline -f /usr/local/libexec/dovecot/deliver -f ${SENDER:-<>}
I would rather not do the master authentication socket as described for obvious reasons.
is there a format in the .qmail file that I can use with deliver to achieve what I want???
Thanks,
Tim.
Timo or anyone,
any insight into this???
I really just want to tell dovecot's deliver where the home directory is without having to fork another process to do it.
I may be able to create a shell script that set the env variable and then launched deliver, but that's another fork that I'd rather not have, and since I already know the home dir when I set up the .qmail-user file, I'd rather just set it...
help...
Tim.
Tim Traver wrote:
Hi all,
ok, after looking at all of the posts that I've found, and trying numerous settings, I am a little stumped as to how to set up the deliver program with qmail to get everything correct.
Ultimately, I really don't want to do a lookup of the home dir if I don't have to. I'd rather specify the stuff in the .qmail-user file for that particular user to avoid the extra step.
In looking in the wiki, it says for users without a lookup to use
HOME=/path/to/user/homedir deliver -f $FROM_ENVELOPE
but I can't do that in the .qmail file, which would normally look something like this :
|/var/qmail/bin/preline -f /usr/local/libexec/dovecot/deliver -f ${SENDER:-<>}
I would rather not do the master authentication socket as described for obvious reasons.
is there a format in the .qmail file that I can use with deliver to achieve what I want???
Thanks,
Tim.
On Tue, 2009-01-27 at 12:05 -0800, Tim Traver wrote:
Timo or anyone,
any insight into this???
Not really. There is currently no parameter to set home directory, maybe v1.3's config rewrite could help in future.
I really just want to tell dovecot's deliver where the home directory is without having to fork another process to do it.
I may be able to create a shell script that set the env variable and then launched deliver, but that's another fork that I'd rather not have, and since I already know the home dir when I set up the .qmail-user file, I'd rather just set it...
A shell script doesn't have to fork deliver, just exec it.
help...
Tim.
Tim Traver wrote:
Hi all,
ok, after looking at all of the posts that I've found, and trying numerous settings, I am a little stumped as to how to set up the deliver program with qmail to get everything correct.
Ultimately, I really don't want to do a lookup of the home dir if I don't have to. I'd rather specify the stuff in the .qmail-user file for that particular user to avoid the extra step.
In looking in the wiki, it says for users without a lookup to use
HOME=/path/to/user/homedir deliver -f $FROM_ENVELOPE
but I can't do that in the .qmail file, which would normally look something like this :
|/var/qmail/bin/preline -f /usr/local/libexec/dovecot/deliver -f ${SENDER:-<>}
I would rather not do the master authentication socket as described for obvious reasons.
is there a format in the .qmail file that I can use with deliver to achieve what I want???
Thanks,
Tim.
On Tue, 27 Jan 2009, Timo Sirainen wrote:
I may be able to create a shell script that set the env variable and then launched deliver, but that's another fork that I'd rather not have, and since I already know the home dir when I set up the .qmail-user file, I'd rather just set it...
A shell script doesn't have to fork deliver, just exec it.
Even if the shell forks before the exec, that time is nothing compared to the many synchronous writes that qmail does.
Even on a 233 MHz Pentium II computer with a reasonable operating system (any halfway recent BSD, or Linux, or Solaris), an extra fork has never hurt me (not even when such a machines were used as mail, web, samba, ftp server and 100 Mbit/s firewall at the same time).
Typical shells will try to use lighter-weight vfork() anyways -- only that most operating systems should implement copy-on-write strategies underneath fork() and can then map vfork() on top of fork() because it really makes no noticable difference any more.
-- Matthias Andree
On Mon, 26 Jan 2009, Tim Traver wrote:
ok, after looking at all of the posts that I've found, and trying numerous settings, I am a little stumped as to how to set up the deliver program with qmail to get everything correct.
qmail is way obsolete and buggy. http://mandree.home.pages.de/qmail-bugs.html
I've migrated away to Postfix ages before Postfix 1.0 was released and never rued that change a split second...
Ultimately, I really don't want to do a lookup of the home dir if I don't have to. I'd rather specify the stuff in the .qmail-user file for that particular user to avoid the extra step.
...are home directory lookups so very expensive on your system? Hard to believe. I always found that qmail's (and qmail-send's) queue spooling behaviour was what really hurted, with a dozen (or so) synchronous writes for just spooling the message into the queue...
-- Matthias Andree
On Jan 28, 2009, at 2:56 AM, Matthias Andree wrote:
On Mon, 26 Jan 2009, Tim Traver wrote:
ok, after looking at all of the posts that I've found, and trying numerous settings, I am a little stumped as to how to set up the
deliver program with qmail to get everything correct.qmail is way obsolete and buggy. http://mandree.home.pages.de/qmail-bugs.html
Yes, in it's default form. Hence netqmail.
I've migrated away to Postfix ages before Postfix 1.0 was released and never rued that change a split second...
and I suppose you've never upgraded it - right? :P
Ultimately, I really don't want to do a lookup of the home dir if I don't have to. I'd rather specify the stuff in the .qmail-user
file for that particular user to avoid the extra step....are home directory lookups so very expensive on your system?
Hard to believe. I always found that qmail's (and qmail-send's) queue spooling behaviour was what really hurted, with a dozen (or so) synchronous writes for just spooling the message into the queue...
The bigger problem, other than a minor hardware/filesystem upgrade,
is does deliver obey .qmail files in the user's home directory?
It doesn't seem like it. Please correct me if I'm wrong, because if
it doesn't, you'll need to modify at least how user's vacations and
forwards are done.
Rick
Rick Romero schrieb:
On Jan 28, 2009, at 2:56 AM, Matthias Andree wrote:
On Mon, 26 Jan 2009, Tim Traver wrote:
ok, after looking at all of the posts that I've found, and trying numerous settings, I am a little stumped as to how to set up the deliver program with qmail to get everything correct.
qmail is way obsolete and buggy. http://mandree.home.pages.de/qmail-bugs.html
Yes, in it's default form. Hence netqmail.
So? netqmail fixes only a minority of qmail's bugs, but not the ones that require touching qmail's concepts - and I don't even make an attempt to update my bug list, since I find netqmail's change list too terse.
I've migrated away to Postfix ages before Postfix 1.0 was released and never rued that change a split second...
and I suppose you've never upgraded it - right? :P
Nah. Of course I upgraded Postfix - but I have yet to see another piece of software where upgrades go so smoothly.
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.
It doesn't seem like it. Please correct me if I'm wrong, because if it doesn't, you'll need to modify at least how user's vacations and forwards are done.
-- Matthias Andree
On Jan 28, 2009, at 8:23 AM, Matthias Andree wrote:
Rick Romero schrieb:
On Jan 28, 2009, at 2:56 AM, Matthias Andree wrote:
On Mon, 26 Jan 2009, Tim Traver wrote:
ok, after looking at all of the posts that I've found, and trying numerous settings, I am a little stumped as to how to set up the
deliver program with qmail to get everything correct.qmail is way obsolete and buggy. http://mandree.home.pages.de/qmail-bugs.html
Yes, in it's default form. Hence netqmail.
So? netqmail fixes only a minority of qmail's bugs, but not the
ones that require touching qmail's concepts - and I don't even make an
attempt to update my bug list, since I find netqmail's change list too terse.
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).
I've migrated away to Postfix ages before Postfix 1.0 was
released and never rued that change a split second...and I suppose you've never upgraded it - right? :P
Nah. Of course I upgraded Postfix - but I have yet to see another
piece of software where upgrades go so smoothly.
make setup check didn't seem to hard for me (even after my custom
patches). And you've now said that software is updated to fix
problems and add features.
It's a crime to not specify AT LEAST what version of qmail you're
complaining about. 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.
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.
Rick
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'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.
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.
-- Matthias Andree
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
On Jan 28, 2009, at 12:29 PM, Charles Marcus wrote:
On 1/28/2009 1:04 PM, Rick Romero wrote:
I use both maildrop and procmail with qmail/vpopmail.
Ummm... this is the dovecot list, right?
deliver would replace either qmail-local(I believe, I've never used
it in that way) or vdelivermail - but to do so, it needs to either be
a drop in replacement and do everything that those two programs did
(quota is another we haven't brought up yet), or we have to do that
processing somehow (via Sieve/maildrop/procmail) prior to calling
deliver. OR - it has to be specifically placed in every
user's .qmail delivery file.
Oh another one could be obeying qmail extension addresses, which
leads us to .qmail-user-alt files that need to be processed too.. it
depends on your installation and how you want to use dovecot's
deliver. There's a lot that needs to be addressed if one wants to
try and use dovecot's deliver. Not that it's not possible, but I
wouldn't consider it a drop in replacement.
Rick
Words by Rick Romero [Wed, Jan 28, 2009 at 12:51:14PM -0600]:
Oh another one could be obeying qmail extension addresses, which leads us to .qmail-user-alt files that need to be processed too.. it depends on your installation and how you want to use dovecot's deliver. There's a lot that needs to be addressed if one wants to try and use dovecot's deliver. Not that it's not possible, but I wouldn't consider it a drop in replacement.
Not really that much to be addressed, I'm using it with much fuzz.
-- Jose Celestino | http://japc.uncovering.org/files/japc-pgpkey.asc
"One man’s theology is another man’s belly laugh." -- Robert A. Heinlein
On Jan 28, 2009, at 1:09 PM, Jose Celestino wrote:
Words by Rick Romero [Wed, Jan 28, 2009 at 12:51:14PM -0600]:
Oh another one could be obeying qmail extension addresses, which
leads us to .qmail-user-alt files that need to be processed too.. it
depends on your installation and how you want to use dovecot's deliver.
There's a lot that needs to be addressed if one wants to try and use dovecot's deliver. Not that it's not possible, but I wouldn't consider it
a drop in replacement.Not really that much to be addressed, I'm using it with much fuzz.
Excellent! How do you handle vacations and forwards? Do you use qmail extension addresses?
Exactly how did you implement deliver?
Rick
In all honesty, switching to qmail-ldap would fix most of these issues
I'm hearing on this thread ; as you move the .qmail and forward logic
to a proper centralized directory and can store the maildir info
there. Integration with dovecot is mostly trivial once the info is
LDAP based.
~Max
On Jan 28, 2009, at 11:18 AM, Rick Romero wrote:
On Jan 28, 2009, at 1:09 PM, Jose Celestino wrote:
Words by Rick Romero [Wed, Jan 28, 2009 at 12:51:14PM -0600]:
Oh another one could be obeying qmail extension addresses, which
leads us to .qmail-user-alt files that need to be processed too.. it
depends on your installation and how you want to use dovecot's deliver.
There's a lot that needs to be addressed if one wants to try and use dovecot's deliver. Not that it's not possible, but I wouldn't consider it
a drop in replacement.Not really that much to be addressed, I'm using it with much fuzz.
Excellent! How do you handle vacations and forwards? Do you use qmail extension addresses?
Exactly how did you implement deliver?
Rick
On Thu, 2009-01-29 at 04:29, Charles Marcus wrote:
On 1/28/2009 1:04 PM, Rick Romero wrote:
I use both maildrop and procmail with qmail/vpopmail.
Ummm... this is the dovecot list, right?
I was beginning to wonder that myself, I though I unsubbed from the qmail list a LONG time ago
Rick Romero schrieb:
You've listed two DIFFERENT versions, which may or may not include the noted patches.
I don't find "All subsequent contents of this document refer to qmail-1.03, most of the bugs apply to the netqmail-1.05 patchkit, too." unclear. I've removed the netqmail part of it, although netqmail addressed only a fraction of the points last time I looked at it.
qmail 1.03 does not include any of the patches, and netqmail isn't an official qmail release, but a third-party patch kit.
Which is the entire point - The page is just plain out of date.
No, it is not - it pertains to the latest official qmail release (which is over a decade old BTW). Feel free to send a patch that weaves info about netqmail 1.06 in. I'm not doing that.
-- Matthias Andree
On 1/28/2009, Matthias Andree (matthias.andree@gmx.de) wrote:
No, it is not - it pertains to the latest official qmail release (which is over a decade old BTW).
Which is as good a reason as any to not use it...
Lets please limit discussion to dovecot related issues, not qmail related issues.
participants (8)
-
Charles Marcus
-
Jose Celestino
-
Matthias Andree
-
Maxwell Reid
-
Noel Butler
-
Rick Romero
-
Tim Traver
-
Timo Sirainen