qmail Digest 11 Sep 1999 10:00:00 -0000 Issue 756
Topics (messages 30089 through 30132):
Still 533
30089 by: Vince Vielhaber <[EMAIL PROTECTED]>
30098 by: Paul Farber <[EMAIL PROTECTED]>
Patches revisited
30090 by: Vince Vielhaber <[EMAIL PROTECTED]>
30091 by: "Lyndon Griffin" <[EMAIL PROTECTED]>
30093 by: Russell Nelson <[EMAIL PROTECTED]>
30094 by: Russell Nelson <[EMAIL PROTECTED]>
30096 by: Greg Hudson <[EMAIL PROTECTED]>
30101 by: Russell Nelson <[EMAIL PROTECTED]>
30114 by: "Lyndon Griffin" <[EMAIL PROTECTED]>
30115 by: Eric Dahnke <[EMAIL PROTECTED]>
30116 by: "Lyndon Griffin" <[EMAIL PROTECTED]>
30120 by: "David Dyer-Bennet" <[EMAIL PROTECTED]>
30121 by: "Adam D . McKenna" <[EMAIL PROTECTED]>
30127 by: Ruben van der Leij <[EMAIL PROTECTED]>
qmail needs rcpt to own home dir ?
30092 by: "Robin Bowes" <[EMAIL PROTECTED]>
qmail distro and UID
30095 by: Russell Nelson <[EMAIL PROTECTED]>
30097 by: Mirko Zeibig <[EMAIL PROTECTED]>
30099 by: [EMAIL PROTECTED] (Frank D. Cringle)
30103 by: Sam <[EMAIL PROTECTED]>
30104 by: "David Harris" <[EMAIL PROTECTED]>
30118 by: Kevin Waterson <[EMAIL PROTECTED]>
30119 by: Kevin Waterson <[EMAIL PROTECTED]>
30128 by: [EMAIL PROTECTED]
qmail & relay detection
30100 by: [EMAIL PROTECTED]
30102 by: Sam <[EMAIL PROTECTED]>
30107 by: Dave Sill <[EMAIL PROTECTED]>
30109 by: "Mr. Christopher F. Miller" <[EMAIL PROTECTED]>
30112 by: "David Dyer-Bennet" <[EMAIL PROTECTED]>
30122 by: Sam <[EMAIL PROTECTED]>
30123 by: "James J. Lippard" <[EMAIL PROTECTED]>
30125 by: [EMAIL PROTECTED]
30126 by: Sam <[EMAIL PROTECTED]>
30130 by: "D. J. Bernstein" <[EMAIL PROTECTED]>
Webpage "Send"
30105 by: [EMAIL PROTECTED]
30106 by: James Smallacombe <[EMAIL PROTECTED]>
Selective forwarding using .qmail
30108 by: Damon Parker <[EMAIL PROTECTED]>
30110 by: Dave Sill <[EMAIL PROTECTED]>
30117 by: Peter Gradwell <[EMAIL PROTECTED]>
relay rules question
30111 by: Patrick Berry <[EMAIL PROTECTED]>
30113 by: Tim Hunter <[EMAIL PROTECTED]>
Outlook Groupware Functions
30124 by: "Stephan Hadan" <[EMAIL PROTECTED]>
Qmail dies over and over
30129 by: Gustavo V G C Rios <[EMAIL PROTECTED]>
30132 by: Jos Backus <[EMAIL PROTECTED]>
POP3: premature NOOP OK, NOT an RFC 1939 Compliant server
30131 by: "Olivier M." <[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, 10 Sep 1999, Paulo Jan wrote:
> Paul Farber wrote:
> >
> > Yeah, I know. But the binary .cdb file is pretty unreadable, don't you
> > think?
> >
> > Paul D. Farber II
> > Farber Technology
> > Ph. 570-628-5303
> > Fax 570-628-5545
> > [EMAIL PROTECTED]
> >
> > On Thu, 9 Sep 1999, Adam D . McKenna wrote:
> >
> > > That's not a cdb, it's a flat textfile. You need to compile it into a cdb
> > > using tcprules.
> > >
>
>
> That's the point. The cdb file is NOT supposed to be human-readable;
> it's a binary format designed to be read by tcpserver (and other
> programs). See ftp://koobera.math.uic.edu/www/cdb.html.
That's why Paul DIDN'T post the .cdb file. He posted the contents
of the file used to generate it. In an earlier message he also posted
his method for generating the .cdb. Did you really want him to post the
binary?
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
==========================================================================
The jist of the response was, no, I didn't use a plain text file for the
.cbd file in tcpserver.
Thanks.
Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax 570-628-5545
[EMAIL PROTECTED]
On Thu, 9 Sep 1999, James Smallacombe wrote:
> On Thu, 9 Sep 1999, Paul Farber wrote:
>
> > Yeah, I know. But the binary .cdb file is pretty unreadable, don't you
> > think?
>
> unreadable by you, but it's what tcpserver reads. AFAIK, tcpserver can't
> read unhashed plaintext. The command to do this changed in recent
> tcpservers; You now use tcprules instead of tcpmakectl...it does pretty
> much the same thing. You can also use tcprulescheck to check it against an
> ip.
>
> Also, if the following isn't all on one line (ie, if you edit it with pico
> without using -w), make sure you put a \ on the end of the first line.
>
> 28500 ? S 0:01 tcpserver -v -H -R -c100 -x
> /etc/tcprules.d/qmail-smtpd.cdb -u81 -g80 0 smtp qmail-smtpd
>
>
On Fri, 10 Sep 1999, Lyndon Griffin wrote:
> A while back, someone was trying to assemble a comprehensive patch list
> and archive. I would like to volunteer to host this.
>
> My only request - at least, initially - is that patch authors *only*
> submit to me their patches, along with a blurb of what the patch does and
> what requirements (outside of QMail) the patch may depend on.
>
> Of course, if somebody knows of a site already doing this, that URL is
> welcome, and I may withdraw my offer.
Have you been to www.qmail.org?
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
==========================================================================
Yeah, I went back, now that you mention it, and I see a lot of work has been
done since I wrote it off as a dead-loss for information months ago. No
offense, Russ, but the presentation of information there is about as good as
any geoshitties site. And yes, that can be taken as an offer to help make
things better, hence the reason for starting this thread.
> -----Original Message-----
> From: Vince Vielhaber [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 10, 1999 3:47 AM
> To: Lyndon Griffin
> Cc: [EMAIL PROTECTED]
> Subject: Re: Patches revisited
>
>
> On Fri, 10 Sep 1999, Lyndon Griffin wrote:
>
> > A while back, someone was trying to assemble a comprehensive patch list
> > and archive. I would like to volunteer to host this.
> >
> > My only request - at least, initially - is that patch authors *only*
> > submit to me their patches, along with a blurb of what the
> patch does and
> > what requirements (outside of QMail) the patch may depend on.
> >
> > Of course, if somebody knows of a site already doing this, that URL is
> > welcome, and I may withdraw my offer.
>
> Have you been to www.qmail.org?
>
> 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
> ==========================================================================
>
>
>
>
Lyndon Griffin writes:
> Of course, if somebody knows of a site already doing this, that URL is
> welcome, and I may withdraw my offer.
http://www.qmail.org/top.html#addons . You can argue that it needs
improvement, but it's the canonical list.
--
-russ nelson <[EMAIL PROTECTED]> http://russnelson.com
Crynwr sells support for free software | PGPok | Government schools are so
521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Lyndon Griffin writes:
> Yeah, I went back, now that you mention it, and I see a lot of work has been
> done since I wrote it off as a dead-loss for information months ago. No
> offense, Russ, but the presentation of information there is about as good as
> any geoshitties site. And yes, that can be taken as an offer to help make
> things better, hence the reason for starting this thread.
No offense, but your web site sucks? How *am* I supposed to take that
other than as offensive? I mean, c'mon, really. If you think it
sucks, say so, but don't think you can say it without hurting my
feelings. It's best to strike the phrase "No offense, but" from your
vocabulary.
I prefer to list everything on one page because it minimizes latency.
You download the page once, which doesn't take too awful long because
there's almost no graphics. Then you use your browser's search
function to find things that the internal navigation links don't bring
you to by browsing. This, instead of the usual "click, wait. click,
wait" you get from most other web sites. You can't do much with a
small wait, but you can usually find something to do with a big wait
to download a big page.
So, since you think you can do better, what would you do differently?
Split the page up? That would waste people's time. Add more
information? I'm fine with that -- "send code", as they say.
--
-russ nelson <[EMAIL PROTECTED]> http://russnelson.com
Crynwr sells support for free software | PGPok | Government schools are so
521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
> So, since you think you can do better, what would you do
> differently? Split the page up? That would waste people's time.
> Add more information? I'm fine with that -- "send code", as they
> say.
There's always the approach of "one big page with an index at the top
where the index links point to anchors within the page."
(I'm not saying there's a natural way to split the page up, but you
can split the page up without increasing latency, although it won't be
quite the same as splitting it up the normal way.)
In another message, you wrote:
> If I was making a distribution, *I* would reserve some UIDs <100.
> The chances that you'll run into a conflict in an upgrade a very
> small. I'd include a program to check for a conflict, and reassign
> the existing UID.
Of course, once a site starts making use of network filesystems, it
doesn't matter what UIDs are "reserved" by new operating systems, and
no simple tool can make reassigning UIDs easy. Eventually someone is
going to feel some pain. It happens.
Greg Hudson writes:
> > So, since you think you can do better, what would you do
> > differently? Split the page up? That would waste people's time.
> > Add more information? I'm fine with that -- "send code", as they
> > say.
>
> There's always the approach of "one big page with an index at the top
> where the index links point to anchors within the page."
That's what I'm doing.
> In another message, you wrote:
>
> > If I was making a distribution, *I* would reserve some UIDs <100.
> > The chances that you'll run into a conflict in an upgrade a very
> > small. I'd include a program to check for a conflict, and reassign
> > the existing UID.
>
> Of course, once a site starts making use of network filesystems, it
> doesn't matter what UIDs are "reserved" by new operating systems, and
> no simple tool can make reassigning UIDs easy. Eventually someone is
> going to feel some pain. It happens.
Right, well the alternatives are to read the UIDs at runtime (and we
all know how successful we've been at convincing Dan to allow *THAT*
change), or to edit the executables at runtime, which of course
means that the executables no longer match the checksums on the CDROM.
--
-russ nelson <[EMAIL PROTECTED]> http://russnelson.com
Crynwr sells support for free software | PGPok | Government schools are so
521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
>From the presentation of information perspective, the site is not all that
good. Technically speaking, it is very good - fast loading, not a lot of BS
graphics, accessible with all browsers, including the elite few of us who
still use Lynx. I am concerned about the quality and quantity of
information on the site. Certainly, QMail is a force in the industry, and I
imagine that you and Dan Bernstein and countless others want it to be
an even more powerful force. QMail is making money, of that there can be no
doubt. Dan has a book deal, and you have a consultancy. People that use
QMail are also making money - Hotmail, Blue Mountain Arts, NetDynamics, for
instance. I like QMail, I want to continue to use QMail. I want to be
informed about QMail, and my previous experience from www.qmail.org is that
it is not a place to get informed. Yes, there is a patch list now on the
page, and I applaud that effort. I never would have looked if I hadn't been
slammed, however, because I had already written off www.qmail.org as a
dead-loss for information.
I know other people that have come away from the site with that same
impression - even worse, I've had people tell me that the product must suck
because the web site sucks. I don't argue with them because - number one,
I've had a lot of trouble getting to the information I want, number two
image is everything. It's the American Way, it's why companies advertise,
and it's why people spend billions of dollars on the Internet. QMail is not
a product that can continue to stand on it's own merits - people obviously
have a lot of trouble with it, just look at the volume on this mailing list.
It's time that information about QMail becomes as robust as QMail itself.
Hearing from me that the site sucks shouldn't make you feel bad - after all,
what do you know about me? I'm certainly no guru on QMail, which is the
foundation of my criticism for the QMail site. There isn't a nice way to
say that something sucks, lest you not get the message across. I prefer to
be blunt. I got your attention. The current site, in my opinion, hurts
QMail more that it helps. I have offered to help you, and my offer stands.
It's easy to say something sucks. It's hard to do something about it.
Let's do something about it.
> -----Original Message-----
> From: Russell Nelson [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 10, 1999 5:31 AM
> To: QMail List
> Subject: RE: Patches revisited
>
>
> Lyndon Griffin writes:
> > Yeah, I went back, now that you mention it, and I see a lot of
> work has been
> > done since I wrote it off as a dead-loss for information
> months ago. No
> > offense, Russ, but the presentation of information there is
> about as good as
> > any geoshitties site. And yes, that can be taken as an offer
> to help make
> > things better, hence the reason for starting this thread.
>
> No offense, but your web site sucks? How *am* I supposed to take that
> other than as offensive? I mean, c'mon, really. If you think it
> sucks, say so, but don't think you can say it without hurting my
> feelings. It's best to strike the phrase "No offense, but" from your
> vocabulary.
>
> I prefer to list everything on one page because it minimizes latency.
> You download the page once, which doesn't take too awful long because
> there's almost no graphics. Then you use your browser's search
> function to find things that the internal navigation links don't bring
> you to by browsing. This, instead of the usual "click, wait. click,
> wait" you get from most other web sites. You can't do much with a
> small wait, but you can usually find something to do with a big wait
> to download a big page.
>
> So, since you think you can do better, what would you do differently?
> Split the page up? That would waste people's time. Add more
> information? I'm fine with that -- "send code", as they say.
>
> --
> -russ nelson <[EMAIL PROTECTED]> http://russnelson.com
> Crynwr sells support for free software | PGPok | Government
> schools are so
> 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any
> rank amateur
> Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them.
> Homeschool!
>
Sorry for prolonging this most likely annoying thread, but I completely
disagree with you.
On the currentsite you've got simple access to qmail sources, man pages,
list archives, patches, support, etc and it is well organized.
What do you want animated gifs and sound?
- eric
Lyndon Griffin escribió:
>
> >From the presentation of information perspective, the site is not all that
> good. Technically speaking, it is very good - fast loading, not a lot of BS
> graphics, accessible with all browsers, including the elite few of us who
> still use Lynx. I am concerned about the quality and quantity of
> information on the site. Certainly, QMail is a force in the industry, and I
> imagine that you and Dan Bernstein and countless others want it to be
> an even more powerful force. QMail is making money, of that there can be no
> doubt. Dan has a book deal, and you have a consultancy. People that use
> QMail are also making money - Hotmail, Blue Mountain Arts, NetDynamics, for
> instance. I like QMail, I want to continue to use QMail. I want to be
> informed about QMail, and my previous experience from www.qmail.org is that
> it is not a place to get informed. Yes, there is a patch list now on the
> page, and I applaud that effort. I never would have looked if I hadn't been
> slammed, however, because I had already written off www.qmail.org as a
> dead-loss for information.
>
> I know other people that have come away from the site with that same
> impression - even worse, I've had people tell me that the product must suck
> because the web site sucks. I don't argue with them because - number one,
> I've had a lot of trouble getting to the information I want, number two
> image is everything. It's the American Way, it's why companies advertise,
> and it's why people spend billions of dollars on the Internet. QMail is not
> a product that can continue to stand on it's own merits - people obviously
> have a lot of trouble with it, just look at the volume on this mailing list.
> It's time that information about QMail becomes as robust as QMail itself.
>
> Hearing from me that the site sucks shouldn't make you feel bad - after all,
> what do you know about me? I'm certainly no guru on QMail, which is the
> foundation of my criticism for the QMail site. There isn't a nice way to
> say that something sucks, lest you not get the message across. I prefer to
> be blunt. I got your attention. The current site, in my opinion, hurts
> QMail more that it helps. I have offered to help you, and my offer stands.
> It's easy to say something sucks. It's hard to do something about it.
> Let's do something about it.
>
> > -----Original Message-----
> > From: Russell Nelson [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, September 10, 1999 5:31 AM
> > To: QMail List
> > Subject: RE: Patches revisited
> >
> >
> > Lyndon Griffin writes:
> > > Yeah, I went back, now that you mention it, and I see a lot of
> > work has been
> > > done since I wrote it off as a dead-loss for information
> > months ago. No
> > > offense, Russ, but the presentation of information there is
> > about as good as
> > > any geoshitties site. And yes, that can be taken as an offer
> > to help make
> > > things better, hence the reason for starting this thread.
> >
> > No offense, but your web site sucks? How *am* I supposed to take that
> > other than as offensive? I mean, c'mon, really. If you think it
> > sucks, say so, but don't think you can say it without hurting my
> > feelings. It's best to strike the phrase "No offense, but" from your
> > vocabulary.
> >
> > I prefer to list everything on one page because it minimizes latency.
> > You download the page once, which doesn't take too awful long because
> > there's almost no graphics. Then you use your browser's search
> > function to find things that the internal navigation links don't bring
> > you to by browsing. This, instead of the usual "click, wait. click,
> > wait" you get from most other web sites. You can't do much with a
> > small wait, but you can usually find something to do with a big wait
> > to download a big page.
> >
> > So, since you think you can do better, what would you do differently?
> > Split the page up? That would waste people's time. Add more
> > information? I'm fine with that -- "send code", as they say.
> >
> > --
> > -russ nelson <[EMAIL PROTECTED]> http://russnelson.com
> > Crynwr sells support for free software | PGPok | Government
> > schools are so
> > 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any
> > rank amateur
> > Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them.
> > Homeschool!
> >
--
+ + + + + + + + + + + + + + + + + + + +
Spark Sistemas
- presentado por IWCC Argentina S.A.
Tel: 4702-1958
e-mail: [EMAIL PROTECTED]
+ + + + + + + + + + + + + + + + + + + +
> What do you want animated gifs and sound?
>
> - eric
Apparently, you neglected to read my previous post. Simply having a link to
the list archive is not helpful.
>
> Lyndon Griffin escribió:
> >
> > >From the presentation of information perspective, the site is
> not all that
> > good. Technically speaking, it is very good - fast loading,
> not a lot of BS
> > graphics, accessible with all browsers, including the elite few
> of us who
> > still use Lynx. I am concerned about the quality and quantity of
> > information on the site.
Maybe it's subjective, but I disagree - I don't feel that the site is well
organized. Yes, there are sections of seemingly related material, which I
guess is what you deem to be well organized. I do agree with you that this
may no longer be the forum for this discussion. As you all can probably
gather, I'm anxious to continue this discussion, however.
Lyndon Griffin <[EMAIL PROTECTED]> writes on 10 September 1999 at 13:53:56 -0700
> Maybe it's subjective, but I disagree - I don't feel that the site is well
> organized. Yes, there are sections of seemingly related material, which I
> guess is what you deem to be well organized. I do agree with you that this
> may no longer be the forum for this discussion. As you all can probably
> gather, I'm anxious to continue this discussion, however.
Well, if Russell wants to announce that he doesn't care to hear our
opinions, I could be convinced to cease offering them. I'm hoping,
however, that a polite and detailed discussion of the site design may
help come up with some suggestions that would significantly improve
it, and if we do and since people seem to be willing to help, perhaps
could actually be implemented.
And nearly everything *is* subjective, I'm certainly with you there.
Let me start with a big *thank you* to Russell Nelson for creating the
site, and keeping it pretty current. I've gone there a number of
times looking for specific things like the big dns patch, and I've
always found them.
Point 1: I find the categories things are grouped into somewhat
arbitrary. In particular, I think somebody new to qmail would find
them very confusing.
[addons]
Big -- and yet there are at least two or three others that are just
breakouts from here.
[author's software]
I think I see why these have a separate category -- BUT they're
essentially addons.
[qmail book]
[commercial support]
These two categories are clear and to the point.
[checkpassword]
This is a particular class of addon, which newbies won't understand
the purpose of. It's not even really for qmail as such.
[ezmlm]
I guess it makes sense to break out this author-written addon into its
own section....
[maildir]
This is mostly glue for interfacing other things to maildir; so the
section title is reasonably appropriate.
[tips]
These are pretty useful; but are actually rather different from the
other sections it seems to me.
[user software]
These are essentially addons too.
[user documentation]
[high-volume servers]
Another useful specialized category, I guess.
I wonder if what's really needed is a hierarchy more than 1 level
deep? And maybe with some cross-referencing?
Also, there isn't much editorial content. I can certainly see reasons
why, but what people really need is *advice* about how to proceed with
qmail, rather than a menu of everything that's available.
Point 2: I think it would be nice if the front page had *less*
technical stuff, and in particular if it looked less like a large
collection of enhancements and fixes for things. It presents the
appearance of a product that's in some disarray, which I think is an
unfortunate impression to make on a newcomer.
Point 3: I think I know why qmail.org is avoiding this role (time),
but it would be *really nice* if qmail.org laid out several paths into
qmail, with some discussion as to which path is appropriate for what
situation. I suppose it's also possible that Russell just doesn't
want to take the abuse the putting specific recommended paths on
qmail.org is likely to generate (from a small minority). (I don't
even know who is likely to object; it's just that I'm pretty sure
standing up is likely to get one shot at, as a general rule). I'm
thinking of paths like "personal fully-connected server" and
"intermittently connected personal system" and "high-volume mail
sender" and "large POP user community" and "internal node in big
organization that uses qmail overall". They wouldn't claim to be the
*only* or even *best* way -- but they'd describe a path and some of
the tradeoffs made. This sort of thing would help new users *a lot* I
think. I guess this is back to the "advice" concept I mentioned under
point 1.
--
David Dyer-Bennet ***NOTE ADDRESS CHANGES*** [EMAIL PROTECTED]
http://dd-b.lighthunters.net/ (photos) Minicon: http://www.mnstf.org/minicon
http://www.dd-b.net/dd-b (sf) http://ouroboros.demesne.com/ Ouroboros Bookworms
Join the 20th century before it's too late!
I think that it would be really useful if qmail.org had an "apps" section
similar to freshmeat.net or linuxapps.com. If I could search through names
and decriptions of apps, that would be *very useful*. For instance, if I
hear about this cool program called "vchkpw", that's an addition for qmail,
and I go to www.qmail.org, a simple search is not going to find it, because
the places that vchkpw is mentioned on the qmail page do not lead to the
actual software. vchkpw is listed as the following:
>Christopher Johnson (EI39-1) wrote a virtual domains package with the
>following features. Inter7 is now maintaining the current version.
For someone who searches for "virtual domains", this is fine. However, if
I've used vchkpw before and just can't remember the link, then it's going to
be hard for me to find this on the page. Especially since it's listed under
"Alternative checkpassword implementations." It's obvious to you or me why
your checkpassword program relates to virtual domains, but that is not
obvious at all to a newbie.
Another thing that database searches are good for is that you can have
descriptions with words appearing out of order. For instance, a search for
"virtual domains" will find a document with "virtual mail domains" as well.
Anyway, just my 2 cents. I think the qmail page is definitely a very
valuable resource, but I can see how it would be confusing for newbies.
--Adam
On Fri, Sep 10, 1999 at 12:33:28PM -0700, Lyndon Griffin wrote:
> From the presentation of information perspective, the site is not all that
> good.
> imagine that you and Dan Bernstein and countless others want it to be
> an even more powerful force.
One simple question. Have you *seen*, as in 'with your own eyes', the pages
Dan Bernstein has made?
It all boils down to the question of form versus function. *Anything* about
qmail chooses function. The tiniest detail like your SMTP-greeting has a
well chosen function. (Do NOT tell who you are and what version. It might
give people too much info..)
A fancy box, nice manual and slick webpages will not add *function*, just
form.
--
Ruben
--
Eat more memory!
Chris McCarthy <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>
> I am setting up a webmail system on top of qmail. I thought once I had a
> /etc/passwd and /etc/shadow entry for a user, that would be sufficient
> to receive email. This is not the case, unless the user also has a valid
> home directory owned by that user, qmail says the user does not exist.
>
> delivery 1661: failure: Sorry,_no_mailbox_here_by_that_name._(#5.1.1)/
>
>
> Is there a way around this ? I would like to avoid creating lots of home
> directories that will not be used for anything else. I want all freemail
> users to share the same home directory.
Checkout the vpopmail (vchkpw) package at http://www.inter7.com/vchkpw/
R.
Kevin Waterson writes:
> I am putting together a redhat clone and have omitted sendmail entirely.
> of course exmh nmh fetchmail etc complain, but that can be remedied later.
> I have been looking and reading up on qmail-run and var-qmail packages.
Ask redhat to change the dependency from "sendmail" to "mailtransferagent".
> If I use the
> qmail-run-4-4.i386.rpm
> functions-3-3.i386.rpm
>
> What should I use in the way of var-qmail. My understanding is
> that it needs to be compiled on each machine, but as this is a
> fresh install, but maybe used for upgrades, I am concerned about
> UID's. Should I simply create a .rpm from the source supplied or
> can someone recommend a better method.
If I was making a distribution, *I* would reserve some UIDs <100. The
chances that you'll run into a conflict in an upgrade a very small.
I'd include a program to check for a conflict, and reassign the
existing UID.
--
-russ nelson <[EMAIL PROTECTED]> http://russnelson.com
Crynwr sells support for free software | PGPok | Government schools are so
521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
On Fri, Sep 10, 1999 at 08:42:08AM -0400, Russell Nelson wrote:
> Kevin Waterson writes:
> > I am putting together a redhat clone and have omitted sendmail entirely.
> > of course exmh nmh fetchmail etc complain, but that can be remedied later.
> > I have been looking and reading up on qmail-run and var-qmail packages.
>
> Ask redhat to change the dependency from "sendmail" to "mailtransferagent".
Hello Kevin,
what Distro do you use, at least on my system (RH 6.0):
mirko@picard:[mirko]> rpm -qi --requires nmh
Name : nmh Relocations: (not relocateable)
Version : 0.27 Vendor: Red Hat Software
Release : 8 Build Date: Son 18 Apr 1999
22:10:30 CEST
Install date: Mon 21 Jun 1999 14:56:59 CEST Build Host:
porky.devel.redhat.com
Group : Applications/Internet Source RPM: nmh-0.27-8.src.rpm
Size : 4758227 License: freeware
Packager : Red Hat Software <http://developer.redhat.com/bugzilla>
Summary : A capable mail handling system with a command line interface.
[...]
smtpdaemon
[...]
mutt and fetchmail only require smtpdaemon as well.
smtpdaemon is provided eg. in the RPMs Mate has built?
Regards
Mirko
Russell Nelson <[EMAIL PROTECTED]> writes:
> Kevin Waterson writes:
> > I am putting together a redhat clone and have omitted sendmail entirely.
> > of course exmh nmh fetchmail etc complain, but that can be remedied later.
> > I have been looking and reading up on qmail-run and var-qmail packages.
>
> Ask redhat to change the dependency from "sendmail" to "mailtransferagent".
It looks like they have changed it to smtpdaemon in Redhat 6.0,
although I am not an rpm expert, so maybe I misunderstand.
$ rpm -q --whatrequires sendmail
no package requires sendmail
$ rpm -q --whatrequires smtpdaemon
fetchmail-5.0.0-1
mutt-0.95.4us-4
nmh-0.27-8
--
Frank Cringle, [EMAIL PROTECTED]
voice: (+49 2304) 467101; fax: 943357
Frank D. Cringle writes:
> It looks like they have changed it to smtpdaemon in Redhat 6.0,
> although I am not an rpm expert, so maybe I misunderstand.
>
> $ rpm -q --whatrequires sendmail
> no package requires sendmail
> $ rpm -q --whatrequires smtpdaemon
> fetchmail-5.0.0-1
> mutt-0.95.4us-4
> nmh-0.27-8
That has been the case at least since 4.0. The problem is that Red Hat's
installer forces a sendmail install no matter what, even if another package
provides smtpdaemon.
--
Sam
Sam [mailto:[EMAIL PROTECTED]]
> That has been the case at least since 4.0. The problem is that Red Hat's
> installer forces a sendmail install no matter what, even if another package
> provides smtpdaemon.
If you are going to be installing a bunch of machines, you might invest in
modifying the base package by modifying the installer's package groupings so
that qmail is installed instead of sendmail. You see, sendmail is in the "base"
group which is always installed. If you just modify this group, problem solved.
Modify the groups by editing the RedHat/base/comps file and using the genhdlist
utility to write the RedHat/base/hdlist file. The format is easy enough to
understand.
However, there are some "gotchas" to installing packages in the operating
system install phase. First, you have to be doubly sure that you've setup the
package with the proper "prereq" tags so that anything its installation needs
is installed first. Second, you do not have access to the hostname or any
networking information when the package is installed, so the %post script can't
do your automatic configuration. A way to get around this is have your %post
script setup a dummy script in /etc/rc.d setup that will get run on the first
server-boot, which can then configure qmail with the networking information.
When you get it working it's so sweet just to pop in the RedHat install disk
and choose your own customized package setup off the list of package groups.
- David Harris
Principal Engineer, DRH Internet Services
Sam wrote:
>
>
> That has been the case at least since 4.0. The problem is that Red Hat's
> installer forces a sendmail install no matter what, even if another package
> provides smtpdaemon.
Yes, but in this case I have removed the sendmail rpms from the distro
Kevin
David Harris wrote:
>
>
> If you are going to be installing a bunch of machines, you might invest in
> modifying the base package by modifying the installer's package groupings so
> that qmail is installed instead of sendmail. You see, sendmail is in the "base"
> group which is always installed. If you just modify this group, problem solved.
>
> Modify the groups by editing the RedHat/base/comps file and using the genhdlist
> utility to write the RedHat/base/hdlist file. The format is easy enough to
> understand.
Yes .This is what I have done
Kevin
>What should I use in the way of var-qmail.
>My understanding is that it needs to be compiled on each machine, but
>as this is a fresh install, but maybe used for upgrades, I am concerned
>about
>UID's. Should I simply create a .rpm from the source supplied or can
>someone
>recommend a better method.
Since this will be your distribution, you can just reserve the qmail
uids. In this case, you can get away with a very simple spec file to
build qmail (I can tell you if you need it).
But you might be concerned about people who would like to upgrade
their RH system to yours (probably bad idea though).
Then you could test and remove their qmail users if they are not with
the specified uids. Or use the var-qmail package as it is now. It
does not have to be compiled on the install system at all. As the
README explains:
1) take qmail-1.03-*.src.rpm (this does not contain the qmail sources,
but the qmail binaries), do
rpm --rebuild qmail-1.03-*.src.rpm
This adds the qmail users if they do not yet exist, edits the
binaries for the qmail uids/gids, and builds
qmail-1.03-*.i386.rpm
2) which then can be installed in the usual way.
Since you install qmail with the base system, and compilation does not
happen, users will not notice at all that you are doing a bit
nonstandard rpm install.
Mate
Hi,
I recently had a scan of my DSL-connected Linux box done by
http://www.dslreports.com. I was rather surprised to see that this service
reported my system was set up as an open e-mail relay. I quickly discovered
that it's not, really; the system just didn't know that qmail was checking local
recipients AFTER accepting the mail. I do still have a couple of concerns.
First, here's the relevant portion of the output of the test:
Test mail relay
To:<[EMAIL PROTECTED]> .. 553 sorry, that domain isn't in
my list of allowed rcpthosts (#5.7.1)
To:<[EMAIL PROTECTED]> .. 553 sorry, that domain isn't in my list of allowed
rcpthosts (#5.7.1)
To:<[EMAIL PROTECTED]@[151.203.46.57]> ..250 ok
To <root%XX.XX.com@[151.203.46.57]> ..250 ok
To <XX.XX.com!root@[151.203.46.57]> ..250 ok
I gather that the last three are notations allowed by some SMTP daemons for
relay, but that qmail doesn't recognize them as such, and so tries to interpret
them as usernames, which of course fails and causes a bounce message to go out,
but only AFTER accepting the message for attempted delivery. I have three
concerns about this behavior:
1) If the "from" address is also bogus, the bounce will bounce, and so I'll
get a notification of the bounce. This is fine if it's just an isolated
incident, but I'm concerned that if some spammer tried to do a mass
mailing through my system, I might be inundated with these messages. I
tried a test, and I see that I do at least get but a single message for
multiple recipients, but what if a spammer tries sending messages
individually, or a dozen or more messages, each to different groups?
2) If one open relay test misidentifies my system as having an open relay,
others might. I'd hate to get stuck on an anti-spam e-mail blacklist
because of a misidentification like this. (For a while, a former ISP
of mine used an over-eager anti-spam list that blocked mail from a
mailing list that was misidentified in a way similar to this.) Most
of my incoming mail should be coming through my ISP (grabbed via
fetchmail), so this shouldn't be a big problem even if it happens,
but some people do still seem to grab and use my "direct" address.
3) If the spammer places the recipient in the "from" field rather than
the "to" field, the system WOULD serve as an open relay of sorts,
albeit a very strange and undesirable one, since to the recipient,
the e-mail would seem to be a bounce from his/her own account. If
nothing else, a feature like this could make the target think that
his/her security had been compromised, and I'd rather not be a
party to such a prank. (Granted, such a message would be easily
forged via more direct means, but still....)
Anyhow, I realize that giving information "up front" on working usernames on the
system is probably at least a small security risk, so I'd rather not do that,
but is there some way to refuse deliveries to usernames that match some pattern
(like anything containing an "@", "%", or "!", to kill the specific examples
used in this particular test)?
--
Rod Smith
[EMAIL PROTECTED]
http://members.bellatlantic.net/~smithrod
Author of _Special Edition Using Corel WordPerfect 8 for Linux_, from Que
[EMAIL PROTECTED] writes:
> Anyhow, I realize that giving information "up front" on working usernames on the
> system is probably at least a small security risk, so I'd rather not do that,
I've yet to see anyone make a cogent argument for this, instead of
accepting it as a given.
The flip side of this coin is that you force yourself to accept mail to bad
recipients, with a forged return address, and thus you can now be used as a
middleman to mailbombing by proxy. If THAT's not a security risk, I don't
know what is. What do you think is a greater security risk: having the
ability to confirm local addresses, or have someone send you a couple of
thousand RCPT TOs to non-existent addresses, and a return address of
[EMAIL PROTECTED]? Keep in mind that Qmail will happily explode that into
several thousand happy little messages that it will promptly bounce back to
the sender.
--
Sam
Sam <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] writes:
>
>> Anyhow, I realize that giving information "up front" on working
>> usernames on the system is probably at least a small security risk,
>> so I'd rather not do that,
>
>I've yet to see anyone make a cogent argument for this, instead of
>accepting it as a given.
It's pretty obvious. Given two systems, one that advertises users and
one that doesn't, and an infinite supply of kiddie krackers doing
brute-force searches for accounts with easy-to-guess passwords, the
system that advertises usernames will be broken into first, on
average, because the crackers will waste less time trying to break
into nonexistent accounts.
-Dave
Or given a list of valid usernames on one system, forge
email to that user's associates elsewhere. Or spam in
his name, etc...
On Fri, Sep 10, 1999 at 02:24:29PM -0400, Dave Sill wrote:
> Sam <[EMAIL PROTECTED]> wrote:
>
> >[EMAIL PROTECTED] writes:
> >
> >> Anyhow, I realize that giving information "up front" on working
> >> usernames on the system is probably at least a small security risk,
> >> so I'd rather not do that,
> >
> >I've yet to see anyone make a cogent argument for this, instead of
> >accepting it as a given.
>
> It's pretty obvious. Given two systems, one that advertises users and
> one that doesn't, and an infinite supply of kiddie krackers doing
> brute-force searches for accounts with easy-to-guess passwords, the
> system that advertises usernames will be broken into first, on
> average, because the crackers will waste less time trying to break
> into nonexistent accounts.
>
> -Dave
--
Christopher F. Miller, Publisher [EMAIL PROTECTED]
MaineStreet Communications, Inc 208 Portland Road, Gray, ME 04039
1.207.657.5078 http://www.maine.com/
Database publishing, e-commerce, office/internet integration, Debian linux.
Mr. Christopher F. Miller <[EMAIL PROTECTED]> writes on 10 September 1999 at 13:45:29 -0500
>
> Or given a list of valid usernames on one system, forge
> email to that user's associates elsewhere. Or spam in
> his name, etc...
All of which can be done to anybody who posts in public (like, say,
here) anyway. And it's much easier to harvest email addresses from
deja and web pages and list archives than it is to play VRFY games on
systems.
--
David Dyer-Bennet ***NOTE ADDRESS CHANGES*** [EMAIL PROTECTED]
http://dd-b.lighthunters.net/ (photos) Minicon: http://www.mnstf.org/minicon
http://www.dd-b.net/dd-b (sf) http://ouroboros.demesne.com/ Ouroboros Bookworms
Join the 20th century before it's too late!
On Fri, 10 Sep 1999, Dave Sill wrote:
> Sam <[EMAIL PROTECTED]> wrote:
>
> >[EMAIL PROTECTED] writes:
> >
> >> Anyhow, I realize that giving information "up front" on working
> >> usernames on the system is probably at least a small security risk,
> >> so I'd rather not do that,
> >
> >I've yet to see anyone make a cogent argument for this, instead of
> >accepting it as a given.
>
> It's pretty obvious. Given two systems, one that advertises users and
> one that doesn't, and an infinite supply of kiddie krackers doing
> brute-force searches for accounts with easy-to-guess passwords, the
It's much easier to scrape the same accounts from the web or Usenet.
Furthermore, you ignored the rest of my post, which compared whatever
miniscule benefit you get from practicing security through obscurity
weighed against your server now being a willing accomplice in a
denial-of-service attack. The same script kiddies are far less likely to
select a nailed down service in order to mailbomb someone by proxy,
instead it's much easier to shove a few thousand messages with a few
thousand bad recipients into Qmail's queue, then sit back and watch Qmail
unload a few million messages into the target's mailbox.
> system that advertises usernames will be broken into first, on
> average, because the crackers will waste less time trying to break
> into nonexistent accounts.
I've yet to hear of a single documented case of someone using sendmail in
this fashion in order to crack into accounts. If a cracker wants to
collect valid addresses to try to crack into, they're far less likely to
start banging on port 25 which is usually logged on sendmail boxes, and be
notices, instead of simply harvest the addresses off the search engines or
Dejanews, which is virtually undetectable.
I agree with Sam on this one. My experience supports his view. I've
never seen any systematic attempts to grab usernames via SMTP. I've seen
quite a few mailbombs with bounces, though.
Jim Lippard [EMAIL PROTECTED] http://www.discord.org/
Unsolicited bulk email charge: $500/message. Don't send me any.
PGP Fingerprint: 0C1F FE18 D311 1792 5EA8 43C8 7AD2 B485 DE75 841C
On Fri, 10 Sep 1999, Sam wrote:
> On Fri, 10 Sep 1999, Dave Sill wrote:
>
> > Sam <[EMAIL PROTECTED]> wrote:
> >
> > >[EMAIL PROTECTED] writes:
> > >
> > >> Anyhow, I realize that giving information "up front" on working
> > >> usernames on the system is probably at least a small security risk,
> > >> so I'd rather not do that,
> > >
> > >I've yet to see anyone make a cogent argument for this, instead of
> > >accepting it as a given.
> >
> > It's pretty obvious. Given two systems, one that advertises users and
> > one that doesn't, and an infinite supply of kiddie krackers doing
> > brute-force searches for accounts with easy-to-guess passwords, the
>
> It's much easier to scrape the same accounts from the web or Usenet.
>
> Furthermore, you ignored the rest of my post, which compared whatever
> miniscule benefit you get from practicing security through obscurity
> weighed against your server now being a willing accomplice in a
> denial-of-service attack. The same script kiddies are far less likely to
> select a nailed down service in order to mailbomb someone by proxy,
> instead it's much easier to shove a few thousand messages with a few
> thousand bad recipients into Qmail's queue, then sit back and watch Qmail
> unload a few million messages into the target's mailbox.
>
> > system that advertises usernames will be broken into first, on
> > average, because the crackers will waste less time trying to break
> > into nonexistent accounts.
>
> I've yet to hear of a single documented case of someone using sendmail in
> this fashion in order to crack into accounts. If a cracker wants to
> collect valid addresses to try to crack into, they're far less likely to
> start banging on port 25 which is usually logged on sendmail boxes, and be
> notices, instead of simply harvest the addresses off the search engines or
> Dejanews, which is virtually undetectable.
>
>
>
On Fri, Sep 10, 1999 at 07:55:52PM -0400, Sam wrote:
>
> Furthermore, you ignored the rest of my post, which compared whatever
> miniscule benefit you get from practicing security through obscurity
> weighed against your server now being a willing accomplice in a
> denial-of-service attack. The same script kiddies are far less likely to
> select a nailed down service in order to mailbomb someone by proxy,
> instead it's much easier to shove a few thousand messages with a few
> thousand bad recipients into Qmail's queue, then sit back and watch Qmail
> unload a few million messages into the target's mailbox.
So aside from debating the value of doing it, can somebody address the
main point of my initial post: How do you configure qmail to PREVENT such
a thing from happening? I'm a qmail newbie, and haven't seen anything in
the documentation that says how to get qmail to reject messages with bogus
"to" fields up front, rather than delaying and then bouncing the message.
--
Rod Smith
[EMAIL PROTECTED]
http://members.bellatlantic.net/~smithrod
Author of _Special Edition Using Corel WordPerfect 8 for Linux_, from Que
On Fri, 10 Sep 1999 [EMAIL PROTECTED] wrote:
> On Fri, Sep 10, 1999 at 07:55:52PM -0400, Sam wrote:
> >
> > Furthermore, you ignored the rest of my post, which compared whatever
> > miniscule benefit you get from practicing security through obscurity
> > weighed against your server now being a willing accomplice in a
> > denial-of-service attack. The same script kiddies are far less likely to
> > select a nailed down service in order to mailbomb someone by proxy,
> > instead it's much easier to shove a few thousand messages with a few
> > thousand bad recipients into Qmail's queue, then sit back and watch Qmail
> > unload a few million messages into the target's mailbox.
>
> So aside from debating the value of doing it, can somebody address the
> main point of my initial post: How do you configure qmail to PREVENT such
> a thing from happening?
You don't. Qmail simply can't do it.
> I'm a qmail newbie, and haven't seen anything in
> the documentation that says how to get qmail to reject messages with bogus
> "to" fields up front, rather than delaying and then bouncing the message.
That's because such a thing does not exist. Qmail is not designed to do
that. Now, I do happen have a patch for Qmail that adds this capability,
since I've had a problem with this issue myself since 1997, but it is not
for the faint of heart. In addition to adding RCPT TO: checking, it also
includes several other drastic changes as well. This is not an
understatement. Qmail was simply not designed for some of these things,
so it's not just a one or two line change to the code. Even experienced
administrators do not always have an easy time integrating my patches, in
fact that happened just the other day. So, forget about it for the
moment, and become familiar an comfortable with Qmail as a starting point.
Afterwards, perhaps you might want to look into tweaking it by adding
other people's code.
Sam writes:
> it's much easier to shove a few thousand messages with a few
> thousand bad recipients into Qmail's queue, then sit back and watch Qmail
> unload a few million messages into the target's mailbox.
Please stop spreading misinformation.
Each queued message is bounced at most once. Your message to 1000 bad
local recipients will produce exactly one bounce showing the addresses
that failed. You might as well have sent the same data directly.
Messages split when they are _successfully_ relayed or forwarded. SMTP
clients are not permitted to relay without your explicit authorization.
Forwarding targets are normally valid addresses. The exceptions, such as
multidrop POP mailboxes, allow multiple bounces no matter what MTA
you're running; in the same situations, RCPT verification is impossible.
I'm not saying I like server-side bounces. They reflect a fundamental
misallocation of responsibilities in the Internet mail infrastructure.
Internet mail would have been much simpler, much faster, and much more
reliable if it had been designed without bounce messages; the sender's
ISP would have been responsible for retransmitting new-mail notices
until the recipient downloaded and acknowledged the message.
---Dan
Hi qmailers
I neet to make a Webpage that can be sent
by clicking a "Send" buttom.
just like you find in Hotmail.com
and so many other places.
Which program do I call in qmail for this to be done.
Does any of you have a sample page
that you would like to help me with.
Thanks in advance
Jacob
On Fri, 10 Sep 1999 [EMAIL PROTECTED] wrote:
> Hi qmailers
>
> I neet to make a Webpage that can be sent
> by clicking a "Send" buttom.
> just like you find in Hotmail.com
> and so many other places.
>
> Which program do I call in qmail for this to be done.
the sendmail wrapper. If you installed qmail correctly per the
instructions, it should already have the appropriate symlink in place.
> Does any of you have a sample page
> that you would like to help me with.
>
>
> Thanks in advance
> Jacob
>
>
Does anyone use their .qmail files to selectively forward messages to
different addresses? Say "if from=??? or subj=???"
How about passing the messages to a script for processing?
Damon Parker
[EMAIL PROTECTED]
www.siliconsys.com
voice 512.478.1669
data/fax 512.478.1627
mobile 512.750.9793
Damon Parker <[EMAIL PROTECTED]> wrote:
>Does anyone use their .qmail files to selectively forward messages to
>different addresses? Say "if from=??? or subj=???"
>
>How about passing the messages to a script for processing?
Sure. These are very common. Tools like maildrop and procmail make it
very easy, but it can be done directly from .qmail files.
-Dave
At 3:01 pm -0400 10/9/99,the wonderful Dave Sill wrote:
>Damon Parker <[EMAIL PROTECTED]> wrote:
>
> >Does anyone use their .qmail files to selectively forward messages to
> >different addresses? Say "if from=??? or subj=???"
> >
> >How about passing the messages to a script for processing?
>
>Sure. These are very common. Tools like maildrop and procmail make it
>very easy, but it can be done directly from .qmail files.
how can you do it just in the .qmail file?
I'd like to have a list of 'important' from addresses (in a line
delimited text file) that I forward mail to an 'important'pop3
account, with the rest being junked.
- kinda opposite to procmail, which appears to prefer forwarding mail
if it matches. But creating a 3 line entry for each matching person
might take some time...
peter
--
peter at gradwell dot com; http://www.gradwell.com/
gradwell dot com Ltd. Enabling the internet you don't see.
** Cheap and easy ecommerce: http://www.gradwell.net/ **
Okay,
I have our smtp running under tcpserver and only machine in the office
can send mail through it. But now, we have people dialing in from
home and wanting to use our smtp server. They can't use the ISPs smtp
server because they want to send mail as
[EMAIL PROTECTED] and most people don't like you doing
that...
Unfortunately people are also dialing into MSN and want to use the
mailserver. I don't want to allow the IP range for all of MSN...
Any suggestions?
Pat
--
Patrick Berry --- Code Creation --- Freestyle Interactive --- 415.778.0610
http://www.freestyleinteractive.com
You make your users use the MSN smtp server, I have several users using our
office mailserver remotely with MSN and no reported problems sending mail
as [EMAIL PROTECTED] through MSN's smtp servers. I *assume* that MSN lets
any of its IP addresses send mail regardless of hostname.
Tim
At 12:02 PM 9/10/99 -0700, you wrote:
>Okay,
>
>I have our smtp running under tcpserver and only machine in the office
>can send mail through it. But now, we have people dialing in from
>home and wanting to use our smtp server. They can't use the ISPs smtp
>server because they want to send mail as
>[EMAIL PROTECTED] and most people don't like you doing
>that...
>
>Unfortunately people are also dialing into MSN and want to use the
>mailserver. I don't want to allow the IP range for all of MSN...
>
>Any suggestions?
>
>Pat
>--
>Patrick Berry --- Code Creation --- Freestyle
>Interactive --- 415.778.0610
>
>http://www.freestyleinteractive.com
Hello everybody,
I have already installed qmail on SuSE Linux 6.2 with Windows clients and it
works really fine.
We have almost 15 clients running Outlook 97/98/2000. Now my question is, if
it is possible to use the groupware function of that MUA with qmail, or are
there any questions to do so ?
I really don't want to use M$ Exchange to use the wanted features of
Outlook.
Thank you for your answers
best regards
Stephan
Hi folks, my freebsd box (3.2-Stable) running qmail dies over and over,
several about 1/2 times a week. Here is what i get at log:
937023957.591990 alert: oh no! lost spawn connection! dying...
937023957.617105 status: exiting
I decide to trace qmail syscalls, using the utility truss, i got that:
returns 0 (0x0)
syscall stat("bounce/275998",0xbfbfd454)
errno 2 'No such file or directory'
syscall write(0,0x804eba1,8)
returns 8 (0x8)
syscall write(0,0x8055500,6)
returns 6 (0x6)
syscall write(0,0x804e6c9,1)
returns 1 (0x1)
syscall unlink(0x8051270)
returns 0 (0x0)
syscall write(5,0x8051270,12)
returns 12 (0xc)
syscall read(0x6,0x80550d0,0x400)
returns 1 (0x1)
syscall gettimeofday(0xbfbfd970,0x0)
returns 0 (0x0)
SIGNAL 20
syscall select(0x9,0xbfbfda30,0xbfbfd9b0,0x0,0xbfbfd99c)
returns 1 (0x1)
syscall gettimeofday(0xbfbfd970,0x0)
returns 0 (0x0)
syscall read(0x2,0x8054090,0x800)
returns 0 (0x0)
syscall write(0,0x804e667,46)
returns 46 (0x2e)
syscall utimes(0x8051270,0xbfbfd940)
returns 0 (0x0)
syscall utimes(0x8051270,0xbfbfd940)
returns 0 (0x0)
syscall utimes(0x8051270,0xbfbfd940)
returns 0 (0x0)
syscall utimes(0x8051270,0xbfbfd940)
returns 0 (0x0)
syscall utimes(0x8051270,0xbfbfd940)
returns 0 (0x0)
syscall write(0,0x804efc6,16)
returns 16 (0x10)
syscall exit(0x0)
process exit, rval = 0
please, can anyone help me?
How to avoid these error? Before, what is happenning ?
Is this serious, or can be solved ?
Thanks a lot for your time and cooperation.
On Sat, Sep 11, 1999 at 02:36:15AM -0300, Gustavo V G C Rios wrote:
> Hi folks, my freebsd box (3.2-Stable) running qmail dies over and over,
> several about 1/2 times a week. Here is what i get at log:
>
> 937023957.591990 alert: oh no! lost spawn connection! dying...
> 937023957.617105 status: exiting
This means that either qmail-lspawn or qmail-rspawn died for some reason (grep
qmail-send.c). I am presuming the SIGNAL 20 points to the child death in
question (20 is SIGCHLD). This _bad_. Do you see any core files hanging
around?
Also, try cd'ing into a dir with plenty of room and then do
# ktrace -di -p <pid-of-qmail-send>
after restarting qmail. This will trace qmail-send's children too, and may
point you to what's going on. You can view the ktrace.out file using kdump. Be
sure to watch the size that file though. Use ``ktrace -C'' to turn the trace
off. See ktrace(1)/kdump(1) for details.
Another thing to try is do a cvsup, a make world, a kernel
config/rebuild/install, and reinstall the qmail binaries (using ``make setup
check'' in the qmail source dir).
--
Jos Backus _/ _/_/_/ "Reliability means never
_/ _/ _/ having to say you're sorry."
_/ _/_/_/ -- D. J. Bernstein
_/ _/ _/ _/
[EMAIL PROTECTED] _/_/ _/_/_/ use Std::Disclaimer;
I'm currently trying to install phpop (pop-based webmail interface),
and it seems it doesn't like qpop3d : it return the error which
I use as subject for this post. Is qpop3d really "NOT an RFC 1939
Compliant server", or is the php program buggy ? Strange...
(source: http://renaghan.com/phpop/download.php3 )
Olvier
