qmail Digest 9 Mar 1999 11:00:01 -0000 Issue 574
Topics (messages 22754 through 22787):
migrating sendmail to qmail
22754 by: Francisco Yepes Candel <[EMAIL PROTECTED]>
22756 by: Peter van Dijk <[EMAIL PROTECTED]>
22774 by: Richard Letts <[EMAIL PROTECTED]>
qmail + procmail again
22755 by: Peter van Dijk <[EMAIL PROTECTED]>
Oops, you were sent a virus
22757 by: Sascha Ottolski <[EMAIL PROTECTED]>
smtproutes
22758 by: Mate Wierdl <[EMAIL PROTECTED]>
22759 by: Harald Hanche-Olsen <[EMAIL PROTECTED]>
22764 by: Mate Wierdl <[EMAIL PROTECTED]>
22765 by: Mate Wierdl <[EMAIL PROTECTED]>
22772 by: "Sam" <[EMAIL PROTECTED]>
22776 by: Mate Wierdl <[EMAIL PROTECTED]>
22778 by: Stefan Paletta <[EMAIL PROTECTED]>
22781 by: "Sam" <[EMAIL PROTECTED]>
Rewriting the "Date:" field
22760 by: Juan Carlos Castro y Castro <[EMAIL PROTECTED]>
22761 by: Harald Hanche-Olsen <[EMAIL PROTECTED]>
22762 by: Juan Carlos Castro y Castro <[EMAIL PROTECTED]>
22767 by: [EMAIL PROTECTED]
22771 by: "Sam" <[EMAIL PROTECTED]>
22787 by: Harald Hanche-Olsen <[EMAIL PROTECTED]>
ezmlm response
22763 by: Dan Laffin <[EMAIL PROTECTED]>
Getting Qmail to reject unknown MAIL FROM addresses...
22766 by: Jason Haar <[EMAIL PROTECTED]>
22770 by: Harald Hanche-Olsen <[EMAIL PROTECTED]>
22773 by: "Sam" <[EMAIL PROTECTED]>
22775 by: Jason Haar <[EMAIL PROTECTED]>
qmail on caldera linux 2.0.35
22768 by: [EMAIL PROTECTED]
qpopper vulnerability?
22769 by: Matthias Pigulla <[EMAIL PROTECTED]>
22777 by: Peter van Dijk <[EMAIL PROTECTED]>
22784 by: [EMAIL PROTECTED]
22785 by: Peter van Dijk <[EMAIL PROTECTED]>
22786 by: [EMAIL PROTECTED]
strange problem with dot_forward with Solaris 2.6
22779 by: <[EMAIL PROTECTED]>
22780 by: Peter van Dijk <[EMAIL PROTECTED]>
22782 by: <[EMAIL PROTECTED]>
Location of Maildir
22783 by: "Dave" <[EMAIL PROTECTED]>
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To bug my human owner, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
Hello everybody,
I want to migrate sendmail to qmail in a mail server that has the following
properties.
1. It has no users (mailboxes)
2. It only act as a mail gateway, i.e: it redirect messages between mail
servers (with their propers mailboxes) and the world and viceversa
Can I follow these steps?:
1. kill sendmail daemon that is listening on port 25
2. activate qmail-smtpd on port 25
3. run "sendmail -q" to force the delivery of messages that are still in
the sendmail queue
The news messages could be delivered by qmail. Meanwhile the olds messages
could be delivered by sendmail until they are run out. Can "sendmail -q"
interfere with qmail-smtpd (or others qmails daemons) in some sense?
Thanks in advance.
---------------------------------------------------------------------------
Francisco Yepes Candel e-mail:[EMAIL PROTECTED]
Universidad de Murcia telf: +34-968-364828
Servicio de Inform�tica fax : +34-968-364151
30100 Murcia
Spain
On Mon, Mar 08, 1999 at 12:26:12PM +0100, Francisco Yepes Candel wrote:
> Hello everybody,
>
> I want to migrate sendmail to qmail in a mail server that has the following
> properties.
>
> 1. It has no users (mailboxes)
> 2. It only act as a mail gateway, i.e: it redirect messages between mail
> servers (with their propers mailboxes) and the world and viceversa
Ah.. shouldn't be problematic then :)
> Can I follow these steps?:
>
> 1. kill sendmail daemon that is listening on port 25
> 2. activate qmail-smtpd on port 25
> 3. run "sendmail -q" to force the delivery of messages that are still in
> the sendmail queue
Yeah.. keep running sendmail -q every once in a while to make sure you really get rid
of all messages.
> The news messages could be delivered by qmail. Meanwhile the olds messages
> could be delivered by sendmail until they are run out. Can "sendmail -q"
> interfere with qmail-smtpd (or others qmails daemons) in some sense?
I don't think so..
Greetz, Peter.
--
.| Peter van Dijk | <mo|VERWEG> stoned worden of coden
.| [EMAIL PROTECTED] | <mo|VERWEG> dat is de levensvraag
| <mo|VERWEG> coden of stoned worden
| <mo|VERWEG> stonend worden En coden
| <mo|VERWEG> hmm
| <mo|VERWEG> dan maar stoned worden en slashdot lezen:)
On Mon, 8 Mar 1999, Francisco Yepes Candel wrote:
> 3. run "sendmail -q" to force the delivery of messages that are still in
> the sendmail queue
if you start sendmail with the -qxx parameter but not -bd then it will sit
there processing the queue every xx hours/minutes etc until the queue is
empty. once it is empty to can kill the process permenatly
Richard
On Mon, Mar 08, 1999 at 03:26:34AM -0500, Adam D. McKenna wrote:
> I noticed in my testing that if a user does not have a home directory, and you
> are using procmail to deliver to /var/mail/username, then qmail will return
> that the user doesn't exist. Is there a way around this? I want qmail to
> deliver to /var/mail/username as long as the user has an entry in /etc/passwd.
> (and not necessarily a home directory.)
You could try something similar to FAQ 4.9. (Hint: remove the -h from the qmail-pw2u
line).
Greetz, Peter.
--
.| Peter van Dijk | <mo|VERWEG> stoned worden of coden
.| [EMAIL PROTECTED] | <mo|VERWEG> dat is de levensvraag
| <mo|VERWEG> coden of stoned worden
| <mo|VERWEG> stonend worden En coden
| <mo|VERWEG> hmm
| <mo|VERWEG> dan maar stoned worden en slashdot lezen:)
On Sun, 07 Mar 1999 12:37:59 EST "Adam D. McKenna" wrote:
> From: Sascha Ottolski <[EMAIL PROTECTED]>
>
> :> The Star Scanning System discovered a virus in a message sent to you.
> :> ------------------------------------
> :
> :Does anybody know what kind of anti-virus-system is running on their
> :qmail-server?
> :
> :Looks very interesting..
> :
> :Greetings, Sascha
>
> This is just a wild guess, but I'm going to say he's running the Star Scanning
> System.
ok, I think you are right here :-) But do you have an idea how it works or
where to get it?
Sascha
Suppose I have a box running qmail on a home network without DNS. How
can I route all remote messages to another box on the home network?
Would putting
:[1.2.3.4]
in smtproutes work, where 1.2.3.4. is the remote box's IP on the home
network.
Thx
Mate
- Mate Wierdl <[EMAIL PROTECTED]>:
| Suppose I have a box running qmail on a home network without DNS.
| How can I route all remote messages to another box on the home
| network?
|
| Would putting
|
| :[1.2.3.4]
|
| in smtproutes work, where 1.2.3.4. is the remote box's IP on the
| home network.
I think you would need to patch qmail-remote to skip the CNAME
lookups, or provide a fake dns_cname() that does no actual lookup.
- Harald
On Mon, Mar 08, 1999 at 05:39:48PM +0100, Harald Hanche-Olsen wrote:
> - Mate Wierdl <[EMAIL PROTECTED]>:
>
> | Suppose I have a box running qmail on a home network without DNS.
> | How can I route all remote messages to another box on the home
> | network?
> |
> | Would putting
> |
> | :[1.2.3.4]
> |
> | in smtproutes work, where 1.2.3.4. is the remote box's IP on the
> | home network.
>
> I think you would need to patch qmail-remote to skip the CNAME
> lookups, or provide a fake dns_cname() that does no actual lookup.
So with stock qmail, I *must* have DNS?
--
---
Mate Wierdl | Dept. of Math. Sciences | University of Memphis
On Mon, Mar 08, 1999 at 10:38:12PM +0530, Sameer Vijay wrote:
>
> Hi!
>
> I would suggest that you put the name and ip (1.2.3.4) in /etc/hosts
> and put the name in the smtproutes
>
> :remote.host
>
> I am not sure whether putting brackets there will help. just the
> IP should suffice, if you want to put ip there.
If what you suggest is supposed to work, then I am confused: having
:remote.host
in smtproutes does not require a DNS lookup of remote.host?
--
---
Mate Wierdl | Dept. of Math. Sciences | University of Memphis
Mate Wierdl writes:
> So with stock qmail, I *must* have DNS?
Correct. If you don't have DNS running, your network must be so small that
putting a few lines into control/smtproutes shouldn't be much of a hassle.
--
Sam
On Mon, Mar 08, 1999 at 10:47:01PM +0000, Sam wrote:
> Mate Wierdl writes:
>
> > So with stock qmail, I *must* have DNS?
>
> Correct. If you don't have DNS running, your network must be so small that
> putting a few lines into control/smtproutes shouldn't be much of a hassle.
This is exzactly my question: suppose I have only two machines, box1.home,
and box2.home. Can I just put
:box2.home
in smtproutes on box1.home to direct all remote mail to box2---though
box2.home is in only /etc/hosts?
Also, is the syntax
:[1.2.3.4]
valid, if 1.2.3.4 is the IP of box2.home?
Thx
Mate
Mate Wierdl wrote/schrieb/scribsit:
> Also, is the syntax
>
>:[1.2.3.4]
>
> valid, if 1.2.3.4 is the IP of box2.home?
Yes. No need for DNS here.
Stefan
Mate Wierdl writes:
> This is exzactly my question: suppose I have only two machines, box1.home,
> and box2.home. Can I just put
>
> :box2.home
>
> in smtproutes on box1.home to direct all remote mail to box2---though
> box2.home is in only /etc/hosts?
No - you must use the IP address.
>
> Also, is the syntax
>
> :[1.2.3.4]
>
> valid, if 1.2.3.4 is the IP of box2.home?
That's it. Actually:
box1.home:[1.2.3.4]
is probably better.
--
Sam
Hi. I'm using ezmlm 0.53 under qmail and I'd like to know if I can
rewrite the "Date:" header field so I know when the message was received
according to the server clock (instead of according to the machine who
sent the message).
I intend to run an auto racing list in which people bet on race results
(just recreational; no money involved) and I have to be able to assess
that each message arrived before the time limit for placing bets.
Cya,
--
___THE___ One man alone cannot fight the future. USE LINUX!
\ \ / / _______________________________________________
\ V / |Juan Carlos Castro y Castro |
\ / |[EMAIL PROTECTED] |
/ \ |Linuxeiro, alvinegro, X-Phile e Carioca Folgado|
/ ^ \ |Diretor de Inform�tica e Eventos Sobrenaturais |
/ / \ \ |da E-RACE CORPORATION |
~~~ ~~~ -----------------------------------------------
RACER
- Juan Carlos Castro y Castro <[EMAIL PROTECTED]>:
| I intend to run an auto racing list in which people bet on race
| results (just recreational; no money involved) and I have to be able
| to assess that each message arrived before the time limit for
| placing bets.
Why not use the Received: header fields for that purpose?
- Harald
Harald Hanche-Olsen wrote:
>
> - Juan Carlos Castro y Castro <[EMAIL PROTECTED]>:
>
> | I intend to run an auto racing list in which people bet on race
> | results (just recreational; no money involved) and I have to be able
> | to assess that each message arrived before the time limit for
> | placing bets.
>
> Why not use the Received: header fields for that purpose?
Well, hm, that's kind of user-unfriendly... those flocks of Received:
are somewhat confusing, and what I want is something that shows
screaming in my face. The Date: field would be ideal for that because
Netscape can sort on it.
Other options (besides editing Date:) woud be making up a new header
name (Arrived-At-Server: maybe?) or using the footer feature of ezmlm. I
didn't find a tag that would translate into the current time.
--
___THE___ One man alone cannot fight the future. USE LINUX!
\ \ / / _______________________________________________
\ V / |Juan Carlos Castro y Castro |
\ / |[EMAIL PROTECTED] |
/ \ |Linuxeiro, alvinegro, X-Phile e Carioca Folgado|
/ ^ \ |Diretor de Inform�tica e Eventos Sobrenaturais |
/ / \ \ |da E-RACE CORPORATION |
~~~ ~~~ -----------------------------------------------
RACER
>> Harald Hanche-Olsen wrote:
H> Why not use the Received: header fields for that purpose?
>> On Mon, 08 Mar 1999 15:15:41 -0300,
>> Juan Carlos Castro y Castro <[EMAIL PROTECTED]> said:
J> Those flocks of Received: are somewhat confusing, and what I want is
J> something that shows screaming in my face. The Date: field would be
J> ideal for that because Netscape can sort on it.
The Date: line can be forged. I realize that this also applies to
Received: lines, but all you can do is add a forgery, not prevent a
server from adding a valid Received: line.
Since the same argument applies to adding a special-purpose header via
the user-agent, would it be better to (say) replace qmail-inject with a
small filter that adds a header and then passes the message along to
the real qmail-inject? The only advantage to this approach is not
having to parse through multiple Received: lines.
--
Karl Vogel
ASC/YCOA, Wright-Patterson AFB, OH 45433, USA
[EMAIL PROTECTED] or [EMAIL PROTECTED]
Juan Carlos Castro y Castro writes:
> Well, hm, that's kind of user-unfriendly... those flocks of Received:
> are somewhat confusing, and what I want is something that shows
> screaming in my face. The Date: field would be ideal for that because
> Netscape can sort on it.
Arrange via virtualdomains, or some other means, to divert
mail to the mailing list address to some .qmail, in ~alias perhaps, which
will contain something like:
| sed '1,/^$/s/^Date:/X-Date:/' | /var/qmail/bin/qmail-inject
your_real_mailing_list_address
--
Sam
- "Sam" <[EMAIL PROTECTED]>:
| Arrange via virtualdomains, or some other means, to divert mail to
| the mailing list address to some .qmail, in ~alias perhaps, which
| will contain something like:
|
| | sed '1,/^$/s/^Date:/X-Date:/' | /var/qmail/bin/qmail-inject
| your_real_mailing_list_address
There is a problem with this approach: If the incoming mail has
syntax errors in its headers, qmail-inject will refuse it, and the
mail is stuck in the queue. This sort of thing really happens; I've
seen it. On the other hand, if you're happy with the non-delivery of
such mail and the resulting bounce a week later, this is fine.
(You don't need the full path of qmail-inject in .qmail if you
sensibly run qmail-start with /var/qmail/bin at the front of $PATH.)
- Harald
Hey, I'm finally getting down to setting up this qmail box and I was
wondering if there were any suggestions on filesystem setup (inode
density, cylinder grouping, and cluster size, etc.) and RAID0+1 config
(stripping interval, etc.). I have my system drives (raid1) and my data
drives for the Maildirs (raid0+1) running on an e450 with Solaris 7 and
DiskSuite 4.2. Thanks.
--
Dan Laffin [EMAIL PROTECTED] Phone:(407)660-7900x249
Systems Administrator, MPINet Fax :(407)660-7848
On Mon, Mar 08, 1999 at 10:53:58AM +0100, Harald Hanche-Olsen wrote:
> | How would you propose going about writing clairvoyant code which would
> | know in advance that the client on the other side of a new SMTP connection
> | will do a MAIL FROM: with an unresolvable address at some point in the
> | future?
>
> Clearly, you can't. But what you could do is to have a program
> sitting between the TCP socket and qmail-smtpd. Normally, it would
> just pass every incoming command to qmail-smtpd, but it would check
> any MAIL command first. If it's bad, it will take over and reject
> every RCPT or DATA command until a RSET or new MAIL command appears.
What I was thinking about is a program that carried out the SMTP
conversation until the MAIL FROM occurred, and then checked that the address
was "correct" (by DNS lookup). If it isn't, drop the SMTP as spam, otherwise
turn around and replay the conversation to qmail-smtpd and then link the two
together.
> Avoiding patches is a valid goal, but not at any price.
Too true. However I am concerned that there are a LOT of patches for Qmail
now that are needed to make it compete with sendmail (anti-UCE support is
extremely lacking in "pure" qmail), and if I go down the path of shoving all
the (great) patches available into qmail, I'll end up with something
unsubstainable. DJB certainly implies he thinks most of these patches should
be done as standalone apps instead of qmail patches (rblsmtpd is an example
of this) - so I'm just asking what he's suggesting...
Personally I think http://www.flame.org/qmail/mlg-patches.diff is a great
patch (does all I'm asking, AND assigns "spam points" to each message -
bouncing when a threshold level has been met, adding a "X-Spam" header
otherwise so that you can then filter it).
--
Cheers
Jason Haar
Unix/Network Specialist, Trimble NZ
Phone: +64 3 3391 377 Fax: +64 3 3391 417
- Jason Haar <[EMAIL PROTECTED]>:
| > Clearly, you can't. But what you could do is to have a program
| > sitting between the TCP socket and qmail-smtpd. Normally, it would
| > just pass every incoming command to qmail-smtpd, but it would check
| > any MAIL command first. If it's bad, it will take over and reject
| > every RCPT or DATA command until a RSET or new MAIL command appears.
|
| What I was thinking about is a program that carried out the SMTP
| conversation until the MAIL FROM occurred, and then checked that the
| address was "correct" (by DNS lookup). If it isn't, drop the SMTP as
| spam, otherwise turn around and replay the conversation to
| qmail-smtpd and then link the two together.
Well, there is no way for a program to magically link two file
descriptors together and then go away: The program must remain and
copy data from one file descriptor to the other. Second, after the
DATA phase is done the sender may start over with a new MAIL command,
etc., and your front end program must be prepared for that. So it
would need to parse the traffic to detect this, and filter the new
address. Further, a spammer could easily get around your filter by
just doing
MAIL FROM:<[EMAIL PROTECTED]>
(the front end checks this, finds it ok, replays this to
qmail-smtpd, and leaves the rest to qmail-smtpd)
RSET
MAIL FROM:<[EMAIL PROTECTED]>
(qmail-smtpd blissfully accepts the new sender address)
Personally, I don't see checking the sender domain in the DNS as a
very useful antispam measure, since spammers are learning to use
sender addresses with existing domains. But it can be seen as a way
to increase the reliability of mail delivery: By accepting mail, you
take on the responsibility to either deliver it or to notify the
envelope sender of a failure to do so. By refusing to accept mail
without a valid sender domain, you are basically refusing an
obligation that is impossible to meet. (On the other hand, it may be
impossible anyway, since the local part of the sender address may be
wrong as well. But then you could, at least in principle, pass the
resulting double bounce to the postmaster at that domain.)
- Harald
Jason Haar writes:
> What I was thinking about is a program that carried out the SMTP
> conversation until the MAIL FROM occurred, and then checked that the address
> was "correct" (by DNS lookup). If it isn't, drop the SMTP as spam, otherwise
> turn around and replay the conversation to qmail-smtpd and then link the two
> together.
How would you propose to handle the second and subsequent E-mail messages
that the sender might send, after the first one is accepted by Qmail?
--
Sam
On Mon, Mar 08, 1999 at 10:49:00PM +0000, Sam wrote:
> How would you propose to handle the second and subsequent E-mail messages
> that the sender might send, after the first one is accepted by Qmail?
Well that about sorts that problem out.
I can't see how I can do what I want without patching qmail itself. I think
I'll give up the purist approach and just go for the existing patches that
already do all this...
[Better document... Better not be hit by a bus ;-/]
--
Cheers
Jason Haar
Unix/Network Specialist, Trimble NZ
Phone: +64 3 3391 377 Fax: +64 3 3391 417
Hello List,
Can anyone point me in the right direction?
I'm new to Linux and I'm trying to install qmail on Caldera Open-Linux
1.3. The version (from uname) is 2.0.35. I haven't been able to locate any
messages regarding qmail and linux 2.0.35. I 've downloaded the rpm's
(from the link on the qmail home page) for functions, daemontools, ucspi
tcpserver and of course qmail. I'm attempting to rebuild the rpm for ucspi
tcpserver and shadow-utils but they fail. Do you know where I can locate
correct version rpm's for this caldera version? This version builds the
rpm in /usr/src/OPENLINUX... instead of /usr/src/redhat... I even tried
to install it from the tar file but can't get the smtd process to work
correctly.
There is a note in the documentation about making sure to use the correct
shadow-utils for the version, but I can't find the correct info in the
spec. ( I did an "rpm -q -a" , and the shadow-utils are not installed)
I should mention that I was able to install these rpm's and get qmail
running successfully on a redhat (5.0 I think) system and using the tar
file on Solaris 2.6. I checked caldera's download site and they don't even
mention qmail or the shadow-utils.
Any help is appreciated.
TIA,
Rick
[EMAIL PROTECTED]
Hi folks,
In http://www.cert.org/advisories/CA-98.08.qpopper_vul.html you will
read "CERT Coordination Center has received reports of buffer overflow
vulnerabilities in some POP servers based on QUALCOMM's qpopper."
Is qmail-popup (or any other program involved due to qmail's POP3
iterface design) known to be exploitable?
Matthias
--
w e b f a c t o r y | matthias pigulla
www.webfactory.de [EMAIL PROTECTED]
On Mon, Mar 08, 1999 at 09:33:08PM +0100, Matthias Pigulla wrote:
> Hi folks,
>
> In http://www.cert.org/advisories/CA-98.08.qpopper_vul.html you will
> read "CERT Coordination Center has received reports of buffer overflow
> vulnerabilities in some POP servers based on QUALCOMM's qpopper."
>
> Is qmail-popup (or any other program involved due to qmail's POP3
> iterface design) known to be exploitable?
No, DJB's code has always been perfectly exploit-free as far as I know. qmail-popup
and qmail-pop3d are in _no_ _way_ related to qpopper.
Greetz, Peter.
--
.| Peter van Dijk | <mo|VERWEG> stoned worden of coden
.| [EMAIL PROTECTED] | <mo|VERWEG> dat is de levensvraag
| <mo|VERWEG> coden of stoned worden
| <mo|VERWEG> stonend worden En coden
| <mo|VERWEG> hmm
| <mo|VERWEG> dan maar stoned worden en slashdot lezen:)
On Tue, Mar 09, 1999 at 01:34:36AM +0100, Peter van Dijk wrote:
[ssnip]
> > Is qmail-popup (or any other program involved due to qmail's POP3
> > iterface design) known to be exploitable?
>
> No, DJB's code has always been perfectly exploit-free as far as I know. qmail-popup
> and qmail-pop3d are in _no_ _way_ related to qpopper.
[ssnip]
and the latest betas of qpopper are also exploit-free.
--
http://www.spb.sitek.net/~pashah/public-key-0x97739141.pgp
On Tue, Mar 09, 1999 at 11:23:47AM +0300, [EMAIL PROTECTED] wrote:
> On Tue, Mar 09, 1999 at 01:34:36AM +0100, Peter van Dijk wrote:
>
> [ssnip]
>
> > > Is qmail-popup (or any other program involved due to qmail's POP3
> > > iterface design) known to be exploitable?
> >
> > No, DJB's code has always been perfectly exploit-free as far as I know. qmail-popup
> > and qmail-pop3d are in _no_ _way_ related to qpopper.
>
> [ssnip]
>
> and the latest betas of qpopper are also exploit-free.
rephrase: no bugs have been found... after the amount of bugs found in previous
qpopper releases, I don't trust it.
Greetz, Peter.
--
.| Peter van Dijk | <mo|VERWEG> stoned worden of coden
.| [EMAIL PROTECTED] | <mo|VERWEG> dat is de levensvraag
| <mo|VERWEG> coden of stoned worden
| <mo|VERWEG> stonend worden En coden
| <mo|VERWEG> hmm
| <mo|VERWEG> dan maar stoned worden en slashdot lezen:)
On Tue, Mar 09, 1999 at 09:56:41AM +0100, Peter van Dijk wrote:
> rephrase: no bugs have been found... after the amount of bugs found in previous
> qpopper releases, I don't trust it.
okay (:
right you are ... the only thing that makes me use it anyways is it`s
bulletinboard feature ...
Pashah
--
http://www.spb.sitek.net/~pashah/public-key-0x97739141.pgp
Hi there,
I'm puzzled by the qmail-start script, maybe someone can give me a hint.
The script is like the following:
supervise /var/lock/qmail /var/qmail/bin/qmail-start \
'|dot-forward .forward ./Maildir/' accustamp \
| setuser qmaill supervise /var/lock/qmail-cyclog cyclog \
/var/log/qmail/qmail &
It gave me the following error messages in about every 10 messages:
920934855.867884 delivery 22: deferral:
dot-forward:_fatal:_unable_to_parse_this_line:_/
But it will disappear if I use the following script:
/bin/sh -cf '/var/qmail/rc &'
And /var/qmail/rc is like the following:
#!/bin/sh
exec env - PATH="/var/qmail/bin:$PATH" \
qmail-start '|dot-forward .forward
./Maildir/' splogger qmail
Did I miss something here? I have poked around try to find the answer
but no vail. The first script works on the Red hat linux 5.2 though.
I really like to use the supervise tools and the cyclog.
Any help is highly appreciated.
Thanks.
--George Hong
System Admin
On Mon, Mar 08, 1999 at 05:43:44PM -0700, [EMAIL PROTECTED] wrote:
> Hi there,
> I'm puzzled by the qmail-start script, maybe someone can give me a hint.
> The script is like the following:
>
> supervise /var/lock/qmail /var/qmail/bin/qmail-start \
> '|dot-forward .forward ./Maildir/' accustamp \
.forward and ./Maildir/ are on one line here.
> | setuser qmaill supervise /var/lock/qmail-cyclog cyclog \
> /var/log/qmail/qmail &
>
> It gave me the following error messages in about every 10 messages:
>
> 920934855.867884 delivery 22: deferral:
> dot-forward:_fatal:_unable_to_parse_this_line:_/
>
>
> But it will disappear if I use the following script:
>
> /bin/sh -cf '/var/qmail/rc &'
>
> And /var/qmail/rc is like the following:
>
> #!/bin/sh
>
> exec env - PATH="/var/qmail/bin:$PATH" \
> qmail-start '|dot-forward .forward
> ./Maildir/' splogger qmail
Here, they're on two lines.
> Did I miss something here? I have poked around try to find the answer
> but no vail. The first script works on the Red hat linux 5.2 though.
> I really like to use the supervise tools and the cyclog.
>
> Any help is highly appreciated.
Just put the newline in between .forward and ./Maildir/
Greetz, Peter.
--
.| Peter van Dijk | <mo|VERWEG> stoned worden of coden
.| [EMAIL PROTECTED] | <mo|VERWEG> dat is de levensvraag
| <mo|VERWEG> coden of stoned worden
| <mo|VERWEG> stonend worden En coden
| <mo|VERWEG> hmm
| <mo|VERWEG> dan maar stoned worden en slashdot lezen:)
It fixed it.
Thanks a lot.
--George
On Tue, 9 Mar 1999, Peter van Dijk wrote:
> On Mon, Mar 08, 1999 at 05:43:44PM -0700, [EMAIL PROTECTED] wrote:
> > Hi there,
> > I'm puzzled by the qmail-start script, maybe someone can give me a hint.
> > The script is like the following:
> >
> > supervise /var/lock/qmail /var/qmail/bin/qmail-start \
> > '|dot-forward .forward ./Maildir/' accustamp \
>
> .forward and ./Maildir/ are on one line here.
>
> > | setuser qmaill supervise /var/lock/qmail-cyclog cyclog \
> > /var/log/qmail/qmail &
> >
> > It gave me the following error messages in about every 10 messages:
> >
> > 920934855.867884 delivery 22: deferral:
> > dot-forward:_fatal:_unable_to_parse_this_line:_/
> >
> >
> > But it will disappear if I use the following script:
> >
> > /bin/sh -cf '/var/qmail/rc &'
> >
> > And /var/qmail/rc is like the following:
> >
> > #!/bin/sh
> >
> > exec env - PATH="/var/qmail/bin:$PATH" \
> > qmail-start '|dot-forward .forward
> > ./Maildir/' splogger qmail
>
> Here, they're on two lines.
>
> > Did I miss something here? I have poked around try to find the answer
> > but no vail. The first script works on the Red hat linux 5.2 though.
> > I really like to use the supervise tools and the cyclog.
> >
> > Any help is highly appreciated.
>
> Just put the newline in between .forward and ./Maildir/
>
> Greetz, Peter.
> --
> .| Peter van Dijk | <mo|VERWEG> stoned worden of coden
> .| [EMAIL PROTECTED] | <mo|VERWEG> dat is de levensvraag
> | <mo|VERWEG> coden of stoned worden
> | <mo|VERWEG> stonend worden En coden
> | <mo|VERWEG> hmm
> | <mo|VERWEG> dan maar stoned worden en slashdot lezen:)
>
I am just beginning setting up a Qmail system and have found that to use the
Maildir capability it ends up in the Users $HOME. Is there anyway to create
say a /var/qmail/maildirs dir and place all users' Maildirs there? The users
current $HOME also serves their personal web pages, which I understand could
not be viewed throuh a browser anyway because of permissions, but the users
can be stupid sometimes and delete their Maildir, which I did to test and
all their mail is now going nowhere...well at least not going to them. I
need a way to protect their Maildirs from themselves...any ideas?
