qmail Digest 15 Mar 1999 11:00:01 -0000 Issue 580
Topics (messages 22930 through 22970):
rblsmtp - I need to change the bounce report.
22930 by: torben fjerdingstad <[EMAIL PROTECTED]>
local-local test
22931 by: Enrico Mangano <[EMAIL PROTECTED]>
dot-qmail security
22932 by: Joel Eriksson <[EMAIL PROTECTED]>
22933 by: Mate Wierdl <[EMAIL PROTECTED]>
22935 by: Scott Schwartz <[EMAIL PROTECTED]>
22937 by: Scott Schwartz <[EMAIL PROTECTED]>
22938 by: Joel Eriksson <[EMAIL PROTECTED]>
22939 by: Joel Eriksson <[EMAIL PROTECTED]>
22940 by: Brad Shelton <[EMAIL PROTECTED]>
22941 by: Joel Eriksson <[EMAIL PROTECTED]>
22943 by: Scott Schwartz <[EMAIL PROTECTED]>
22944 by: Brad Shelton <[EMAIL PROTECTED]>
22945 by: "Scott D. Yelich" <[EMAIL PROTECTED]>
22946 by: Brad Shelton <[EMAIL PROTECTED]>
22948 by: Mark Delany <[EMAIL PROTECTED]>
22953 by: Mate Wierdl <[EMAIL PROTECTED]>
22954 by: xs <[EMAIL PROTECTED]>
22956 by: Vince Vielhaber <[EMAIL PROTECTED]>
22958 by: Mark Delany <[EMAIL PROTECTED]>
22959 by: Roger Merchberger <[EMAIL PROTECTED]>
22960 by: Mate Wierdl <[EMAIL PROTECTED]>
22961 by: [EMAIL PROTECTED]
22962 by: Richard Antecki <[EMAIL PROTECTED]>
22963 by: xs <[EMAIL PROTECTED]>
22970 by: Marlon Anthony Abao <[EMAIL PROTECTED]>
queue-fix 1.4
22934 by: Eric Huss <[EMAIL PROTECTED]>
22942 by: [EMAIL PROTECTED]
22947 by: Peter van Dijk <[EMAIL PROTECTED]>
Network problems with high concurrencyremote
22936 by: "Fred Lindberg" <[EMAIL PROTECTED]>
Updating tcp.smtp file
22949 by: "Dave" <[EMAIL PROTECTED]>
22950 by: Chris Johnson <[EMAIL PROTECTED]>
22951 by: Mark Delany <[EMAIL PROTECTED]>
22952 by: "Dave" <[EMAIL PROTECTED]>
22955 by: "Dave" <[EMAIL PROTECTED]>
22957 by: "Dave" <[EMAIL PROTECTED]>
[LONG QUOTE] Re: dot-qmail security
22964 by: [EMAIL PROTECTED]
A problem with /var/qmail/rc
22965 by: [EMAIL PROTECTED]
22966 by: "Adam D. McKenna" <[EMAIL PROTECTED]>
[SOLVED] Re: A problem with /var/qmail/rc
22967 by: [EMAIL PROTECTED]
Problems with Qmail and Pine
22968 by: "Evans Martin" <[EMAIL PROTECTED]>
22969 by: "Adam D. McKenna" <[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]
----------------------------------------------------------------------
On Fri, Mar 12, 1999 at 11:19:30PM +0100, Harald Hanche-Olsen wrote:
> - torben fjerdingstad <[EMAIL PROTECTED]>:
>
> | On Fri, Mar 12, 1999 at 10:56:46AM -0500, Timothy L. Mayo wrote:
> | > You don't without a lot of work. The error message is the TXT
> | > record from the ORBS database. If Alan Brown wants the IP address
> | > in the message, he should modify his scripts to place it in the
> | > TXT record in his ORBS DNS database.
> |
> | What kind of work? Changing rblsmtpd?
>
> Why not? It shouldn't be too hard: In the check() routine, just
> before "if (message.len > 200) message.len = 200;" insert something
> along the lines of (** untested code follows **)
>
> x = env_get("TCPREMOTEIP");
> if (x)
> if (*x) {
> if (!stralloc_cats(&message, " (Remote IP: ")) die_sys();
> if (!stralloc_cats(&message, x) die_sys();
> if (!stralloc_cats(&message, ")")) die_sys();
> }
Thank you very much. It works after I added the missing ')'
right after 'x)' in the second die_sys() line.
> | At the same time I think it should be modified to be able to take
> | multiple -r flags.
>
> Would be useful. I'll leave that as an exercise for the reader. 8-)
Not done yet. I don't code much.
Thanks Harald!
--
Med venlig hilsen / Regards
Netdriftgruppen / Network Management Group
UNI-C
Tlf./Phone +45 35 87 89 41 Mail: UNI-C
Fax. +45 35 87 89 90 Bygning 304
E-mail: [EMAIL PROTECTED] DK-2800 Lyngby
Hi!!
I'm trying installing qmail 1.03 on my linux box with Debian 2.0
and kernel 2.0.34.
I did all INSTALL says to do, but making the third test (local-local
test: echo to: enr1co | /var/qmail/bin/qmail-inject) of TEST.deliver
i received an error in my syslog.
(I didn't passed from mailbox to maildir but i did a simbolik link
from /var/spool/mail/enr1co to /home/enr1co/Mailbox.
I set MAILHOST=iol.it and MAILUSER=enr1co in my .bash_profile(s).
All qmail daemons were running. My localhost is 'out').
This is my syslog:
Mar 12 20:37:37 out qmail: 921267457.446445 info msg 74001: bytes
190 from <[EMAIL PROTECTED]> qp 2269 uid 0
Mar 12 20:37:37 out qmail: 921267457.453123 starting delivery 7:
msg 74001 to local [EMAIL PROTECTED]
Mar 12 20:37:37 out qmail: 921267457.455606 status: local 1/10
remote 0/20
Mar 12 20:37:37 out qmail: 921267457.486754 delivery 7:
failure: Sorry,_no_mailbox_here_by_that_name._(#5.1.1)/
Mar 12 20:37:37 out qmail: 921267457.489978 status: local 0/10
remote 0/20
Mar 12 20:37:37 out qmail: 921267457.511358 bounce msg 74001 qp 2272
Mar 12 20:37:37 out qmail: 921267457.513089 end msg 74001
Mar 12 20:37:37 out qmail: 921267457.516306 new msg 74005
Mar 12 20:37:37 out qmail: 921267457.517269 info msg 74005: bytes
701 from <> qp 2272 uid 7796
Mar 12 20:37:37 out qmail: 921267457.525678 starting delivery 8:
msg 74005 to remote [EMAIL PROTECTED]
Mar 12 20:37:37 out qmail: 921267457.527208 status: local 0/10
remote 1/20
Mar 12 20:37:37 out qmail: 921267457.544726 delivery 8: deferral:
CNAME_lookup_failed_temporarily._(#4.4.3)/
Mar 12 20:37:37 out qmail: 921267457.545458 status: local 0/10
remote 0/20
Moreover if i try a 'telnet localhost 25' it ends with:
'Connection closed by foreign host'
___
Thank you very much,
Enrico Mangano.
Hello.
Is it possible to restrict dot-qmail capabilities for some users and allow
it for others. I have not found any info on this in the FAQ / README / etc.
The thing I'm worried about is the feature of pipe'ing the message to a command.
If there is no standard way of doing it, I'll just hack the code of qmail-local a bit,
but maybe some of you know of a better way?
/ Joel Eriksson
What mean things can happen if a user pipes the message to a command?
They can always do it using the shell anyways. The shell started in
.qmail is run by the user...
Mate
Joel Eriksson <[EMAIL PROTECTED]> writes:
| If there is no standard way of doing it, I'll just hack the code of qmail-local a
|bit,
| but maybe some of you know of a better way?
The best fix to change qmail to run pipes using /var/qmail/bin/sh
instead of /bin/sh. Then you can link that to /bin/sh or to
the restricted shell of your choice, like smrsh.
Mate Wierdl <[EMAIL PROTECTED]> writes:
| What mean things can happen if a user pipes the message to a command?
| They can always do it using the shell anyways. The shell started in
| .qmail is run by the user...
But it might be running on the mail server, where users cannot
normally log in, and where you only want to let them
run certain commands.
On Sun, 14 Mar 1999, Mate Wierdl wrote:
> What mean things can happen if a user pipes the message to a command?
> They can always do it using the shell anyways. The shell started in
> .qmail is run by the user...
You see, the server I am administrating does not allow shellaccess for
users, just POP3 and FTP (to put up webpages).
Of course the shell started by qmail-local to spawn commands specified in
dot-qmail files is run by the user itself. One of the main reasons for me
using Qmail is security.. :-)
Well, I just patched qmail-local.c to look in /var/qmail/control/staffusers for
usernames and match the UID of the user against the UID that owns the dot-qmail
file, so it's not a problem anymore for me. But I'm still interesting in
if there is some standard way of accomplishing this.
If there isn't, and someone has the same problem, just mail me for the patch.
> Mate
/ Joel Eriksson
On 14 Mar 1999, Scott Schwartz wrote:
> Joel Eriksson <[EMAIL PROTECTED]> writes:
> | If there is no standard way of doing it, I'll just hack the code of qmail-local a
>bit,
> | but maybe some of you know of a better way?
>
> The best fix to change qmail to run pipes using /var/qmail/bin/sh
> instead of /bin/sh. Then you can link that to /bin/sh or to
> the restricted shell of your choice, like smrsh.
Good point, that could be of use if some commands should be allowed. In
this case I don't want any commands at all to be allowed though, so I did
a quick patch myself. Thanks anyway!
/ Joel Eriksson
On Sun, Mar 14, 1999 at 04:59:24PM -0500, Scott Schwartz wrote:
> Mate Wierdl <[EMAIL PROTECTED]> writes:
> | What mean things can happen if a user pipes the message to a command?
> | They can always do it using the shell anyways. The shell started in
> | .qmail is run by the user...
>
> But it might be running on the mail server, where users cannot
> normally log in, and where you only want to let them
> run certain commands.
So script the .qmail creation for each user to be locked down by root
permissions.
What's the big deal?
--
Brad Shelton [EMAIL PROTECTED]
On Line Exchange http://ole.net
Detroit News http://detnews.com
On Sun, 14 Mar 1999, Brad Shelton wrote:
> > But it might be running on the mail server, where users cannot
> > normally log in, and where you only want to let them
> > run certain commands.
>
> So script the .qmail creation for each user to be locked down by root
> permissions.
What do you mean? In my case FTP is allowed to the server, but shellaccess is not.
Script the .qmail creation??
/ Joel Eriksson
Brad Shelton <[EMAIL PROTECTED]> writes:
| On Sun, Mar 14, 1999 at 04:59:24PM -0500, Scott Schwartz wrote:
| > Mate Wierdl <[EMAIL PROTECTED]> writes:
| > | What mean things can happen if a user pipes the message to a command?
| > | They can always do it using the shell anyways. The shell started in
| > | .qmail is run by the user...
| >
| > But it might be running on the mail server, where users cannot
| > normally log in, and where you only want to let them
| > run certain commands.
|
| So script the .qmail creation for each user to be locked down by root
| permissions.
|
| What's the big deal?
That's a big complicated change. In my environment, which I think is
typical, .qmail files are in home directories. Even if you have a
seperate mail partition, it's simplest and easiest to allow users to
create .qmail files using normal shell commands like vi. The issue
isn't that we want to restrict .qmail files, but that we might want to
restrict the commands that are executed on a particular cpu on behalf
of them. That correctly handles the problem in all cases, with no
ad-hoc restrictions on other kinds of delivery. Thus, the restricted
shell solution is the right one.
On Sun, Mar 14, 1999 at 11:26:54PM +0100, Joel Eriksson wrote:
> On Sun, 14 Mar 1999, Brad Shelton wrote:
>
> > > But it might be running on the mail server, where users cannot
> > > normally log in, and where you only want to let them
> > > run certain commands.
> >
> > So script the .qmail creation for each user to be locked down by root
> > permissions.
>
> What do you mean? In my case FTP is allowed to the server, but shellaccess is not.
> Script the .qmail creation??
Sure.
It can be part of the qmail default, or a create user process.
All you have to do is create it as root and make it readable by the mail
process for the user. They can read it, but they can't replace it.
--
Brad Shelton [EMAIL PROTECTED]
On Line Exchange http://ole.net
Detroit News http://detnews.com
> All you have to do is create it as root and make it readable by the mail
> process for the user. They can read it, but they can't replace it.
*sigh* I was just waiting for this to come up. I asked this question
regarding the .qmail security "reward" and was told that this doesn't
count. Gee, so I wonder the *next* time a security hole is found, if it
will also just be explained away as "well, it's possible with all the
others too" or "that doesn't count".
A file doesn't really matter if the user has write permissions
to the parent/current directory. Although the above statement
doesn't address this directly, I think it's misleading enough
to point out.
Scott
On Sun, Mar 14, 1999 at 06:12:05PM -0500, Scott Schwartz wrote:
> Brad Shelton <[EMAIL PROTECTED]> writes:
> | On Sun, Mar 14, 1999 at 04:59:24PM -0500, Scott Schwartz wrote:
> | > Mate Wierdl <[EMAIL PROTECTED]> writes:
> | > | What mean things can happen if a user pipes the message to a command?
> | > | They can always do it using the shell anyways. The shell started in
> | > | .qmail is run by the user...
> | >
> | > But it might be running on the mail server, where users cannot
> | > normally log in, and where you only want to let them
> | > run certain commands.
> |
> | So script the .qmail creation for each user to be locked down by root
> | permissions.
> |
> | What's the big deal?
>
> That's a big complicated change. In my environment, which I think is
> typical, .qmail files are in home directories. Even if you have a
> seperate mail partition, it's simplest and easiest to allow users to
> create .qmail files using normal shell commands like vi. The issue
> isn't that we want to restrict .qmail files, but that we might want to
> restrict the commands that are executed on a particular cpu on behalf
> of them. That correctly handles the problem in all cases, with no
> ad-hoc restrictions on other kinds of delivery. Thus, the restricted
> shell solution is the right one.
Oh. Sorry. I didn't know there was a "right one".
I thought it went something like, "Use what works for your environment.
That's why it's modular and flexible. Use at your own risk."
If I have a system that I don't want users, except in special cases, to have
the ability to put whatever they feel like in their .qmail files. you better
believe I'll do whatever I have to do, to stop them.... if I have to.
It sounded to me as if he needed (in this case) to stop users from doing so.
Simple. Disable the ability. Of course, that causes the need for him to do
the admin if something needs to be changed.
His decision. Not ours.
--
Brad Shelton [EMAIL PROTECTED]
On Line Exchange http://ole.net
Detroit News http://detnews.com
At 05:03 PM 3/14/99 -0700, Scott D. Yelich wrote:
>> All you have to do is create it as root and make it readable by the mail
>> process for the user. They can read it, but they can't replace it.
>
>*sigh* I was just waiting for this to come up.
It's actually come up quite a few times - check the archives. Most Unix
people know that the directory access is what counts and the owner of the
file doesn't stop anything. In fact I think last time it came up, we talked
about a separate $MAILHOME that was not directly accessible from ftp/shell.
>I asked this question regarding the .qmail security "reward" and was told
>that this doesn't count.
It's not doubt going to get religious, but I agree that it's not a hole. No
more than allowing pipe commands in a .forward is.
After all there are numerous ways in which shell access may be constrained,
it may exclude inbound ftp, it may exclude mail delivery it may exclude
finger access to a .plan file, it may exclude ~fred http access, it may
exclude access to some, but not all commands. Who knows what your particular
intent is? And, is it the same for every admin of every machine?
I don't see vi making magical tests to see whether you are really allowed to
execute a shell command. I don't see emacs making magical test to see
whether you are really allowed to execute a shell command, I don't see elm
or mailx or mail making a magical test to see whether you are really allowed
to execute a shell command.
That you think qmail-local has some divine way of knowing what exactly you
wish to constrain is endowing it with too much prescience.
Regards.
But if the users do not have shell access, how do they create .qmail files?
Mate
On Sun, Mar 14, 1999 at 10:57:41PM +0100, Joel Eriksson wrote:
> On Sun, 14 Mar 1999, Mate Wierdl wrote:
>
> > What mean things can happen if a user pipes the message to a command?
> > They can always do it using the shell anyways. The shell started in
> > .qmail is run by the user...
>
> You see, the server I am administrating does not allow shellaccess for
> users, just POP3 and FTP (to put up webpages).
>
> Of course the shell started by qmail-local to spawn commands specified in
> dot-qmail files is run by the user itself. One of the main reasons for me
> using Qmail is security.. :-)
>
> Well, I just patched qmail-local.c to look in /var/qmail/control/staffusers for
> usernames and match the UID of the user against the UID that owns the dot-qmail
> file, so it's not a problem anymore for me. But I'm still interesting in
> if there is some standard way of accomplishing this.
>
> If there isn't, and someone has the same problem, just mail me for the patch.
>
> > Mate
>
> / Joel Eriksson
>
--
---
Mate Wierdl | Dept. of Math. Sciences | University of Memphis
ftp?
end
-------------------------------------------------
Greg Albrecht Safari Internet
System Administrator Fort Lauderdale, FL
[EMAIL PROTECTED] www.safari.net
+1[888|954]537-9550
-------------------------------------------------
On Sun, 14 Mar 1999, Mate Wierdl wrote:
>But if the users do not have shell access, how do they create .qmail files?
>
>Mate
>On Sun, Mar 14, 1999 at 10:57:41PM +0100, Joel Eriksson wrote:
>> On Sun, 14 Mar 1999, Mate Wierdl wrote:
>>
>> > What mean things can happen if a user pipes the message to a command?
>> > They can always do it using the shell anyways. The shell started in
>> > .qmail is run by the user...
>>
>> You see, the server I am administrating does not allow shellaccess for
>> users, just POP3 and FTP (to put up webpages).
>>
>> Of course the shell started by qmail-local to spawn commands specified in
>> dot-qmail files is run by the user itself. One of the main reasons for me
>> using Qmail is security.. :-)
>>
>> Well, I just patched qmail-local.c to look in /var/qmail/control/staffusers for
>> usernames and match the UID of the user against the UID that owns the dot-qmail
>> file, so it's not a problem anymore for me. But I'm still interesting in
>> if there is some standard way of accomplishing this.
>>
>> If there isn't, and someone has the same problem, just mail me for the patch.
>>
>> > Mate
>>
>> / Joel Eriksson
>>
>
>--
>---
>Mate Wierdl | Dept. of Math. Sciences | University of Memphis
>
On 15-Mar-99 Mate Wierdl wrote:
> But if the users do not have shell access, how do they create .qmail files?
ftp it from their local machine. They'll be able to at least forward mail
and maybe do some simple lists, but I doubt they'd be able to do much more
than that without a real shell assigned - or can they?
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: [EMAIL PROTECTED] flame-mail: /dev/null
# include <std/disclaimers.h> TEAM-OS2
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
Or smb.
Often admins (at ISPs especially) give users some form of write access to
their home directories so they can fiddle with their ~user home page or
plonk stuff down for remote ftp.
They then think it's qmail's responsibility if that access also allows that
user to modify or create .qmail files.
It's really only a problem for sites that are small enough to have all of a
users home characteristics on one system. As soon as mail delivery is placed
on a dedicated service away from, eg, public_html, the problem goes away.
Until that time, they have to do work to ensure that the .qmail files cannot
be tampered with by the user if that's what they want to restrict.
Regards.
At 09:23 PM 3/14/99 -0500, xs wrote:
>
>ftp?
>
>
>end
>-------------------------------------------------
>Greg Albrecht Safari Internet
>System Administrator Fort Lauderdale, FL
>[EMAIL PROTECTED] www.safari.net
> +1[888|954]537-9550
>-------------------------------------------------
>
>On Sun, 14 Mar 1999, Mate Wierdl wrote:
>
>>But if the users do not have shell access, how do they create .qmail files?
>>
>>Mate
>>On Sun, Mar 14, 1999 at 10:57:41PM +0100, Joel Eriksson wrote:
>>> On Sun, 14 Mar 1999, Mate Wierdl wrote:
>>>
>>> > What mean things can happen if a user pipes the message to a command?
>>> > They can always do it using the shell anyways. The shell started in
>>> > .qmail is run by the user...
>>>
>>> You see, the server I am administrating does not allow shellaccess for
>>> users, just POP3 and FTP (to put up webpages).
>>>
>>> Of course the shell started by qmail-local to spawn commands specified in
>>> dot-qmail files is run by the user itself. One of the main reasons for me
>>> using Qmail is security.. :-)
>>>
>>> Well, I just patched qmail-local.c to look in
/var/qmail/control/staffusers for
>>> usernames and match the UID of the user against the UID that owns the
dot-qmail
>>> file, so it's not a problem anymore for me. But I'm still interesting in
>>> if there is some standard way of accomplishing this.
>>>
>>> If there isn't, and someone has the same problem, just mail me for the
patch.
>>>
>>> > Mate
>>>
>>> / Joel Eriksson
>>>
>>
>>--
>>---
>>Mate Wierdl | Dept. of Math. Sciences | University of Memphis
>>
>
On or about 06:30 PM 3/14/99 -0800, Mark Delany was caught in a dark alley
speaking these words:
>Often admins (at ISPs especially) give users some form of write access to
>their home directories so they can fiddle with their ~user home page or
>plonk stuff down for remote ftp.
[snip]
>It's really only a problem for sites that are small enough to have all of a
>users home characteristics on one system. As soon as mail delivery is placed
>on a dedicated service away from, eg, public_html, the problem goes away.
Right-o... *especially* in qmail's case. It's so processor / memory
miserly, that many start-up shops may have the chance to run everything
from one server, even if that server couldn't handle sendmail & web at the
same time.
Personally, I say: "Don't do it... it's a trap." If one box goes down, you
don't want _all_ of your services to say bye-bye. If you need to run a
backup DNS and/or authentication server anyway, it's best to divide mail &
web services, too.
That advice has saved my bacon more than a few times... :-)
Hope this helps,
Roger "Merch" Merchberger
=====
Roger "Merch" Merchberger -- [EMAIL PROTECTED]
SysAdmin - Iceberg Computers
===== Merch's Wild Wisdom of the Moment: =====
Sometimes you know, you just don't know sometimes, you know?
On Sun, Mar 14, 1999 at 09:27:38PM -0500, Vince Vielhaber wrote:
>
> On 15-Mar-99 Mate Wierdl wrote:
> > But if the users do not have shell access, how do they create .qmail files?
>
> ftp it from their local machine. They'll be able to at least forward mail
> and maybe do some simple lists, but I doubt they'd be able to do much more
> than that without a real shell assigned - or can they?
Well, perhaps they can have
|./zbot
where zbot is an irc channel guard program.
Mate
It is very easy to make users ftp in only to their ~home/public_html,
thus they will not be able to alter the .qmail files.
On Sun, Mar 14, 1999 at 06:30:59PM -0800, Mark Delany wrote:
> Often admins (at ISPs especially) give users some form of write access to
> their home directories so they can fiddle with their ~user home page or
> plonk stuff down for remote ftp.
Pashah
--
http://www.spb.sitek.net/~pashah/public-key-0x97739141.pgp
Forgive me for my stupidity, but can you please explain how this can be
done?
On Mon, 15 Mar 1999 [EMAIL PROTECTED] wrote:
> It is very easy to make users ftp in only to their ~home/public_html,
> thus they will not be able to alter the .qmail files.
>
> On Sun, Mar 14, 1999 at 06:30:59PM -0800, Mark Delany wrote:
> > Often admins (at ISPs especially) give users some form of write access to
> > their home directories so they can fiddle with their ~user home page or
> > plonk stuff down for remote ftp.
>
> Pashah
> --
> http://www.spb.sitek.net/~pashah/public-key-0x97739141.pgp
>
Richard Antecki
Fish Internet
Sydney Australia
or what about this:
.qmail:|MrCHFN-Wrapper.sh
and boom, they have a shell (disreguarding wrappers, etc..)
end
-------------------------------------------------
Greg Albrecht Safari Internet
System Administrator Fort Lauderdale, FL
[EMAIL PROTECTED] www.safari.net
+1[888|954]537-9550
-------------------------------------------------
On Sun, 14 Mar 1999, Vince Vielhaber wrote:
>
>On 15-Mar-99 Mate Wierdl wrote:
>> But if the users do not have shell access, how do they create .qmail files?
>
>ftp it from their local machine. They'll be able to at least forward mail
>and maybe do some simple lists, but I doubt they'd be able to do much more
>than that without a real shell assigned - or can they?
>
>Vince.
>--
>==========================================================================
>Vince Vielhaber -- KA8CSH email: [EMAIL PROTECTED] flame-mail: /dev/null
> # include <std/disclaimers.h> TEAM-OS2
> Online Campground Directory http://www.camping-usa.com
> Online Giftshop Superstore http://www.cloudninegifts.com
>==========================================================================
>
>
>
this is how we do it in our own site. lock user access to their public
directories.
don't allow users to access ~/.
-marlon
At 11:32 AM 3/15/99 +0300, [EMAIL PROTECTED] wrote:
>It is very easy to make users ftp in only to their ~home/public_html,
>thus they will not be able to alter the .qmail files.
>
>On Sun, Mar 14, 1999 at 06:30:59PM -0800, Mark Delany wrote:
>> Often admins (at ISPs especially) give users some form of write access to
>> their home directories so they can fiddle with their ~user home page or
>> plonk stuff down for remote ftp.
>
>Pashah
>--
> http://www.spb.sitek.net/~pashah/public-key-0x97739141.pgp
>
>
I have released a new version of queue-fix. This version fixes a serious
problem where it could delete messages from the queue. Thanks to Harald
Hanche-Olsen for alerting me to the bug.
queue-fix is a program for repairing the qmail queue. It will allow you
to move the queue, repair the queue after recreating the file system, or
even create a queue from scratch.
You can download queue-fix from:
http://www.netmeridian.com/e-huss/queue-fix.tar.gz
or
ftp://ftp.netmeridian.com/queue-fix.tar.gz
-Eric
Great program for fixing the queue. Hope I never have to use it.
I thought of another robust method for moving the queue, but
thankfully have never needed to try it. What do you think?
It employs djb's serialmail.
(install serialmail and follow install instructions in
<serialmail source>/TOISP including setting up a
virtual domain to which to deliver all mail to a maildir)
disable qmail-inject and qmail-smtpd so users can't add
things to the queue
kill -HUP <qmail-send pid> # recognize the virtual domain addition
/var/qmail/bin/qmail-tcpok # reset retry timeout
kill -ALRM <qmail-send pid> # reattempt all deliveries (into maildir)
/var/qmail/bin/qmail-qstat # check to make sure queue is empty
kill <qmail-lspawn pid> # shut down qmail
install qmail in a new location with 'make setup check' after
modifying the file locations, of course (even if just creating
a queue in a new location)
start up the new qmail
reenable qmail-inject and qmail-smtpd
use serialmail to deliver all the queued mail in the maildir back
into the queue
This should, in many cases, also work for queues low on disk space
because as things are delivered to the maildir (on a different partition
with more disk space!) space is created in the queue. (After issueing
qmail-tcpok, you can modify the delivery retry on the huge file(s) that
are stalling the queue so that when you give qmail-send a SIGALRM, it
doesn't attempt to deliver them yet)
Comments?
Glenn
> >
> > I have released a new version of queue-fix. This version fixes a serious
> > problem where it could delete messages from the queue. Thanks to Harald
> > Hanche-Olsen for alerting me to the bug.
> >
> > queue-fix is a program for repairing the qmail queue. It will allow you
> > to move the queue, repair the queue after recreating the file system, or
> > even create a queue from scratch.
> >
> > You can download queue-fix from:
> >
> > http://www.netmeridian.com/e-huss/queue-fix.tar.gz
> >
> > or
> >
> > ftp://ftp.netmeridian.com/queue-fix.tar.gz
> >
> > -Eric
>
>
On Sun, Mar 14, 1999 at 05:32:16PM -0500, [EMAIL PROTECTED] wrote:
>
> Great program for fixing the queue. Hope I never have to use it.
>
> I thought of another robust method for moving the queue, but
> thankfully have never needed to try it. What do you think?
> It employs djb's serialmail.
>
> (install serialmail and follow install instructions in
> <serialmail source>/TOISP including setting up a
> virtual domain to which to deliver all mail to a maildir)
>
> disable qmail-inject and qmail-smtpd so users can't add
> things to the queue
Hmm you really only need to disable qmail-queue, but disabling the other services too
might look better to your users :)
> kill -HUP <qmail-send pid> # recognize the virtual domain addition
> /var/qmail/bin/qmail-tcpok # reset retry timeout
> kill -ALRM <qmail-send pid> # reattempt all deliveries (into maildir)
> /var/qmail/bin/qmail-qstat # check to make sure queue is empty
> kill <qmail-lspawn pid> # shut down qmail
>
> install qmail in a new location with 'make setup check' after
> modifying the file locations, of course (even if just creating
> a queue in a new location)
> start up the new qmail
> reenable qmail-inject and qmail-smtpd
> use serialmail to deliver all the queued mail in the maildir back
> into the queue
>
> This should, in many cases, also work for queues low on disk space
> because as things are delivered to the maildir (on a different partition
> with more disk space!) space is created in the queue. (After issueing
> qmail-tcpok, you can modify the delivery retry on the huge file(s) that
> are stalling the queue so that when you give qmail-send a SIGALRM, it
> doesn't attempt to deliver them yet)
>
> Comments?
Yeah. This won't work. The messages are already queued for remote delivery.
There's a much simpler way: install the new qmail in a new location, use smtproutes
to deliver everything to localhost, start qmail-smtpd for the new qmail on port 25
but start qmail-send from the old qmail. Do the qmail-tcpok and kill -ALRM thingy,
and everything should be peachy.
Also, in your situation, you might as well just move the queue directory to another
directory on the _same_ filesystem, then moving it back after installing the new
qmail..
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:)
Hi,
I'm helping to set up an ezmlm host via ssh with
qmail-1.03/ezmlm/ezmlm-idx/cyclog/tcpserver. It's a PII-400x2/512MB
RAM/IDE which is also use for database work. The system works great
with a concurrencyremote of 100 (local=10, qmail-smtpd limited to 10
with tcpserver, identd not running) for hours (30-60 messages/day, 1000
subscribers per list). However, every other day, it's network-dead,
i.e. running, but the network connection doesn't work (connection
attempts to all ports time out). Initially, linux 2.2.3, but now also
with 2.0.36. Load average is <0.5 and deliveries etc look normal.
Sorry for the lack of info. I'm doing this via ssh and of course can't
do anything and have limited knowledge about hardware specifics. I
haven't been able to look through logs, but watched qmail/tcpserver
logs closely, not seeing anything out of the ordinary.
Are there any gotchas that are obvious to you?
Thanks!
-Sincerely, Fred
(Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)
Anyone know who checkpassword runs as? Isn't it the user?
If so, any ideas on how to modify a tcp.smtp file after checkpassword
succeeds? Only way I see to do it is open up permissions on the file, which
doesn't help when running tcprules (resets them).
my modified checkpassword auths the user then execl()'s a script to add
$TCPREMOTEIP to the tcp.smtp file if it does not exist.
Any help is greatly appreciated
-Dave
California Internet Connection
On Sun, Mar 14, 1999 at 06:00:01PM -0800, Dave wrote:
> Anyone know who checkpassword runs as? Isn't it the user?
>
> If so, any ideas on how to modify a tcp.smtp file after checkpassword
> succeeds? Only way I see to do it is open up permissions on the file, which
> doesn't help when running tcprules (resets them).
>
> my modified checkpassword auths the user then execl()'s a script to add
> $TCPREMOTEIP to the tcp.smtp file if it does not exist.
>
> Any help is greatly appreciated
checkpassword has to run as root, so that it can check passwords. It also has
to be able to exec qmail-pop3d with another user's uid, once that user is
authenticated.
Chris
At 06:00 PM 3/14/99 -0800, you wrote:
>Anyone know who checkpassword runs as? Isn't it the user?
No. It typically runs as root. It switches to the user and only root can do
that. You nominate the uid that it runs as on your tcpserver invocation.
What have you got there?
>If so, any ideas on how to modify a tcp.smtp file after checkpassword
>succeeds? Only way I see to do it is open up permissions on the file, which
>doesn't help when running tcprules (resets them).
>
>my modified checkpassword auths the user then execl()'s a script to add
>$TCPREMOTEIP to the tcp.smtp file if it does not exist.
Right. At that point the process is running as the user. If you want to
modify the file directly, all those users will need to have write access to
the file directly.
Another strategy might be to write TCPREMOTEIP to a temp file in a directory
that everyone has write access to, and have a separate cronjob/process scan
the directory adding entries into tcp.smtp.
The execl() script could be as simple as "touch /var/sometmp/$TCPREMOTEIP".
E&OE.
Regards.
>At 06:00 PM 3/14/99 -0800, you wrote:
>>Anyone know who checkpassword runs as? Isn't it the user?
>
>No. It typically runs as root. It switches to the user and only root can do
>that. You nominate the uid that it runs as on your tcpserver invocation.
>What have you got there?
>
>>If so, any ideas on how to modify a tcp.smtp file after checkpassword
>>succeeds? Only way I see to do it is open up permissions on the file,
which
>>doesn't help when running tcprules (resets them).
>>
>>my modified checkpassword auths the user then execl()'s a script to add
>>$TCPREMOTEIP to the tcp.smtp file if it does not exist.
>
>Right. At that point the process is running as the user. If you want to
>modify the file directly, all those users will need to have write access to
>the file directly.
>
>Another strategy might be to write TCPREMOTEIP to a temp file in a
directory
>that everyone has write access to, and have a separate cronjob/process scan
>the directory adding entries into tcp.smtp.
>
>The execl() script could be as simple as "touch /var/sometmp/$TCPREMOTEIP".
>E&OE.
>
>
>Regards.
>
>
>>tcpserver -u0 -g0 0 110 /var/qmail/bin/qmail-popup myhostname (not
>>literraly) /bin/checkpassword /var/qmail/bin/qmail-pop3d Maildir&
>
>So -u0 means uid 0.
yea
>>
>>>>If so, any ideas on how to modify a tcp.smtp file after checkpassword
>>>>succeeds? Only way I see to do it is open up permissions on the file,
>>which
>>>>doesn't help when running tcprules (resets them).
>>>>
>>>>my modified checkpassword auths the user then execl()'s a script to add
>>>>$TCPREMOTEIP to the tcp.smtp file if it does not exist.
>>>
>>>Right. At that point the process is running as the user. If you want to
>>>modify the file directly, all those users will need to have write access
to
>>>the file directly.
>>
>>but the execl is in the checkpassword program..
>
>Your own checkpassword program? Before or after the setuid() call?
I didn't see setuid() in the original program checkpassword.c (checkpassword
0.81 original) guess I better get greppin'
>>>Another strategy might be to write TCPREMOTEIP to a temp file in a
>>directory
>>>that everyone has write access to, and have a separate cronjob/process
scan
>>>the directory adding entries into tcp.smtp.
>>>
>>>The execl() script could be as simple as "touch
/var/sometmp/$TCPREMOTEIP".
>>>E&OE.
>>
>>Good idea.../tmp
>>
>>but somewhat defeats the purpose of pop before smtp. A user has to pop
then
>>wait for cron before smtp...
>
>True. But having a root program write to a fairly critical file presents
>risks.
>
>
>Regards.
>
>
Thanks guys,
I was one line below prot_gid and prot_uid which I didn't notice DOES call
setuid()..
It's all good now...
-Dave
California Internet Connection
On Mon, Mar 15, 1999 at 04:42:42PM +1100, Richard Antecki wrote:
> Forgive me for my stupidity, but can you please explain how this can be
> done?
This is an extract from proftpd menual:
-------
Syntax: DefaultRoot directory [group-expression]
Default: DefaultRoot /
Context: server config,<VirtualHost>
Compatibility: 0.99.0pl7 and later
The DefaultRoot directive controls the default root directory assigned
to a user upon login. If DefaultRoot is set to a directory other than
"/", a chroot operation is performed immediately after a client authenticates.
This can be used to effectively isolate the client from a portion of the
host system filespace. The specified root directory must begin with a / or
can be the magic character '~'; meaning that the client is chroot jailed
into their home directory. If the DefaultRoot directive specifies a
directory which disallows access to the logged-in user's home directory, the
user's current working directory after login is set to the DefaultRoot
instead of their normal home directory. DefaultRoot cannot be used in
<Anonymous> configuration blocks, as the <Anonymous> directive explicitly
contains a root directory used for Anonymous logins.
-----
so, if you have a line in your /etc/proftpd reading:
DefaultRoot ~/public_html ftpusers,!wheel
thouse who belong to ftpusers will be chroot jailed to ~/public_html, thouse
who belong to group whell will not.
hope this helps.
Pashah
--
http://www.spb.sitek.net/~pashah/public-key-0x97739141.pgp
Hi,
I`ve run upon a problem in /var/qmail/rc script ...
and spent the whole nite trying to solve it \%
it just wont start qmail-start ... if I try to use the cool daemontools ...
I used to have the default script they where running okay ...
due to some proprietary scripts running on the system I must use vsm
delivery ...
here is the script, maybe smd. can point me the mistake in it that stops
it from running the qmail-start:
---
#!/bin/sh
/usr/local/bin/supervise /usr/local/qmail/supervise/tcpserver env - \
PATH="/usr/local/bin:$PATH" TZ=MSK-3MSD \
/usr/bin/tcpserver -v -c 70 \
-u 71 -g 71 -x /etc/tcp.smtp.cdb 0 smtp /usr/local/bin/smtplog \
/usr/local/bin/rblsmtpd -rrelays.orbs.org \
/usr/local/bin/rblsmtpd \
/var/qmail/bin/qmail-smtpd 2>&1 | /usr/local/bin/accustamp \
| /usr/local/bin/cyclog -s100004000 -n5 /var/log/smtpd &
/usr/local/bin/supervise /var/run/supervise/qmail-send env - \
PATH="/usr/local/bin:$PATH" TZ=MSK-3MSD \
/var/qmail/bin/qmail-start '|preline procmail' /usr/local/bin/accustamp \
| /usr/local/bin/cyclog -s100004000 -n5 /var/log/maillog &
---
Any pointers are welcome,
Pashah
--
http://www.spb.sitek.net/~pashah/public-key-0x97739141.pgp
From: <[EMAIL PROTECTED]>
:/usr/local/bin/supervise /var/run/supervise/qmail-send env - \
:PATH="/usr/local/bin:$PATH" TZ=MSK-3MSD \
:/var/qmail/bin/qmail-start '|preline procmail' /usr/local/bin/accustamp \
:| /usr/local/bin/cyclog -s100004000 -n5 /var/log/maillog &
Well, first of all cyclog doesn't log to a file, it logs to a directory.
Second of all you're going to give cyclog 500 megs of logs? (n5 x 100 megs
specified in -s)
Third, make sure there are no spaces after the \ characters you have at the
end of your lines.
Make sure /var/log/maillog/ exists and is a directory.
>NAME
> supervise - start and monitor a service
>
>SYNOPSIS
>supervise [ -rsudox ] dir program [ args ... ]
I.E. you may want to do those "env" commands BEFORE running supervise.
--Adam
Oops, that was a really silly one (:
my PATH statement didn`t contain /var/qmail/bin ...
all fine now, thanx Adam.
[ssnip]
On Mon, Mar 15, 1999 at 01:07:35AM -0500, Adam D. McKenna wrote:
> :/usr/local/bin/supervise /var/run/supervise/qmail-send env - \
> :PATH="/usr/local/bin:$PATH" TZ=MSK-3MSD \
[ssnip]
Pashah
--
http://www.spb.sitek.net/~pashah/public-key-0x97739141.pgp
I am receiving the following message when I start Pine.
Mailbox vulnerable - error creating
/var/spool/mail/evans.lock.921481778.8749
The following are the details on my /var/spool/mail directory:
drwxrwxr-x 2 root mail 1024 Mar 15 00:55 mail
This is the info on /var/spool/mail/evans
-rw-rw---- 1 evans mail 517 Mar 15 00:53 evans
I am running qmail 1.03. Any ideas on what I'm doing wrong here?
Thanks,
Evans
-----------------------------------------------------------------
Martek Computer Co. http://www.martek.net
Evans Martin, Owner <[EMAIL PROTECTED]>
3102 Boulder Park Drive Nashville, TN 37214
(615) 871-0711 Voice (615) 874-0931 FAX
-----------------------------------------------------------------
UNLIMITED INTERNET ACCESS - ONLY $16.95 PER MONTH
-----------------------------------------------------------------
From: Evans Martin <[EMAIL PROTECTED]>
:I am receiving the following message when I start Pine.
:
:Mailbox vulnerable - error creating
:/var/spool/mail/evans.lock.921481778.8749
:
:The following are the details on my /var/spool/mail directory:
:
:drwxrwxr-x 2 root mail 1024 Mar 15 00:55 mail
:
:This is the info on /var/spool/mail/evans
:
:-rw-rw---- 1 evans mail 517 Mar 15 00:53 evans
:
:I am running qmail 1.03. Any ideas on what I'm doing wrong here?
This has nothing to do with qmail, it has to do with file permissions. That
should be obvious from the error message you are getting.
Either make the pine binary setgid mail, or change the permissions on
/var/spool/mail to allow pine to write its tempfile there. Or (a better
solution) change the place where pine puts its tempfile to /var/tmp or some
other world-writable directory.
Or (an even better solution), configure qmail to deliver to your home
directory.
--Adam
