qmail Digest 17 Mar 1999 11:00:01 -0000 Issue 582
Topics (messages 23017 through 23052):
CNAME_
23017 by: Harald Hanche-Olsen <[EMAIL PROTECTED]>
[LONG QUOTE] Re: dot-qmail security
23018 by: "Oliver Thuns" <[EMAIL PROTECTED]>
rblsmtp - I need to change the bounce report.
23019 by: torben fjerdingstad <[EMAIL PROTECTED]>
Back-up scheme, 2 qmail servers
23020 by: Krzysztof Dabrowski <[EMAIL PROTECTED]>
23021 by: Cris Daniluk <[EMAIL PROTECTED]>
23022 by: Eric Dahnke <[EMAIL PROTECTED]>
23023 by: Eric Dahnke <[EMAIL PROTECTED]>
23038 by: Ari Rubenstein <[EMAIL PROTECTED]>
23046 by: Cris Daniluk <[EMAIL PROTECTED]>
Fwd: round robin rcpt's
23024 by: xs <[EMAIL PROTECTED]>
Mail loop problem
23025 by: Mark E Drummond <[EMAIL PROTECTED]>
23029 by: Harald Hanche-Olsen <[EMAIL PROTECTED]>
23030 by: Mark E Drummond <[EMAIL PROTECTED]>
23031 by: "Sam" <[EMAIL PROTECTED]>
23039 by: "Matt Kercher" <[EMAIL PROTECTED]>
ezmlm and "delay notifies" (was: Re: mini-bounce)
23026 by: "Fred Lindberg" <[EMAIL PROTECTED]>
23028 by: Bruno Wolff III <[EMAIL PROTECTED]>
keeping users from running shells
23027 by: "Adam D. McKenna" <[EMAIL PROTECTED]>
23045 by: Cris Daniluk <[EMAIL PROTECTED]>
23047 by: "Adam D. McKenna" <[EMAIL PROTECTED]>
23048 by: Andrzej Wadas <[EMAIL PROTECTED]>
dot-qmail security
23032 by: Matthias Pigulla <[EMAIL PROTECTED]>
23034 by: Joel Eriksson <[EMAIL PROTECTED]>
23035 by: Joel Eriksson <[EMAIL PROTECTED]>
23037 by: Joel Eriksson <[EMAIL PROTECTED]>
23040 by: Dave Sill <[EMAIL PROTECTED]>
Should tcpserver block connections once conccurrency has been reached
23033 by: Mark Delany <[EMAIL PROTECTED]>
[Fwd: Qmail smtp delivery]
23036 by: Donna Phillips <[EMAIL PROTECTED]>
Did this work?
23041 by: Robin Bowes <[EMAIL PROTECTED]>
23042 by: Peter van Dijk <[EMAIL PROTECTED]>
23043 by: Robin Bowes <[EMAIL PROTECTED]>
23044 by: Peter van Dijk <[EMAIL PROTECTED]>
new user's mail loops - reason unclear
23049 by: Andreas Schuldei <[EMAIL PROTECTED]>
Unusual Delivery Problem
23050 by: "Karl Lellman" <[EMAIL PROTECTED]>
23052 by: Harald Hanche-Olsen <[EMAIL PROTECTED]>
MX Problems through Firewall
23051 by: "Karl Lellman" <[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]
----------------------------------------------------------------------
- RJP <[EMAIL PROTECTED]>:
|
| G'Day.
| I have been sporadically trying to set up Qmail-1.03 for about 3 weeks
| now and keep running into:
|
| Mar 16 09:07:53 SedricWorks qmail: 921575273.166915 status: local 0/10
| remote 2/20
| Mar 16 09:07:53 SedricWorks qmail: 921575273.276501 delivery 4:
| deferral: CNAME_lookup_failed_temporarily._(#4.4.3)/
Could you please tell us what address this is trying to deliver to?
Then we can start looking for a DNS problem.
| grep says that the deferral: message emanates from qmail-send.c
| line 935 which just after a call to read(), & that is where I lose it at
| the moment through not knowing enough about how the unix libraries work.
| Presumably read()'s file handle is actually the end of a pipe which is
| expected to be connected through to the ISP server but isn't?
No, the pipe leads eventually to qmail-remote, which is calling
temp_dnscanon() from line 304 in qmail-remote.c.
- Harald
>> This is an extract from proftpd menual:
>
>Has anyone managed to get proftpd to actually chroot?
Yes :-)
On Sun, Mar 14, 1999 at 02:48:09PM +0100, torben fjerdingstad wrote:
> On Fri, Mar 12, 1999 at 11:19:30PM +0100, Harald Hanche-Olsen wrote:
> > - torben fjerdingstad <[EMAIL PROTECTED]>:
> >
> > | 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.
One more question. Do the rblsmtpd dns lookups happen concurrently
in this case? (I hope so):
tcpserver -x /usr/local/etc/tcp.smtp.cdb \
-v -p -t 5 -c 400 -b 40 -u 203 -g 200 0 \
smtp /usr/local/bin/smtplog \
/usr/local/bin/rblsmtpd -rrelays.orbs.org \
/usr/local/bin/rblsmtpd -rrbl.maps.vix.com \
/usr/local/bin/rblsmtpd -rdul.maps.vix.com \
/usr/local/qmail/bin/qmail-smtpd 2>&1 \
| /usr/local/bin/accustamp \
| /usr/local/bin/cyclog -s100004000 -n2 /var/adm/smtpd smtpd 3 &
P.S. last saturday the out-of-the-country connection was down. So was
rblsmtp because there are no nameservers for maps.vix.org in my
here. Every smtp connection was severely crawling, waiting for
dns replies.
--
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
>My question is, will there be any implications "Out_There" of suddenly
>having a new IP and hostname for our mailserver, assuming we make the
>appro DNS changes?
Maybe you could arrange it on your router via port forwarding? You set it
up to forward all conenction for ports 25 i 110 to first machine. set up
the secod to monitor the first one and in an event of failure, dynamicaly
reconfigure port forwarding on your router to point to the second machine.
later on , when your first machine is up and running you can manualy revert
your router to the previous state (or even make it automatic too). Hope
you've got what i mean (sorry for bad english).
Kris
Eric Dahnke wrote:
> Hello List,
>
> We have a server moving about 9000 msgs per day and want to have a
> second qmail server waiting on our network to take over in the event of
> a failure.
>
> Our current thinking is:
>
> - an identical qmail installation on a backup machine
> - daily copy of /home /control and /alias to backup machine
> - in the event of a massive failure unplug the ethernet from the main
> server and plug into the backup machine.
>
> (I realize we will lose the queue --normally just full of waiting
> bounces-- and all msgs received for local users since the last backup)
>
> My question is, will there be any implications "Out_There" of suddenly
> having a new IP and hostname for our mailserver, assuming we make the
> appro DNS changes?
>
> Any other comments on this kind of idle machine waiting backup scheme?
> (the main mail server is dpt raid fived)
>
> cheers - eric
Why don't you just set up your second server as an MX server and use the
handy dandy MX routing feature in named to automatically reroute mail in
the event of a failure. The MX server will hold all the messages while you
repair your server and automatically resend them when everything is back
online.
This is probably the perfect solution for you, *especially* since you have
a raid 5. Don't be looking for a harddrive failure anytime soon :) Your
harddrives are the only irreplaceable components because they contain your
data, so anything else could be repairable in the time it takes you to
scrounge up the hardware.
--
Cris Daniluk [EMAIL PROTECTED]
-------------------------------------------------------------
Digital Services Network, Inc. http://www.dsnet.net
1129 Niles-Cortland Road, Warren, Ohio 44484 [EMAIL PROTECTED]
(330) 609-8624 ext. 20 Fax (330) 609-9990
The Web Hosting Specialists
-------------------------------------------------------------
Andy Walden escribió:
> >
> > - an identical qmail installation on a backup machine
> > - daily copy of /home /control and /alias to backup machine
> > - in the event of a massive failure unplug the ethernet from the main
> > server and plug into the backup machine.
> >
> > (I realize we will lose the queue --normally just full of waiting
> > bounces-- and all msgs received for local users since the last backup)
> >
> > My question is, will there be any implications "Out_There" of suddenly
> > having a new IP and hostname for our mailserver, assuming we make the
> > appro DNS changes?
>
> If its not going to be online unless failure occurs, why would you give it
> a different ip or hostname?
Because the two machines are connected via a second 192. network which does
the backup. Therefore, must have different IP's and hostname.
thx - eric
Cris Daniluk escribió:
> Eric Dahnke wrote:
>
> > Hello List,
> >
> > We have a server moving about 9000 msgs per day and want to have a
> > second qmail server waiting on our network to take over in the event of
> > a failure.
> >
> > Our current thinking is:
> >
> > - an identical qmail installation on a backup machine
> > - daily copy of /home /control and /alias to backup machine
> > - in the event of a massive failure unplug the ethernet from the main
> > server and plug into the backup machine.
> >
> > (I realize we will lose the queue --normally just full of waiting
> > bounces-- and all msgs received for local users since the last backup)
> >
> > My question is, will there be any implications "Out_There" of suddenly
> > having a new IP and hostname for our mailserver, assuming we make the
> > appro DNS changes?
> >
> > Any other comments on this kind of idle machine waiting backup scheme?
> > (the main mail server is dpt raid fived)
> >
> > cheers - eric
>
> Why don't you just set up your second server as an MX server and use the
> handy dandy MX routing feature in named to automatically reroute mail in
> the event of a failure. The MX server will hold all the messages while you
> repair your server and automatically resend them when everything is back
> online.
>
> This is probably the perfect solution for you, *especially* since you have
> a raid 5. Don't be looking for a harddrive failure anytime soon :) Your
> harddrives are the only irreplaceable components because they contain your
> data, so anything else could be repairable in the time it takes you to
> scrounge up the hardware.
OK, I was thinking about something similar, but you've got me here. You say
"The MX server will hold all the messages while you repair your server and
automatically resend them when everything is back online."
What do you mean by hold all the messages?
Our mailserver does both smtp and pop, so therein lies the problem. Great, so
the MX rolls and the backup server accepts smtp for our domains. But what
about pop? When the primary server comes back up, users would need to pop both
servers to get all their mail, and that would turn into a mess.
Or am I not understanding.
thx - eric
On Tue, 16 Mar 1999, Eric Dahnke wrote:
> What do you mean by hold all the messages?
>
> Our mailserver does both smtp and pop, so therein lies the problem. Great, so
> the MX rolls and the backup server accepts smtp for our domains. But what
> about pop? When the primary server comes back up, users would need to pop both
> servers to get all their mail, and that would turn into a mess.
>
> Or am I not understanding.
I have one subdomain with something like this:
- primary mail server, has lower MX records, users, pop, imap, etc.
- secondary mail server, higher MX records, no users, no pop, etc.
If the primary mail server goes down, messages are queued on the backup
server. This is accomplished by making the backup server a "null client"
as defined in the qmail FAQ.
When the primary server comes back online after a failure, the queued
messages on the backup server are delivered to the primary server.
Pop users would have an interuption in service, but no lost messages.
In the case of an extened outage of the primary server, you could build or
fall back to a entirely different primary server by changing the MX
records for your mail domain, and changing the qmail/control/smtproutes
file.
- Ari
--------------------------------------------------------------------------
Ari Rubenstein Unix Operations Engineer
Digex, West Coast Sun Cert'd SysAdmin
[EMAIL PROTECTED]
408-873-4256
Eric Dahnke wrote:
> Cris Daniluk escribió:
>
> > Eric Dahnke wrote:
> >
> > > Hello List,
> > >
> > > We have a server moving about 9000 msgs per day and want to have a
> > > second qmail server waiting on our network to take over in the event of
> > > a failure.
> > >
> > > Our current thinking is:
> > >
> > > - an identical qmail installation on a backup machine
> > > - daily copy of /home /control and /alias to backup machine
> > > - in the event of a massive failure unplug the ethernet from the main
> > > server and plug into the backup machine.
> > >
> > > (I realize we will lose the queue --normally just full of waiting
> > > bounces-- and all msgs received for local users since the last backup)
> > >
> > > My question is, will there be any implications "Out_There" of suddenly
> > > having a new IP and hostname for our mailserver, assuming we make the
> > > appro DNS changes?
> > >
> > > Any other comments on this kind of idle machine waiting backup scheme?
> > > (the main mail server is dpt raid fived)
> > >
> > > cheers - eric
> >
> > Why don't you just set up your second server as an MX server and use the
> > handy dandy MX routing feature in named to automatically reroute mail in
> > the event of a failure. The MX server will hold all the messages while you
> > repair your server and automatically resend them when everything is back
> > online.
> >
> > This is probably the perfect solution for you, *especially* since you have
> > a raid 5. Don't be looking for a harddrive failure anytime soon :) Your
> > harddrives are the only irreplaceable components because they contain your
> > data, so anything else could be repairable in the time it takes you to
> > scrounge up the hardware.
>
> OK, I was thinking about something similar, but you've got me here. You say
> "The MX server will hold all the messages while you repair your server and
> automatically resend them when everything is back online."
>
> What do you mean by hold all the messages?
>
> Our mailserver does both smtp and pop, so therein lies the problem. Great, so
> the MX rolls and the backup server accepts smtp for our domains. But what
> about pop? When the primary server comes back up, users would need to pop both
> servers to get all their mail, and that would turn into a mess.
>
> Or am I not understanding.
>
> thx - eric
I think you are a bit confused as to what an MX really is. Your MX server, once
properly configured, will put the mail messages sent to users on your regular
server in a holding queue. Once this server is back online, the MX server will
jump in and send off these messages that it has been holding. There is no
POP involved on this server. As far as POP access on your other server, yes, it
IS down, but no messages will be lost. Once the server goes back up, the MX will
send off the mail and users will get all their messages. They'll never notice
anything happened, except for the annoying inconvenience of the server being down
for a while.
--
Cris Daniluk [EMAIL PROTECTED]
-------------------------------------------------------------
Digital Services Network, Inc. http://www.dsnet.net
1129 Niles-Cortland Road, Warren, Ohio 44484 [EMAIL PROTECTED]
(330) 609-8624 ext. 20 Fax (330) 609-9990
The Web Hosting Specialists
-------------------------------------------------------------
elite, thats exactly what i need. i was gonna take the code someone else
had posted and write my own ticketing system, but this is much cooler.
thanks to everyone.
-xs
On Tue, 16 Mar 1999, Guy Antony Halse wrote:
>> hey all,
>> i was wondering if anyone knew of a package that did this, or perhaps
>> something qmail might allready have that will round robin messages to
>> different rcpt's, for example:
>
>Hiya ...
>
>I have written a program that does just this, we use it for our help@rucus
>address. It round robins between any number of people, and does mail
>threading (so that one person always deals with the same query irrespective
>of the number of messages sent). It also ensures that all outgoing and
>incomming mail can be archived (usefull for preparing faqs, etc) and
>provides a followup method for unresolved queries.
>
>Basically each message is issued with a ticket and a unique id number which
>is used by the program to keep track of, and distribute the mail. The
>information is stored in a flatfile database that is easily queried (grep :)
>when people want to make follow up queries.
>
>The program wasn't originally intended for distribution (arm pulling by
>other sysadmin who is on this list ;) so is rather poorly documented. The
>code should be self explanitory though.
>
>If you would like to look at and/or play arround with the script, it is
>available under GPL from
>
>ftp://rucus.ru.ac.za/pub/mail/other/tracker.tgz
>
>All I ask is that you let me have a copy of any improvements that you make :)
>
>Oh, and I am not on this list, so please direct any comments/queries to me
>at the email address below.
>
>- Guy
>--
> \\\\ Mon Dieu! Nous sommes dans la merde ////
> (o o) __ __ (o o)
>_________oOOo__(_)__oOOo_______(__)_____(__)_______oOOo__(_)__oOOo____
>| The ideas and opinions expressed | Rhodes University, South Africa | J
>| above are mine, not yours. They | Email: [EMAIL PROTECTED] | A
>| could be for a small fee though. | http://www.rucus.ru.ac.za/~guy | P
>|_____________________________oOOo_______oOOo________________________| H
> (__) (__) ||||| (__) (__)
>
Hi folks. I put my new qmail based MX into production yesterday and it
is working great. However, I have one problem and I am not sure which
end I should look to for the answer.
My setup is an external gateway machine running qmail (our MX),
forwarding mail for our domain to our internal mailhub running Netscape
Messaging Server (NMS) which all our users access using IMAP.
The problem is that mail to a non-existant or mispelled address within
our domain gets sent to the internal hub, which checks it and does not
find a valid RCPT, and so it sends the email back to the MX. Now the MX,
instead of bouncing the email back to the sender, it returns it to the
internal hub, which then sends it back again to the MX.
An example, someone outside our domain ([EMAIL PROTECTED]) sends an
email to [EMAIL PROTECTED] The MX for mydomain.com checks the
RCPT and sees that it is destined for our domain so it relays the
message on to our internal hub. The hub, realising that unknownuser does
not exist should bounce the message. Only the message gets sent back to
the MX, which for some reason returns the message back to the hub
instead of returning it the original sender.
This is probably just a lack of understanding on my part (I'm relatively
new to postmaster duties) leading to a misconfiguration somewhere. My
question is, is this qmail's problem or NMS's problem?
--
_________________________________________________________________
Mark E Drummond Royal Military College of Canada
mailto:[EMAIL PROTECTED] Computing Services
Linux Uber Alles perl || die
- Mark E Drummond <[EMAIL PROTECTED]>:
| My setup is an external gateway machine running qmail (our MX),
| forwarding mail for our domain to our internal mailhub running
| Netscape Messaging Server (NMS) which all our users access using
| IMAP.
|
| The problem is that mail to a non-existant or mispelled address
| within our domain gets sent to the internal hub, which checks it and
| does not find a valid RCPT, and so it sends the email back to the
| MX.
That's your problem, as far as I can understand it. Your NMS needs to
be told that it, and it alone, is the final authority on what is a
valid email address within your domain, and so it should produce a
proper bounce message if it is not.
| Now the MX, instead of bouncing the email back to the sender, it
| returns it to the internal hub, which then sends it back again to
| the MX.
As well it should: How can it tell the difference between this
message and any other message destined for your domain? Bounce
creation needs to happen where the final delivery was supposed to
happen; anything else just gets too difficult.
| My question is, is this qmail's problem or NMS's problem?
You will never get anyone on this list to admit it's qmail's problem. 8-)
- harald
Harald Hanche-Olsen wrote:
>
> - Mark E Drummond <[EMAIL PROTECTED]>:
>
> | My setup is an external gateway machine running qmail (our MX),
> | forwarding mail for our domain to our internal mailhub running
> | Netscape Messaging Server (NMS) which all our users access using
> | IMAP.
> |
> | The problem is that mail to a non-existant or mispelled address
> | within our domain gets sent to the internal hub, which checks it and
> | does not find a valid RCPT, and so it sends the email back to the
> | MX.
>
> That's your problem, as far as I can understand it. Your NMS needs to
> be told that it, and it alone, is the final authority on what is a
> valid email address within your domain, and so it should produce a
> proper bounce message if it is not.
This is what I figured. Only I have no idea why NMS is sending bounces
to the MX. It does not send anything else to the MX, it delivers it
itself. Hmmmm... I'll keep looking. Thanks!
--
_________________________________________________________________
Mark E Drummond Royal Military College of Canada
[EMAIL PROTECTED] Computing Services
Linux Uber Alles perl || die
Mark E Drummond writes:
> The problem is that mail to a non-existant or mispelled address within
> our domain gets sent to the internal hub, which checks it and does not
Your "internal hub" is broken. Contact your software vendor for a fix. If
your software vendor is unable to produce a properly-written mail server,
switch to different software.
--
Sam
On Tue, Mar 16, 1999 at 09:27:24AM -0500, Mark E Drummond wrote:
> The problem is that mail to a non-existant or mispelled address within
> our domain gets sent to the internal hub, which checks it and does not
> find a valid RCPT, and so it sends the email back to the MX. Now the MX,
> instead of bouncing the email back to the sender, it returns it to the
> internal hub, which then sends it back again to the MX.
I had a similar problem with an internal GroupWise host (piece of trash)
that I had to support. Because most users use our main domain address
@ndo.navy.mil, and all mail was routed through our 2 qmail hubs, I found
that the most managable solution was to build aliases, common misspellings,
and real locals into a fastforward database on both hubs. I set this up as
a virtual domain on both hubs, had a .qmail-default catchall look up the
final delivery address, and forward the mail internally to the GW server
using the verified correct address. This setup killed our previous 100+
errors a month down to 0. All mail incorrectly addressed (not in the
fastforward tables) is delivered to postmaster for manual routing. Works
very well.
A side benefit of this design is that as users move, additional hosts are
added, or changes in configurations are made; the address stays the same,
we only have to update the fastforward tables.
--
Matt
On Mon, 15 Mar 1999 18:22:50 -0500, Justin Bell wrote:
>but vacation messages shouldnt be replying to list email, right?
1. ezmlm lists can be set up via DIR/headeradd to contain "Precedence:
Bulk". Vacation programs should not respond to these. ezmlm-idx since
quite a while does this by default.
2. ezmlm-0.53 has ezmlm-weed which weeds out delivery (delay)
notifications. As long as the notifications conform to that format,
they will not be seen as bounces. Again, I don't see the point in
sending delivery notifications to "Precedence: bulk" messages.
-Sincerely, Fred
(Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)
On Mon, Mar 15, 1999 at 06:13:15PM -0500,
Scott Schwartz <[EMAIL PROTECTED]> wrote:
> Peter van Dijk <[EMAIL PROTECTED]> writes:
> | But yes, it would consider these warnings as bounces.
>
> It also considers vacation messages to be bounces. :-(
Vacation programs shouldn't be replying to lists.
Sorry for the late reply, but this isn't a qmail problem, it's a unix file
permissions problem.
# groupadd shellusr
# vi /etc/group
# chown root.shellusr /bin/csh
# chmod 750 /bin/csh
# chown root.shellusr /bin/sh
# chmod 750 /bin/sh
# chown root.shellusr /bin/ksh
# chmod 750 /bin/ksh
etc.. Of course you need to be careful when doing this and make sure every
user that could possibly need shell access is included (including any users
that have cron jobs running under their UID).. etc.. but this is possible
without modifying qmail (and taking out a very important feature).
--Adam
"Adam D. McKenna" wrote:
> Sorry for the late reply, but this isn't a qmail problem, it's a unix file
> permissions problem.
>
> # groupadd shellusr
> # vi /etc/group
> # chown root.shellusr /bin/csh
> # chmod 750 /bin/csh
> # chown root.shellusr /bin/sh
> # chmod 750 /bin/sh
> # chown root.shellusr /bin/ksh
> # chmod 750 /bin/ksh
>
> etc.. Of course you need to be careful when doing this and make sure every
> user that could possibly need shell access is included (including any users
> that have cron jobs running under their UID).. etc.. but this is possible
> without modifying qmail (and taking out a very important feature).
>
> --Adam
Isn't there a *real* way to do this? I swear there is...
--
Cris Daniluk [EMAIL PROTECTED]
-------------------------------------------------------------
Digital Services Network, Inc. http://www.dsnet.net
1129 Niles-Cortland Road, Warren, Ohio 44484 [EMAIL PROTECTED]
(330) 609-8624 ext. 20 Fax (330) 609-9990
The Web Hosting Specialists
-------------------------------------------------------------
From: Cris Daniluk <[EMAIL PROTECTED]>
:Isn't there a *real* way to do this? I swear there is...
By "real way", do you mean a way that's not already built into your operating
system?
--Adam
Perhaps it is somehow off the subject but related to file permissions on mail
account.
My customers need http virtual servers so I made extra directory Page on mail
account wher Mailbox file resides. They can ftp to own mail account using the
same
name and passw as the do to read post. They transfer files onto Page.
However, Http server needs a customer directory to be eXecutable for others to
be
able to run index.html on Page directory. Mailbox file itself is only readable
by the
owner. Does such a structure brings any danger?
Andrzej
"Adam D. McKenna" wrote:
> Sorry for the late reply, but this isn't a qmail problem, it's a unix file
> permissions problem.
>
> # groupadd shellusr
> # vi /etc/group
> # chown root.shellusr /bin/csh
> # chmod 750 /bin/csh
> # chown root.shellusr /bin/sh
> # chmod 750 /bin/sh
> # chown root.shellusr /bin/ksh
> # chmod 750 /bin/ksh
>
> etc.. Of course you need to be careful when doing this and make sure every
> user that could possibly need shell access is included (including any users
> that have cron jobs running under their UID).. etc.. but this is possible
> without modifying qmail (and taking out a very important feature).
>
> --Adam
Juan Carlos Castro y Castro wrote:
> > But it would fix in no way the problems in this thread.
>
> Maybe it would be too much for the person who originally brought the
> question, because users would be unable to do anything with their .qmail
> while what the guy wanted was only to prevent them from running
> programs. But I fail to see why the problem wouldn't be solved.
If only .qmail-extension is disabled, people can still pipe data into a
shell in their .qmail file.
Matthias
--
w e b f a c t o r y | matthias pigulla
www.webfactory.de [EMAIL PROTECTED]
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?
>From qmail-local.c:
args[0] = "/bin/sh"; args[1] = "-c"; args[2] = prog; args[3] = 0;
sig_pipedefault();
execv(*args,args);
strerr_die3x(111,"Unable to run /bin/sh: ",error_str(errno),". (#4.3.0)");
So, indeed they can.
> Vince.
/ Joel Eriksson
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.
chroot() is broken on Solaris 2.5.1, which is running on the server. But
it doesn't matter anyway, since I made a patch for the problem myself.
> 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
/ Joel Eriksson
On Mon, 15 Mar 1999, Dave Sill wrote:
> Brad Shelton <[EMAIL PROTECTED]> 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.
>
> Not true. If the user can write the directory, they can replace it.
They can _read_ it, but not write to it at all. :-) Maildir and other
files / directories must be made by root and chown'ed to the user.
> -Dave
/ Joel Eriksson
Joel Eriksson <[EMAIL PROTECTED]> wrote:
>
>On Mon, 15 Mar 1999, Dave Sill wrote:
>
>> Brad Shelton <[EMAIL PROTECTED]> 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.
>>
>> Not true. If the user can write the directory, they can replace it.
>
>They can _read_ it, but not write to it at all. :-) Maildir and other
>files / directories must be made by root and chown'ed to the user.
I didn't say "write", I said "replace". E.g.:
Script started on Tue Mar 16 15:39:17 1999
sh-2.00$ ls -la
total 40
drwxr-xr-x 2 de5 user 40 Mar 16 15:39 .
drwxr-xr-x 54 de5 user 20480 Mar 16 15:37 ..
-r--r--r-- 1 root sys 0 Mar 16 15:38 bar
-rw-r--r-- 1 de5 user 0 Mar 16 15:39 typescript
sh-2.00$ cat bar
sh-2.00$ echo foo>bar
sh: bar: Permission denied
sh-2.00$ rm bar
bar: 444 mode. Remove ? (yes/no)[no] : y
sh-2.00$ ls -la
total 40
drwxr-xr-x 2 de5 user 28 Mar 16 15:39 .
drwxr-xr-x 54 de5 user 20480 Mar 16 15:37 ..
-rw-r--r-- 1 de5 user 0 Mar 16 15:39 typescript
sh-2.00$ exit
script done on Tue Mar 16 15:39:53 1999
-Dave
At 09:14 AM 3/16/99 +0000, Yusuf Goolamabbas wrote:
>Hi, I am currently using tcpserver on a Linux 2.0.36 box/RH 5.2 box
>I have setup tcpserver with a limit of 5 connections via -c5 and
>backlog of 1 with -b1
>
>However, when I start up the 7th and subsequent connection, I
>basically get held up waiting for the smtpgreeting string which will
>occur as soon as I close some other connection.
This is often a function of your OS. tcpserver is merely using
listen/accept/connect and it relies on the OS to handle the cases where, eg,
the backlog value in listen() is exceeded.
On some OSes, as I understand it, the listen() value uis silently ignored or
constrained so the value you set via tcpserver may not be the actual value
used by the OS.
>are in the ESTABLISHED state. If I were to increase concurrency limit
>to something higher, is there a possibility that the OS TCP tables
>might become full, with most entries primarily waiting for connections
>to complete.
In general, I would expect that you'd run out of other resources before
running out of some OS table associated with the accept queue. Resources,
such as memory or disk. I've always set concurrency based on have much of
the main system resources I wanted to allocate to that particular service
(disk, memory, CP, bandwidth).
In other words, set concurrency to values that make sense for the main
resources you have and the amount of service you want to offer and the OS
accept queue sizes are unlikely to be relevant.
> Would it be better to refuse connection ?
I'm not sure it's defined what happens when the backlog value is exceeded.
Here's what Freebsd has on the listen() manpage:
* If a connection request arrives with the queue
* full the client may receive an error with an indication of ECONNREFUSED,
* or, if the underlying protocol supports retransmission, the request may
* be ignored so that retries may succeed.
Note the inconclusive use of "may". Check your Linux manpage to see what it
says.
>Is there a patch to tcpserver which does something similar or this
>concept/idea is bogus :-)
I haven't looked lately, but I'd guess that sendmail is making the same
system calls.
Regards.
> I'm looking for a way to have qmail 1.03 deliver mail to Maildir's which all
> have the same uid/gid. I'm have vchkpw-3.1.3 running, and I know I can
> accomplish the task via this method, however I do not want to require 7.5k users
> to change their mail settings to include the domain name in the login for pop3.
>
> Right now, I have my dialup users authenticating via radius on a Sun Netra
> running Solaris 2.6. My current mail server is a Sparc20 with Solaris 2.6 and
> qmail 1.03. We are using SSH to rsync the passwd/shadow files to the mail server
> when updates are made. Maildirs are created on the mail server only. The sparc20
> is on it's last legs however. I'm setting up a new machine with FreeBSD 3.1 and
> qmail 1.03. I'm moving from an alias based system to the vchkpw method for
> handling virtual domains, which works fine. I do not want to overwrite the
> passwd/shadow on my bsd server with a copy from the Solaris machine, so I rename
> the files on copy and have modified vchkpw to check these renamed files instead
> of those defined in pwd.h for that system.
>
> So far, everything works fine except smtp which is where I'm stuck. I'd like
> to have mail delivered to the Maildirs which all use the same uid/gid so as to
> not conflict with any existing ID's on the servers original passwd/shadow..using
> the vpopmail ID instead in a similar manner to vchkpw, but without needing a
> 'user@domain' for the login as vchkpw requires for virtual domains. The
> passwd/shadow copied from the radius server would be for authentication and path
> information only. Any help would be appreciated.
>
> --
> Stephen C. Comoletti
> Asst. Systems Administrator
> DELANET, Inc. http://www.delanet.com
> TEL: (302) 326-5800, FAX: (302) 326-5802
A test.
--
Two rules to success in life:
1. Don't tell people everything you know.
-- Sassan Tat
On Tue, Mar 16, 1999 at 11:03:23PM +0000, Robin Bowes wrote:
> A test.
Depending on what you're trying, I think it did :)
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:)
Peter van Dijk wrote:
>
> On Tue, Mar 16, 1999 at 11:03:23PM +0000, Robin Bowes wrote:
> > A test.
>
> Depending on what you're trying, I think it did :)
<g>
I'm testing my mailing list <--> newsgroup gateway.
I *think* I've just about got to the bottom of it, except the program I
use to re-write messages ready for posting to my newsgroup is completely
broken. I am using DNews 5.0f on Linux 2.2.2ac7 which comes with a
program called drobot.
Anyone got any better suggestions? I've seen mention of mail2new and
newsgate - any good?
R.
--
Two rules to success in life:
1. Don't tell people everything you know.
-- Sassan Tat
On Tue, Mar 16, 1999 at 11:53:16PM +0000, Robin Bowes wrote:
> Peter van Dijk wrote:
> >
> > On Tue, Mar 16, 1999 at 11:03:23PM +0000, Robin Bowes wrote:
> > > A test.
> >
> > Depending on what you're trying, I think it did :)
>
> <g>
>
> I'm testing my mailing list <--> newsgroup gateway.
>
> I *think* I've just about got to the bottom of it, except the program I
> use to re-write messages ready for posting to my newsgroup is completely
> broken. I am using DNews 5.0f on Linux 2.2.2ac7 which comes with a
> program called drobot.
Well you have two To: headers, and I saw a cancel from you coming by earlier today.
Apart from that, it looks quite alright :)
If you are really pedantic, check out the ietf draft on messages both posted and
mailed..
> Anyone got any better suggestions? I've seen mention of mail2new and
> newsgate - any good?
Beats me. I hate newsgroups, I'd rather have all newsgroups come in as mailinglists.
Actually, I'm working on a system to do just that.
Here is my minimalistic poster: :) (goes into .qmail-default on my qnews user :)
# from | newsgroup
#|./postto $EXT
|{ set;cat } | qmail-inject peter
|{ echo -ne "POST\nPath: koek.attic.vuurwerk.nl!peter\nNewsgroups: $EXT\n" ; cat |
grep -v ^Received: | grep -v "^ " ; echo -e ".\nQUIT\n" } | /usr/local/bin/nc
news2.cistron.nl 119 | qmail-inject peter
(those last 3 lines are actually 1 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:)
Linux 2.0.30, qmail 1.0.1
I created the new users account, run qmail-pw2u and qmail-newu and
shecked the assign-file.
the new users .qmail file seems to work:
oliver@paul:/home/oliver > /var/qmail/bin/qmail-local -n $USER ~ $USER
'' '' '' '' ./Mailbox
maildir /home/oliver/.mailspool/
did 1+0+0
but when he sents himself a mail it loops:
Hi. This is the qmail-send program at paul.andrive.de.
I'm afraid I wasn't able to deliver your message to the following
addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
<[EMAIL PROTECTED]>:
This message is looping: it already has my Delivered-To line. (#5.4.6)
--- Below this line is a copy of the
message.
Return-Path:
<[EMAIL PROTECTED]>
Received: (qmail 1181 invoked by alias); 17 Mar 1999 08:30:03
-0000
Delivered-To:
[EMAIL PROTECTED]
Received: (qmail 1178 invoked by alias); 17 Mar 1999 08:30:03
-0000
Delivered-To:
[EMAIL PROTECTED]
Received: (qmail 1174 invoked by uid 0); 17 Mar 1999 08:30:02
-0000
Date: 17 Mar 1999 08:30:02
-0000
Message-ID:
<[EMAIL PROTECTED]>
From:
[EMAIL PROTECTED]
To:
[EMAIL PROTECTED]
Subject:
asdf
Hi. This is the qmail-send program at paul.andrive.de.
I'm afraid I wasn't able to deliver your message to the following
addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
<[EMAIL PROTECTED]>:
This message is looping: it already has my Delivered-To line. (#5.4.6)
--- Below this line is a copy of the
message.
Return-Path:
<[EMAIL PROTECTED]>
Received: (qmail 1181 invoked by alias); 17 Mar 1999 08:30:03
-0000
Delivered-To:
[EMAIL PROTECTED]
Received: (qmail 1178 invoked by alias); 17 Mar 1999 08:30:03
-0000
Delivered-To:
[EMAIL PROTECTED]
Received: (qmail 1174 invoked by uid 0); 17 Mar 1999 08:30:02
-0000
Date: 17 Mar 1999 08:30:02
-0000
Message-ID:
<[EMAIL PROTECTED]>
From:
[EMAIL PROTECTED]
To:
[EMAIL PROTECTED]
Subject:
asdf
asdf
his .qmail-file is trivial:
/home/oliver/.mailspool/
and of cause it has only this one line.
How can I check what is going wrong?
Please cc: to [EMAIL PROTECTED]
asdf
I have a customer who is running Qmail 1.03. They are having a lot of
bounce's when trying to deliver mail to a specific site.
Originating mail domain is 'renaissance.co.nz'. MX entry for
'renaissance.co.nz' points to 'mail.renaissance.co.nz' (202.97.88.10).
Outgoing mail through firewall reverse lookups to 'renaissance.co.nz'
(202.97.88.2).
Destination mail domain is 'eagle.co.nz'. MX entry for eagle.co.nz resolves
to 'relay.eagle.co.nz' (202.36.45.1).
Whenever the 'renaissance.co.nz' qmail server tries to deliver mail to
'relay.eagle.co.nz' it logs the following error...
Connected to 202.36.45.1 but my name was rejected./Remote host said: 220
ESMTP tried here/
The SMTP server administrator at eagle.co.nz has contacted the customer
about the mail bounces and emailed him the following entries that appear in
their logs...
At Mon Mar 15 18:22:27 1999
call from renaissance.co.nz/203.97.88.2
220-relay ESMTP SMTP/smap Ready.
220 ESMTP tried here
HELO renaissance.co.nz
250 (renaissance.co.nz) pleased to meet you.
QUIT
221 Closing connection
It looks as if the Qmail machine is connecting, passing a HELO command and
then just QUITing. Can anyone explain to me what is going on here?
Thanks,
Karl Lellman
Systems Consultant
Extranet Technologies Limited
PO Box 47-808, Auckland, New Zealand
Mobile +64 25 771188, Fax +64 9 3094631
e-mail: [EMAIL PROTECTED]
- "Karl Lellman" <[EMAIL PROTECTED]>:
| Whenever the 'renaissance.co.nz' qmail server tries to deliver mail to
| 'relay.eagle.co.nz' it logs the following error...
|
| Connected to 202.36.45.1 but my name was rejected./Remote host said: 220
| ESMTP tried here/
|
| The SMTP server administrator at eagle.co.nz has contacted the customer
| about the mail bounces and emailed him the following entries that appear in
| their logs...
|
| At Mon Mar 15 18:22:27 1999
| call from renaissance.co.nz/203.97.88.2
| 220-relay ESMTP SMTP/smap Ready.
| 220 ESMTP tried here
| HELO renaissance.co.nz
| 250 (renaissance.co.nz) pleased to meet you.
| QUIT
| 221 Closing connection
|
| It looks as if the Qmail machine is connecting, passing a HELO
| command and then just QUITing. Can anyone explain to me what is
| going on here?
As far as I can tell, this falls into the ``this cannot happen''
category. I contacted the SMTP port on relay.eagle.co.nz myself, it
responds exactly as shown above, with each line CRLF terminated and no
fuzz about it. It looks like qmail-remote has stopped reading the
response after the first line (the one with the hyphen), leaving the
second line to be interpreted as the response to the HELO command.
But, as far as I can read the source in qmail-remote.c (the first few
lines in smtp() and all of smtpcode(), only ~20 lines in all) there is
no way this can happen. So unless this is a patched version of qmail,
I can see no rational explanation for this.
- Harald
I have a customer who is running Qmail 1.03 server (running on Linux).
The Qmail server is located in a DMZ behind a firewall. All incoming mail
is proxied through from the internet to the Qmail server in the DMZ which
then relays it in to an Exchange server on the internal network. All
outgoing mail is relayed from the Exchange server to the Qmail server on the
DMZ which then delivers it.
The problem that they are having is that when the Qmail server tries to
deliver the email the following happens....
Qmail server does a lookup of the relevant MX/DNS records for the mail
domain.
Qmail makes a SMTP connection to the first MX entry for the mail domain.
- In reality the Qmail server is making a SMTP connection through the
default gateway (the firewall). As it is a proxy based firewall, it makes a
SMTP connection to the first MX entry of the mail domain on behalf of the
Qmail server.
The server listed as the first MX entry for the mail domain is not currently
alive.
The SMTP connection from the firewall to the remote SMTP server 'fails'.
The firewall drops the connection that the Qmail server has made to it.
This connection is 'lost'.
Qmail says 'I had a connection but it was lost' and so flags that IP address
to try later.
Qmail tries that IP address later, again and again and again.
Qmail never steps to the next MX entry for the mail domain.
The mail doesn't get through!
I have talked to the firewall manufacturer about this, but they say that
there is nothing they
can do.
Does anyone have any ideas or ways to get around this?
Thanks,
Karl Lellman
Systems Consultant
Extranet Technologies Limited
PO Box 47-808, Auckland, New Zealand
Mobile +64 25 771188, Fax +64 9 3094631
e-mail: [EMAIL PROTECTED]
