qmail Digest 29 Jan 2000 11:00:01 -0000 Issue 895
Topics (messages 36290 through 36332):
GFS and Qmail and BIG mail servers
36290 by: Tracy R Reed
36297 by: Adam McKenna
36322 by: Tracy R Reed
Re: subdomain qmail locals
36291 by: Robert Sander
36303 by: Peter C. Norton
I'm implementing SMTP-AUTH testers needed
36292 by: listy-dyskusyjne Krzysztof Dabrowski
Re: Qmail crashing TCP/IP-stack
36293 by: Uwe Ohse
36298 by: Steve Wolfe
36299 by: Steve Wolfe
36301 by: Jonathan Herbert
36302 by: Mark Delany
36304 by: Jonathan Herbert
36305 by: Mark Delany
36307 by: Jonathan Herbert
36308 by: Kai MacTane
36310 by: Brad Shelton
36312 by: Matthew Brown
36313 by: Jonathan Herbert
36314 by: Mark Delany
36315 by: Mikko Hänninen
36316 by: craig.jcb-sc.com
36317 by: Timothy L. Mayo
36318 by: Jonathan Herbert
36319 by: Jason Haar
36320 by: Dennis Duval
Re: big fat qmail-command hole
36294 by: Russ Allbery
36295 by: Russ Allbery
Mail accept without existing homedir
36296 by: Arne Hinrichsen
logging problem on Solaris 7
36300 by: James P Kannengieser
Re: Sleeping qmail
36306 by: Faried Nawaz
Open Relay
36309 by: Juan E Suris
36311 by: Charles Cazabon
single-user-virtual-domain, rcpthosts, relayclients/domains -> no relaychecking vs.
virtual domain only
36321 by: Martin Büchler
spammer lurking
36323 by: Jim Breton
36324 by: Martin Randall
Aliases
36325 by: Tom Reinertson
36327 by: Mikael Schmidt
36330 by: Mikko Hänninen
Logfile
36326 by: Jacob Joseph
Qmail taking too long??
36328 by: TAG
36329 by: richard.illuin.org
36332 by: Giles Lean
Re: Daemontools.61 initscripts?
36331 by: Vincent Schonau
Administrivia:
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To bug my human owner, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
I have just become aware of the GFS project and I am BLOWN AWAY.
I don't know how this project reached production quality status and escaped my
radar until now. I got an email from my VAR for StorageTek disk arrays today
pitching it as a solution. This appears at first glance to be the answer to a
lot of our mail server scalability problems. You can now put a bunch of SMTP
and POP servers (DNS round robin or serveriron/bigip them) clustered on a
fibrechannel network talking to shared disk arrays. No NFS, no TCP, just SCSI
over fibrechannel with every host in the cluster talking to every disk. I just
finished reading their latest IEEE paper and the locking mechanism makes sense
and seems quite sane and suitable to handling just this sort of situation.
It's a journalled and fault tolerant filesystem. If a machine in the cluster
goes down, no problem. With well supported and relatively inexpensive Qlogic
fibrechannel cards and fibrechannel disks costing only slightly more than SCSI
disks (I think, I've never really priced them individually) this seems quite
viable. I encourage all of you to check out:
http://www.globalfilesystem.org
and tell me what you think. Does this sound like a good way to cluster mail
servers to you too?
--
Tracy Reed http://www.ultraviolet.org
Every one we don't catch would be a "yet another major ms security hole",
and the theory tells us we can't catch all of them. So, we're just not
going to start down that path.
[EMAIL PROTECTED] 08/06/98 Bugtraq
On Fri, Jan 28, 2000 at 12:41:10AM -0800, Tracy R Reed wrote:
> It's a journalled and fault tolerant filesystem. If a machine in the cluster
> goes down, no problem. With well supported and relatively inexpensive Qlogic
> fibrechannel cards and fibrechannel disks costing only slightly more than SCSI
> disks (I think, I've never really priced them individually) this seems quite
> viable. I encourage all of you to check out:
The big expense when running fibre channel is not the HBA's or the disks.
It's the fibre channel switches. We priced out a four port fibrechannel
switch at $15,000 a few months ago.
--Adam
On Fri, Jan 28, 2000 at 10:27:23AM -0500, Adam McKenna wrote:
> The big expense when running fibre channel is not the HBA's or the disks.
> It's the fibre channel switches. We priced out a four port fibrechannel
> switch at $15,000 a few months ago.
We have 50 36G disks per loop and still see excellent performance. Since most
disks are dual ported you can run two loops and get 100 disks (this is what we
are doing, although not with GFS yet). That's a lot of storage, probably more
than people have been talking about NFS mounting.
--
Tracy Reed http://www.ultraviolet.org
Every one we don't catch would be a "yet another major ms security hole",
and the theory tells us we can't catch all of them. So, we're just not
going to start down that path.
[EMAIL PROTECTED] 08/06/98 Bugtraq
On Fri, Jan 28, 2000 at 12:27:52AM -0600, Scott Beck wrote:
> I just downloaded that patch. You said you do not have any benchmark
> results from it but do you think is will be faster to do
> ^([^\.]+\.)?domain$ or list 3000 sub.domain. Both at this point are
> an option.
Look at the implementation. I am using the regex functions from libc,
compiling the patterns when starting qmail-send and then only matching aginst
them. It should be reasonably fast, but as stated I have no numbers because I
have not a big mailserver.
Greetings
--
Robert Sander www.gurubert.de
Your admin isn't completely correct. You can also add the domains to
virtualdomains, which can let you aggregate subdomains and do delivery in
your program. Giving your admin the benefit of the doubt, that you don't
have any possibility of aggregation, then yes, you have to put 3000 names in
the locals file.
Anyway, it sounds to me like you're trying to re-invent the wheel. Have you
looked at the qmailadmin suite from inter7.com?
On Fri, Jan 28, 2000 at 12:08:23AM -0600, Scott Beck wrote:
>
> On 27-Jan-00 Scott Schappell wrote:
> <SNIP>
> > That also has to assume the MX entry is correct
> > for his domain, that all mail goes to that machine.
> > In my example: silvertree.org IN MX 10 arthur.silvertree.org.
> >
> > The FAQ I am referencing is:
> > http://cr.yp.to/qmail/faq/incominghost.html#local
> >
> <SNIP>
>
> I have read this FAQ but failed to understand it because I did
> not know what they meant by DNS entry. Maybe I should explain
> the situation a little better.
>
> I am not the server administrator. I am just a Perl programmer
> trying to make things work correctly for a program I wrote. The
> server administrator told me the only way to get mail from
> <anyone>@<sub>.domain was to add an entry in /var/qmail/control/locals
> for each <sub>.domain. I did not believe him because the amount
> of entries in that file could be over 3000 (eek) so I tested it
> and my test email was bounced.
>
> I sent an email to [EMAIL PROTECTED] domain was entered in
> /var/qmail/control/locals but sub.domain was not. There was a line in
> /etc/aliases.cdb for [EMAIL PROTECTED] to be delivered to me@domain
> and the email bounced. The log said that qmail was not trying to
> deliver it locally.
>
> The program I am writting will just need to set up forwards for
> people that do not have an actual local email account just a
> subdomain account.
>
> I guess what my question should have been was where do I need to make
> entries when someone signs up for an email forward account?
> The forwards will be done with fastforward and I have already made the
> script that writes them to /etc/aliases.cdb.
>
> Sorry for the confusion
> Scott
>
> -----------------------------------------------------------------
> E-Mail: Scott Beck <[EMAIL PROTECTED]>
> Address: 3542 Pine Bettle Ln. Sulphur La. 70663
> Phone: (318) 527-9518
> Date: 27-Jan-00
> Time: 23:40:16
> -----------------------------------------------------------------
--
The 5 year plan:
In five years we'll make up another plan.
Or just re-use this one.
Hello..
I've took mr. Brisby's patch and i'm enhancing it now.
At the moment i have implemented the PLAIN AUTH type and i'm in the middle
of CRAM-MD5.
When we'll have these 3, i can assume that most client will be able to use
this feature.
I need some beta testers so if you are interested then let me know, ok?
I'll try to publish the patch tonight or atleast this monday. It depends on
how fast i'm with coding.
That's it.
Kris
On Fri, Jan 28, 2000 at 11:29:01AM +0100, Henrik Öhman wrote:
> 3Com 3c905B (Running in 100Mbit to the router)
debug the driver for that one, or try another type of ethernet card.
Regards, Uwe
> So, naturally, I'll get a few defferals due to dead connections, but
> eventually all the mail should get sent, so I don't worry about that.
What I
> do worry about is that I can't login because bash can't fork (due to lack
of
> memory,) that the load peaks around 2.40 and averages at 1.20 and that
the
> TCP/IP stack is dead. (I can't get a ping reply from our local network
and all
> connections seem dead.)
>
> 3Com 3c905B (Running in 100Mbit to the router)
Ah, there is a problem in some versions of the 3Com card that only rises
up on a 100Mbit connection, a 10 Mbit can't supply data fast enough. If
you look in the logs, you'll probably notice an error about concurrency,
but I don't know more than that. Check the archives of BugTraq, I think it
was discussed there for a week or so, with a couple of workarounds. One is
to get a different version of the driver, and the other is re-compiling the
existing driver with a higher concurrency. Sorry I don't have more
details.: )
steve
> Ah, there is a problem in some versions of the 3Com card
I apologize, to be fair, I should have said:
There is a problem in some versions of the #Com 3c9x *DRIVER*, not the
card. It's early.
steve
On Fri, Jan 28, 2000 at 11:53:48AM +0100, Henrik Öhman wrote:
>
>
> Petr Novotny wrote:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 28 Jan 00, at 11:29, Henrik Öhman wrote:
> > > A user just sent 2 subsequent mails to a mailing list, both including quite
> > > large attachments (looking in ~user/list/archive, the files are 1,2Mb and
> > > 730kb respectively) to 21 users. This is quite heavy on a 128kbit line, esp.
> > > since concurrencyremote is 20, so I expect that each qmail-remote takes its
> > > share of the bandwidth, leaving 128/20 kbit per delivery.
I've implemented qmail in a number of environments, including small to
medium sized ISPs, research groups, and private companies as well. One of
the main complaints has always been the amorphous "problem with large
attachments".
I can't imagine that this could be entirely the OS's fault, considering this
tends to be a consistent problem regardless of architecture or OS.
There was some discussion a while back regarding where qmail was in all of
this, and what was planned for the future, but i can't seem to find it now.
Has this been written off as "not a qmail problem", or is there current work
to explore this.
(I'm not bashing qmail, i think qmail's great. Just wondering where this was
headed.)
:)
Jonathan
On Fri, Jan 28, 2000 at 11:25:51AM -0500, Jonathan Herbert wrote:
> > > On 28 Jan 00, at 11:29, Henrik Öhman wrote:
> > > > A user just sent 2 subsequent mails to a mailing list, both including quite
> > > > large attachments (looking in ~user/list/archive, the files are 1,2Mb and
> > > > 730kb respectively) to 21 users. This is quite heavy on a 128kbit line, esp.
> > > > since concurrencyremote is 20, so I expect that each qmail-remote takes its
> > > > share of the bandwidth, leaving 128/20 kbit per delivery.
>
> I've implemented qmail in a number of environments, including small to
> medium sized ISPs, research groups, and private companies as well. One of
> the main complaints has always been the amorphous "problem with large
> attachments".
>
> I can't imagine that this could be entirely the OS's fault, considering this
> tends to be a consistent problem regardless of architecture or OS.
Which problem in particular? qmail has no clue as to whether it is really
running on a 486 with 8MB or memory and a 2400bps link or a 64x CPU E10000
with a couple gig of memory and an OC48 connection to the Internet.
The only person with the possibility of having such a clue is the person who
admins the system.
Based on this, my suggestion is that resource consumption by anything that runs
on a system is something that should be controlled by the admin. That qmail lets
you utilize the system resource controls to *gracefully* control just about every
resource type on a system means that you can tune it fairly precisely to your needs.
In additional qmail has numerous concurrency and resource control mechanisms above
and beyond that offered by a typical Unix.
That a default qmail install might consume too many resources in some situations
is entirely to be expected. That a default qmail install doesn't consume enough
resources in other situations is just as expected.
Regards.
On Fri, Jan 28, 2000 at 08:50:58AM -0800, Mark Delany wrote:
> On Fri, Jan 28, 2000 at 11:25:51AM -0500, Jonathan Herbert wrote:
>
> > > > On 28 Jan 00, at 11:29, Henrik Öhman wrote:
> > > > > A user just sent 2 subsequent mails to a mailing list, both including quite
> > > > > large attachments (looking in ~user/list/archive, the files are 1,2Mb and
> > > > > 730kb respectively) to 21 users. This is quite heavy on a 128kbit line, esp.
> > > > > since concurrencyremote is 20, so I expect that each qmail-remote takes its
> > > > > share of the bandwidth, leaving 128/20 kbit per delivery.
> >
> > I've implemented qmail in a number of environments, including small to
> > medium sized ISPs, research groups, and private companies as well. One of
> > the main complaints has always been the amorphous "problem with large
> > attachments".
> >
> > I can't imagine that this could be entirely the OS's fault, considering this
> > tends to be a consistent problem regardless of architecture or OS.
>
> Which problem in particular? qmail has no clue as to whether it is really
> running on a 486 with 8MB or memory and a 2400bps link or a 64x CPU E10000
> with a couple gig of memory and an OC48 connection to the Internet.
Err, the "large attachment" problem. I don't consider this a resource issue
per se; the problem i've experienced more so is the poor handling of
extremely large messages.
To elaborate, users who retrieve large messages via pop3, or transmit large
messages via smtp often complain about being disconnected, timing out, or a
myriad of other equally vague problems.
> The only person with the possibility of having such a clue is the person who
> admins the system.
Thanks for that outstanding vote of confidence :-)
> Based on this, my suggestion is that resource consumption by anything that runs
> on a system is something that should be controlled by the admin. That qmail lets
> you utilize the system resource controls to *gracefully* control just about every
> resource type on a system means that you can tune it fairly precisely to your needs.
[...]
Well, obviously there are too many factors involved to pinpoint the problem
specifically, but that in itself tends to problematic.
Even ruling out user error, configuration mishaps, wind sheer, and solar
radiation, users still tend to complain about the mailserver [qmail] not
handling large messages well.
Similarly, i've never encountered it in any capacity which could be viewed
as debilitating.
I'm simply wondering if this is a known issue- it seems that i'm not the
only one whos run into this in some way shape or form. And it's that which
makes me think there is more substantiality to this claim than is openly
realized.
Jonathan
[PS, i'm not trolling. please dont think i'm trolling, I know how
defensive this list can get on occasion. :)]
> > > I can't imagine that this could be entirely the OS's fault, considering this
> > > tends to be a consistent problem regardless of architecture or OS.
> >
> > Which problem in particular? qmail has no clue as to whether it is really
> Err, the "large attachment" problem. I don't consider this a resource issue
> per se; the problem i've experienced more so is the poor handling of
> extremely large messages.
> To elaborate, users who retrieve large messages via pop3, or transmit large
> messages via smtp often complain about being disconnected, timing out, or a
> myriad of other equally vague problems.
Having worked in an ISP environment for many years I can only say that this
problem is rampant in the industry. I've seen it with qmail, I've seen it with
qpopper, I've seen it with sendmail, I've seen it with large http documents,
I've seen it with large ftps...
Note that the code in qmail is typically *much* simpler than most of the code
that handles socket traffic (has anyone looked at qpopper 3?) which literally
boils down to nothing much more than:
while (data = read_from_mail_file()) {
write_data_to_socket();
}
I've spent a lot of time looking at these problems and this code and I
find it very hard to understand what the code could do that would alleviate
the problem. It totally relies on the OS to manage the TCP/IP session,
as it should.
> > The only person with the possibility of having such a clue is the person who
> > admins the system.
>
> Thanks for that outstanding vote of confidence :-)
Well, I had to assign intelligence to you or the s/w. I chose you.
> Well, obviously there are too many factors involved to pinpoint the problem
> specifically, but that in itself tends to problematic.
Right. There is the line of code in qmail that goes write(), then there
is the OS TCP/IP stack, then typically there is an ethernet card on your machine,
then no doubt a hub - perhaps switched - then a router, then maybe an access
server, then maybe a modem, a phone line, another modem, a serial port,
a ppp layer on a PC, a TCP/IP layer on a PC, a winsock layer, then a PC
application that is often very sensitive to the contents of the email.
I'm obviously being sarcastic here, but how would you like to change the
write() call in qmail exactly?
Regards.
PS. I'm on the list so there is no need to send me a separate copy of
your replies.
On Fri, Jan 28, 2000 at 09:53:28AM -0800, Mark Delany wrote:
> > > > I can't imagine that this could be entirely the OS's fault, considering this
> > > > tends to be a consistent problem regardless of architecture or OS.
> > >
> > > Which problem in particular? qmail has no clue as to whether it is really
>
> > Err, the "large attachment" problem. I don't consider this a resource issue
> > per se; the problem i've experienced more so is the poor handling of
> > extremely large messages.
>
> > To elaborate, users who retrieve large messages via pop3, or transmit large
> > messages via smtp often complain about being disconnected, timing out, or a
> > myriad of other equally vague problems.
>
> Having worked in an ISP environment for many years I can only say that this
> problem is rampant in the industry. I've seen it with qmail, I've seen it with
> qpopper, I've seen it with sendmail, I've seen it with large http documents,
> I've seen it with large ftps...
I agree.
What's curious is that this problem has been so especially prevalent with
qmail.
Obviously, i'm much more suspicious of the MUA. I'm not doubting qmail's
integrity- heck thats why i use it in the first place :), but this has
always left me somewhat perplexed.
It's difficult explaining to people that sometimes things simply dont work,
and it's more than likely their fault for being victimized by industry
propaganda, buying useless equipment, and then expecting to integrate it
seemlessly with my sacrosanct network of the future. An exaggeration,
obviously, but you know what I mean, I'm sure. :)
> Note that the code in qmail is typically *much* simpler than most of the code
> that handles socket traffic (has anyone looked at qpopper 3?) which literally
> boils down to nothing much more than:
>
> while (data = read_from_mail_file()) {
> write_data_to_socket();
> }
>
> I've spent a lot of time looking at these problems and this code and I
> find it very hard to understand what the code could do that would alleviate
> the problem. It totally relies on the OS to manage the TCP/IP session,
> as it should.
That's true.
> > > The only person with the possibility of having such a clue is the person who
> > > admins the system.
> >
> > Thanks for that outstanding vote of confidence :-)
>
> Well, I had to assign intelligence to you or the s/w. I chose you.
Thanks.. er.. i think ;)
> > Well, obviously there are too many factors involved to pinpoint the problem
> > specifically, but that in itself tends to problematic.
>
> Right. There is the line of code in qmail that goes write(), then there
> is the OS TCP/IP stack, then typically there is an ethernet card on your machine,
> then no doubt a hub - perhaps switched - then a router, then maybe an access
> server, then maybe a modem, a phone line, another modem, a serial port,
> a ppp layer on a PC, a TCP/IP layer on a PC, a winsock layer, then a PC
> application that is often very sensitive to the contents of the email.
>
> I'm obviously being sarcastic here, but how would you like to change the
> write() call in qmail exactly?
well, yeah..
I guess super_terrific_write() is out of the question? *duck*
The bottom line i suppose is that there is an arguably infinite number of
variables which could contribute to this, more than likely the majority of
which wouldn't be worth discussing anyhow :)
Off topic, does qmail posess any intrinsic throttling capabilities? I'm
going to guess not, but it'd be interesting to think about.
Jonathan
At 09:53 AM 1/28/00 -0800, Mark Delany wrote or quoted:
>
>> To elaborate, users who retrieve large messages via pop3, or
>> transmit large messages via smtp often complain about being
>> disconnected, timing out, or a myriad of other equally vague
>> problems.
>
>Having worked in an ISP environment for many years I can only say
>that this problem is rampant in the industry.
The problem, as I see it, is that POP3 and SMTP are not designed for the
transmission of large binary messages. They are designed for the
transmission of short-to-medium-sized text messages. Unfortunately, users
in the current era of the "Web as shopping mall" frequently know of no
other way to send *anything*; they have been taught the Net is a
receive-only medium except for email. When they want to transmit something,
they try to do it through email because they don't realize they may have
other options.
My solution to this problem, for my users, has been to make sure they do
have other options, and to make sure they know it. I have worked hard to
impress on them that if they want to send a binary greater than a couple of
hundred Kbytes, they should FTP it to a location on the server (possibly
Web-accessible, possibly only FTP-accessible) and then email the URL to the
interested parties and let them download it at their leisure. I have also
pointed out to them that MIME encoding typically balloons a file by
anywhere from 50% to 85%, and therefore it will take them less time to FTP
the file instead of emailing it. (In other words, I give them an incentive
to avoid emailing large attachments -- their time is probably more valuable
to them than simply making me happy.)
-----------------------------------------------------------------
Kai MacTane
System Administrator
Online Partners.com, Inc.
-----------------------------------------------------------------
>From the Jargon File: (v4.0.0, 25 Jul 1996)
steam-powered /adj./
Old-fashioned or underpowered; archaic. This term does not have a
strong negative loading and may even be used semi-affectionately for
something that clanks and wheezes a lot but hangs in there doing
the job.
On Fri, Jan 28, 2000 at 01:26:57PM -0500, Jonathan Herbert wrote:
> What's curious is that this problem has been so especially prevalent with
> qmail.
I'm curious, but what information do you have available to you that gives
you the impression that huge file attachments being problematic are
"especially prevalent with qmail"?
I know of many other such prevalent problems. How'd qmail get to be so
responsible for everybody else's problems?
Again, just curious.
--
Brad Shelton On Line Exchange http://online-isp.com
Jonathan Herbert wrote:
> I've implemented qmail in a number of environments, including small to
> medium sized ISPs, research groups, and private companies as
> well. One of the main complaints has always been the amorphous
> "problem with large attachments".
>
> I can't imagine that this could be entirely the OS's fault,
> considering this
> tends to be a consistent problem regardless of architecture or OS.
I think it's simply that the big stuff always pushes the OS and hardware a
lot harder than the little stuff. The OS will generally work fine with a
light load -- after all, that's easy to test, and if it dies under light
load, EVERYONE will complain and it'll get fixed. It's the heavy loads that
show the problems, whether it's a load due to mail or anything else.
-Matt
--
Matt Brown ---- UNIX Administrator ---- tickets.com
Phone: (714) 327-5571 --- Email: [EMAIL PROTECTED]
On Fri, Jan 28, 2000 at 02:16:13PM -0500, Brad Shelton wrote:
> On Fri, Jan 28, 2000 at 01:26:57PM -0500, Jonathan Herbert wrote:
>
> > What's curious is that this problem has been so especially prevalent with
> > qmail.
>
> I'm curious, but what information do you have available to you that gives
> you the impression that huge file attachments being problematic are
> "especially prevalent with qmail"?
Like Kai said, i assume this has more to do with what the ordinairy
user views as an acceptable transmission method. Why use something that
works, like ftp, or scp, when you can a [to some degree, i'm sure] less
reliable medium such as email?
And i'm going on strictly user testimonials. Trying to quantify this sort of
thing would be an outrageous nightmare, i'm sure.
> I know of many other such prevalent problems. How'd qmail get to be so
> responsible for everybody else's problems?
Now you're taking me a little too seriously, i think. I'm not blaming qmail,
or any MTA for that matter. The fact of it is that something is going on,
which i can't adequately explain. I could be the only person who has
experienced this, but i know that not to be the case. Even on this list,
every once in a while this issue [if you could even call it that now] pops
up on this list.
I'm not trying to lure anybody into a flame war, and i'm not attempting to
defile the temple of qmail, so don't worry :)
Jonathan
> The problem, as I see it, is that POP3 and SMTP are not designed for the
> transmission of large binary messages. They are designed for the
> transmission of short-to-medium-sized text messages. Unfortunately, users
A lot of people say this and I don't see a particular reason why it
should be the case. Both POP and SMTP do little more than read a file
and write it to a socket. ftp does little more than read a file and
write it to a socket. In the case of binary, the file will be encoded,
big deal.
Perhaps the problem is that email clients tend not to deal well with
large files - that's a bug. The reality is that people find email an easy method
to send things and I'm sure they will continue to do so. And, as people who
provide email services perhaps we should be making sure it does what people
want rather than bemoaning the fact that it lets technical novices exchange
all sorts of unlikely data with each other.
Mark.
Mark Delany <[EMAIL PROTECTED]> wrote on Fri, 28 Jan 2000:
> A lot of people say this and I don't see a particular reason why it
> should be the case. Both POP and SMTP do little more than read a file
> and write it to a socket. ftp does little more than read a file and
> write it to a socket. In the case of binary, the file will be encoded,
> big deal.
I don't quite agree. HTML is a good example of why, it's a document
structure defining language overall, yet people have insisted on adding
formatting/display specific features to it. These features don't work
too well, anyone who's working with web design knows the problems. The
fundamental problem here is using a tool for something it was not
designed for. A screwdriver makes for a bad hammer: though it may
work for small nails, for large nails you need something that can't
really be called a screwdriver anymore.
The same reason is why I think in principle email shouldn't be used
for large file transfer, similar problems will (and have) come up.
Using the right tool for each job is still sound advice.
Mikko,
feeling philosophical, and somewhat off-topic apparently
--
// Mikko Hänninen, aka. Wizzu // [EMAIL PROTECTED] // http://www.iki.fi/wiz/
// The Corrs list maintainer // net.freak // DALnet IRC operator /
// Interests: roleplaying, Linux, the Net, fantasy & scifi, the Corrs /
You will pay the price for your lack of vision!
>A lot of people say this and I don't see a particular reason why it
>should be the case. Both POP and SMTP do little more than read a file
>and write it to a socket. ftp does little more than read a file and
>write it to a socket. In the case of binary, the file will be encoded,
>big deal.
>
>Perhaps the problem is that email clients tend not to deal well with
>large files - that's a bug. The reality is that people find email an easy method
>to send things and I'm sure they will continue to do so. And, as people who
>provide email services perhaps we should be making sure it does what people
>want rather than bemoaning the fact that it lets technical novices exchange
>all sorts of unlikely data with each other.
I assume one problem is the fact that the elements you state in
your first paragraph all rely on a *continuous* connection being
available for a given transmission.
That is, if the connection is dropped for any reason -- and TCP/IP
protocols, as I understand them, are not designed to protect the
sanctity of a connection above all else -- then the entire transmission
(of that email, anyway) is lost, since, unlike some other protocols,
there isn't (as I understand it) a higher-level facility to restart
the transmission (after re-establishing the connection) where the
last successful one left off.
In an extreme case, if a spurious disconnect of all TCP/IP connections
between machines K and R occurs every 10 minutes with 100% reliability,
and never occurs at any other time, then emails that take 10 or more
minutes to transmit will, no matter how often retries occur, *never*
be transmitted. Shorter emails will succeed (geometrically, or
something like that) proportional to the amount of time they need fewer
than 10 minutes.
In a sense, designing a system for robustness at many levels can
end up making it seem less than robust at those very levels due to
problems that are on *other* levels (such as the disconnect problem),
as people using the system believe they can act in ways that basically
stress the robust levels until they are over-extended vis-a-vis the
non-robust ones.
I.e. if the networking software is designed to be so robust that those
every-10-minute outages are basically never noticed, then as people
gain confidence in the 'net, they'll stress a system like SMTP, which
was not designed to be quite so robust (it can't resume transmission
after a broken connection), until it suddenly fails, and they'll think
the problem is elsewhere (qmail, networking software), when it's first
and foremost in the every-10-minute outage, secondarily in the SMTP
protocol.
If I'm wrong that SMTP can't continue a broken transmission or other
stuff, apologies. And, some of my points were already made in other
ways on this topic. I'm basically agreeing that the problem isn't
necessarily in qmail, but can *appear* to be there due to lots of other
factors.
Kinda like how people often believed GNU/Linux, especially through
1996 or so, was flakier than Windows 3.1 and then 95, because all you
had to do was use gcc to compile the kernel to crash lots of systems,
systems that ran Windows just fine. When, in the vast majority of those
cases, it was the hardware (e.g. memory subsystem) that was failing,
only GNU/Linux stressed it hard enough to fail, something that was
apparently very hard to do (under normal circumstance) with Windows.
The lesson here is that just because POP/SMTP/whatever do "little more than"
read and write, it's the facilities upon which they rely to be that simple
that must also be robust. If those facilities (e.g. TCP connections) aren't
sufficiently robust, then either improve those facilities (often requiring
lots of different approaches in different shops), or improve POP/SMTP/whatever
(requiring One Fix that everyone can copy, except that it makes the code
no longer so obviously simple).
Ditto for GNU/Linux, which could have been "fixed" to get around those
hardware problems by either willfully running slower/leaner or by including
lots of special magic to trap and correctly resume after most types of
memory errors. The former, even the latter, could be viewed as crippling
the software to accommodate the hardware. Ditto for fixing POP/SMTP/whatever
to cope better with dropped connections or having qmail handle large emails
specially. But sometimes that sort of crippling is the best practical
alternative.
tq vm, (burley)
Every time I have run into the large email download problem it is because
the clients email software would reach its mail check time and abort the
current download and start over. This is buggy client code, not the
server. :) When we have a customer call, we tell them to turn of the
auto mail check, perform a manual download and restart the auto mail check
after the manual check completes. This has worked every time for us.
On Fri, 28 Jan 2000, Jonathan Herbert wrote:
> On Fri, Jan 28, 2000 at 08:50:58AM -0800, Mark Delany wrote:
> > On Fri, Jan 28, 2000 at 11:25:51AM -0500, Jonathan Herbert wrote:
> >
> > > > > On 28 Jan 00, at 11:29, Henrik Öhman wrote:
> > > > > > A user just sent 2 subsequent mails to a mailing list, both including quite
> > > > > > large attachments (looking in ~user/list/archive, the files are 1,2Mb and
> > > > > > 730kb respectively) to 21 users. This is quite heavy on a 128kbit line,
>esp.
> > > > > > since concurrencyremote is 20, so I expect that each qmail-remote takes its
> > > > > > share of the bandwidth, leaving 128/20 kbit per delivery.
> > >
> > > I've implemented qmail in a number of environments, including small to
> > > medium sized ISPs, research groups, and private companies as well. One of
> > > the main complaints has always been the amorphous "problem with large
> > > attachments".
> > >
> > > I can't imagine that this could be entirely the OS's fault, considering this
> > > tends to be a consistent problem regardless of architecture or OS.
> >
> > Which problem in particular? qmail has no clue as to whether it is really
> > running on a 486 with 8MB or memory and a 2400bps link or a 64x CPU E10000
> > with a couple gig of memory and an OC48 connection to the Internet.
>
> Err, the "large attachment" problem. I don't consider this a resource issue
> per se; the problem i've experienced more so is the poor handling of
> extremely large messages.
>
> To elaborate, users who retrieve large messages via pop3, or transmit large
> messages via smtp often complain about being disconnected, timing out, or a
> myriad of other equally vague problems.
>
> > The only person with the possibility of having such a clue is the person who
> > admins the system.
>
> Thanks for that outstanding vote of confidence :-)
>
> > Based on this, my suggestion is that resource consumption by anything that runs
> > on a system is something that should be controlled by the admin. That qmail lets
> > you utilize the system resource controls to *gracefully* control just about every
> > resource type on a system means that you can tune it fairly precisely to your
>needs.
>
> [...]
>
>
> Well, obviously there are too many factors involved to pinpoint the problem
> specifically, but that in itself tends to problematic.
>
> Even ruling out user error, configuration mishaps, wind sheer, and solar
> radiation, users still tend to complain about the mailserver [qmail] not
> handling large messages well.
>
> Similarly, i've never encountered it in any capacity which could be viewed
> as debilitating.
>
> I'm simply wondering if this is a known issue- it seems that i'm not the
> only one whos run into this in some way shape or form. And it's that which
> makes me think there is more substantiality to this claim than is openly
> realized.
>
> Jonathan
>
> [PS, i'm not trolling. please dont think i'm trolling, I know how
> defensive this list can get on occasion. :)]
>
>
---------------------------------
Timothy L. Mayo mailto:[EMAIL PROTECTED]
Senior Systems Administrator
localconnect(sm)
http://www.localconnect.net/
The National Business Network Inc. http://www.nb.net/
One Monroeville Center, Suite 850
Monroeville, PA 15146
(412) 810-8888 Phone
(412) 810-8886 Fax
On Fri, Jan 28, 2000 at 04:19:25PM -0500, Timothy L. Mayo wrote:
> Every time I have run into the large email download problem it is because
> the clients email software would reach its mail check time and abort the
> current download and start over. This is buggy client code, not the
> server. :) When we have a customer call, we tell them to turn of the
> auto mail check, perform a manual download and restart the auto mail check
> after the manual check completes. This has worked every time for us.
Thats interesting. I'd never have thought of that. I will certainly keep
that handy the next time a user is complaining about this. :)
Thanks!
Jonathan
On Fri, Jan 28, 2000 at 11:59:44AM -0800, Mark Delany wrote:
> > The problem, as I see it, is that POP3 and SMTP are not designed for the
> > transmission of large binary messages. They are designed for the
> > transmission of short-to-medium-sized text messages. Unfortunately, users
>
> A lot of people say this and I don't see a particular reason why it
> should be the case. Both POP and SMTP do little more than read a file
1.2M is not big.
Our site regularly sends >100Mb Email messages through MS
Exchange/Sendmail/Qmail - "my *&^% is bigger than yours!" ;-)
--
Cheers
Jason Haar
Unix/Network Specialist, Trimble NZ
Phone: +64 3 3391 377 Fax: +64 3 3391 417
> > the clients email software would reach its mail check time and abort the
> > current download and start over. This is buggy client code, not the
> > server. :) When we have a customer call, we tell them to turn of the
> > auto mail check, perform a manual download and restart the auto mail
check
> > after the manual check completes. This has worked every time for us.
>
> Thats interesting. I'd never have thought of that. I will certainly keep
> that handy the next time a user is complaining about this. :)
>
Sometimes it not just a big file that causes a hanging of Outlook, etc. I'm
always looking for some rhyme or reason to why Outlook, OE, and other MTAs
hang up in rare cases on certain items. I have probably 1500 dialup-type
customers who check their mail exclusively with OE on my qmail server, and
I get an average of about 1 call per day from a customer who is having OE
hang on an item. I've just learned to live with this. I usually talk the
customer into letting me delete the offending item. But when it happens to
me on my own mail, I get more curious. Day before yesterday it happened to
me on a item that was I was trying to retrieve from the ezmlm mailing list.
When I went into the file on the mail server with a text editor (joe), I
noticed that there were five control characters near the end of the file.
They looked like an underlined @ symbol in joe. Then, using joe, I simply
backspaced over the five characters, and save the file. I then tried again
to retrieve the file with OE and voila! it worked. When I pull the file
into a dos-based text editor in binary mode, it shows them as the NUL char,
hex 00. I'm not sure whether this editor is showing the actual data, or
just replacing the characters with NUL.
I guess the only questions are: where did the control chars come from, and
if they are some uncontrollable artifact of transmission, should OE be able
to retrieve the item even though they are present.
If anyone wants to examine this file, I have saved it in its original form
with the control characters and would be happy to send it.
Dennis Duval
Stig Hackvän <[EMAIL PROTECTED]> writes:
> On Wed, Jan 26, 2000 at 09:23:39PM -0800, Faried Nawaz wrote:
>> And how does someone with /bin/false as their shell put commands in
>> their .qmail files?
> ftp is one way.
So don't put /bin/false in /etc/shells. Why would you want to do this
anyway?
On a stock qmail installation, no users who should not be running
arbitrary commands with their own privileges on the system should be
allowed to create .qmail files. There are various ways of preventing
this; one obvious one is to make their home directory owned by someone
other than them and not writeable by them so that they can't upload files
to it (but can still put files in their web directories or the like).
qmail has no built-in mechanism to support the "limited execution" mode
that sendmail implements with smrsh; if you want that, you can modify
qmail to invoke a limited shell rather than /bin/sh.
--
Russ Allbery ([EMAIL PROTECTED]) <URL:http://www.eyrie.org/~eagle/>
Magnus Bodin <[EMAIL PROTECTED]> writes:
> One question arise: Is there ANY security issues WHATSOEVER to use the
> shell defined in /etc/passwd? Only root should be able to change
> /etc/passwd. So if root assignes a cracked shell to a user, then this is
> not a problem in qmail-land?
There is not a security issue that I can think of, but querying
/etc/passwd can require network traffic to query a remote NIS server.
--
Russ Allbery ([EMAIL PROTECTED]) <URL:http://www.eyrie.org/~eagle/>
Hi,
I checked several docs to find an answer but couldn't find one:
- a mail comes in from outside oder inside (same effect) to: [EMAIL PROTECTED]
- joe exists as a user on that machine
- joe's homedir is defined as /home/joe but does not exist due to a mistake
- there is a file /var/qmail/alias/.qmail-joe which is empty
- qmail accepts the mail with:
Jan 28 14:29:23 ruth qmail: 949066163.816821 new msg 299898
Jan 28 14:29:23 ruth qmail: 949066163.816947 info msg 299898: bytes 1686 from
<[EMAIL PROTECTED]> qp 26722
uid 0
Jan 28 14:29:23 ruth qmail: 949066163.819267 starting delivery 1083: msg 299898 to
local [EMAIL PROTECTED]
Jan 28 14:29:23 ruth qmail: 949066163.819363 status: local 1/10 remote 0/20
Jan 28 14:29:23 ruth qmail: 949066163.983478 delivery 1083: success: did_0+0+1/
Jan 28 14:29:23 ruth qmail: 949066163.983601 status: local 0/10 remote 0/20
Jan 28 14:29:23 ruth qmail: 949066163.983652 end msg 299898
but its not locally deliverd to /var/spool/mail/$USER (procmail).
- there is no bounce, error message or anything else
- I'm using procmail for local delivery.
- there is no users file and no cdb
where is this mail gone ? It's not in postmasters mailbox nor anywhere else I
looked. Is it deleted due to the empty .qmail-joe user ?
TIA
Arne
SALT AG
Berliner Platz 11
D-97080 Würzburg
Telefon: +49.931.3573.400
Telefax: +49.931.3573.409
Email: [EMAIL PROTECTED]
Internet: http://www.salt-ag.com
Hello. I just installed Qmail 1.03 on Solaris 7. Mail deliveries are working
fine, but I just can't get any evidence of mail transport written to
/var/log/syslog. I edited syslog.conf for mail.debug and mail.notice, and I am
piping qmail-send output to logger in my startup script. Basically, I have
followed examples that I found in the documentation and the FAQs. Has anyone
encountered this problem under Solaris 7 at all? If so, what did you do to
resolve it?
Thanks in advance.
Jim
********************************NOTICE*************************************
This transmittal and/or attachments may be a confidential attorney-client
communication or may otherwise be privileged or confidential. If you are not
the intended recipient, you are hereby notified that you have received this
transmittal in error; any review, dissemination, distribution or copying of this
transmittal is strictly prohibited. If you have received this transmittal
and/or attachments in error, please notify us immediately by reply or by
telephone (call us collect at +1 212-848-8400) and immediately delete this
message and all its attachments.
Thank you.
Alok Bhatt <[EMAIL PROTECTED]> writes:
Is there a way to solve this problem.
cd to your qmail source directory, and do "make check".
Hi All!
I followed the installation as per LWQ, but I my SMTP is allowing relaying,
with only localhost on rcpthosts file. Here's my tcp.smtp content:
127.0.0.:allow,RELAYCLIENT=""
216.42.24.88:allow,RELAYCLIENT=""
What could be wrong?
JES
Juan E Suris <[EMAIL PROTECTED]> wrote:
>
> I followed the installation as per LWQ, but I my SMTP is allowing relaying,
> with only localhost on rcpthosts file. Here's my tcp.smtp content:
>
> 127.0.0.:allow,RELAYCLIENT=""
> 216.42.24.88:allow,RELAYCLIENT=""
>
> What could be wrong?
Why do you think your qmail-smtpd is allowing relaying? You haven't provided
any evidence to back up that claim.
This is just a guess, because you haven't given us enough information to
go on, but perhaps just because qmail-smtpd is not immediately aborting
with an error after the RCPT TO: portion of the smtp transaction, you think
that's relaying. It's not a relay unless the message makes it to its
final destination.
Charles
--
----------------------------------------------------
Charles Cazabon <[EMAIL PROTECTED]>
Any opinions expressed are just that -- my opinions.
----------------------------------------------------
Hi there
I have a qmail setup for a single-user-virtual-domain, also running it
from tcpserver with no RELAYCLIENT environment, because I'm not
provided with the customers IP ranges, only a domain suffix. So, I
applied the relayclients and anti-spam patches BUT, as soon as rcpthosts
is in the control directory, the relaying does only work for the virtual
domain, without it anyone is allowd to relay????
Without rcpthost it is an open relay, although there is
relayclients/domains with certain IPs and domins in it.
relayclients:
1.2.3.4:
relaydomains:
.domain.com:
Is constmap() the problem? I just do not want to review the whole code
base. Anyway relayclient is somehow not set.
Does relayclients/domains have any drawback, when having a virtual
domain.
Has somebody a similar setup or documentation explaining on how to do
relaychecking by domain name?
Martin
root@<no, no ... as I said, it is an open relay for now>
This list is definitely being used to harvest e-mail addresses.
[EMAIL PROTECTED]
and
[EMAIL PROTECTED]
Are two of the addresses from which I supposedly received mail on this
address, which obviously I only used for subscription to this list.
I'm not on the list at the moment, if anyone needs to write to me about
this I will still get your mail at this address.
I hate spam.
Hello Jim
On 28-Jan-00, you wrote:
> This list is definitely being used to harvest e-mail addresses.
>
> [EMAIL PROTECTED]
> and
> [EMAIL PROTECTED]
>
> Are two of the addresses from which I supposedly received mail on this
> address, which obviously I only used for subscription to this list.
>
> I'm not on the list at the moment, if anyone needs to write to me about
> this I will still get your mail at this address.
>
> I hate spam.
>
It could be happening at the archive at :-
~~~~~
http://www.ornl.gov/its/archives/mailing-lists
They haven't stripped the e-mail addresses out.
I wonder what they are using to store them.
Most archivers have an option to do this.
Regards...Martin
--
Always remember that you are unique. Just like everyone else.
-- Meade's maxim
I've just set up qmail and it's working pretty well. In fact, too
well. It is automatically aliasing mail for an old address to the
proper user, but I never setup an alias to do so. I was hoping someone
could tell me how qmail is working this particular bit of magic.
I want to receive mail for [EMAIL PROTECTED] and have it delivered
to dee on the local system. The pertinent log and the successful header
are included below. It shows that fixup and fixme got involved somehow,
but I sure don't know how I did it.
Any help will be greatly appreciated.
Thanks.
Tom
[root]$ cat /home/dee/Maildir/new/949117633.15640.olympus.s4rec.com
Return-Path: <[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 15637 invoked by alias); 29 Jan 2000 03:47:13 -0000
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 15633 invoked from network); 29 Jan 2000 03:47:12 -0000
Received: from slkcpop3.slkc.uswest.net (206.81.128.3)
by 166.70.155.14 with SMTP; 29 Jan 2000 03:47:12 -0000
Received: (qmail 4566 invoked by alias); 29 Jan 2000 03:46:47 -0000
Delivered-To: [EMAIL PROTECTED]@fixme
Received: (qmail 4549 invoked by uid 0); 29 Jan 2000 03:46:46 -0000
Received: from unknown (HELO uswest.net) (166.70.155.10)
by pop.slkc.uswest.net with SMTP; 29 Jan 2000 03:46:46 -0000
Sender: tom
Message-ID: <[EMAIL PROTECTED]>
Date: Fri, 28 Jan 2000 20:46:44 -0700
From: Tom Reinertson <[EMAIL PROTECTED]>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: test --ignore
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
[root]$ cat /var/log/mail
Jan 28 20:47:12 olympus qmail: 949117632.752882 new msg 600141
Jan 28 20:47:12 olympus qmail: 949117632.753076 info msg 600141: bytes
879 from <[EMAIL PROTECTED]> qp 15633 uid 7791
Jan 28 20:47:12 olympus qmail: 949117632.773456 starting delivery 95:
msg 600141 to local [EMAIL PROTECTED]
Jan 28 20:47:12 olympus qmail: 949117632.773603 status: local 1/10
remote 0/20
Jan 28 20:47:13 olympus qmail: 949117633.188918 new msg 600139
Jan 28 20:47:13 olympus qmail: 949117633.189213 info msg 600139: bytes
986 from <[EMAIL PROTECTED]> qp 15637 uid 7790
Jan 28 20:47:13 olympus qmail: 949117633.206512 starting delivery 96:
msg 600139 to local [EMAIL PROTECTED]
Jan 28 20:47:13 olympus qmail: 949117633.206659 status: local 2/10
remote 0/20
Jan 28 20:47:13 olympus qmail: 949117633.206761 delivery 95: success:
did_0+1+0/qp_15637/
Jan 28 20:47:13 olympus qmail: 949117633.206858 status: local 1/10
remote 0/20
Jan 28 20:47:13 olympus qmail: 949117633.206948 end msg 600141
Jan 28 20:47:13 olympus qmail: 949117633.420290 delivery 96: success:
did_1+0+0/
Jan 28 20:47:13 olympus qmail: 949117633.420594 status: local 0/10
remote 0/20
Jan 28 20:47:13 olympus qmail: 949117633.420694 end msg 600139
--
"One, they speak English. Two, when they host a world championship,
they invite other countries. Three, visitors to the office of the
head of state are only expected to go down on one knee."
-- John Cleese on why the British are superior to Americans
At 05:40 29/01/00 , you wrote:
>I've just set up qmail and it's working pretty well. In fact, too
>well. It is automatically aliasing mail for an old address to the
>proper user, but I never setup an alias to do so. I was hoping someone
>could tell me how qmail is working this particular bit of magic.
>
>I want to receive mail for [EMAIL PROTECTED] and have it delivered
>to dee on the local system. The pertinent log and the successful header
>are included below. It shows that fixup and fixme got involved somehow,
>but I sure don't know how I did it.
ehm, do you have a /var/qmail/alias/.qmail-deemac file?
if not, create it and type [EMAIL PROTECTED] in it and it should do
the trick for you.
>Any help will be greatly appreciated.
>
>Thanks.
>
>Tom
>
>
>[root]$ cat /home/dee/Maildir/new/949117633.15640.olympus.s4rec.com
>Return-Path: <[EMAIL PROTECTED]>
>Delivered-To: [EMAIL PROTECTED]
>Received: (qmail 15637 invoked by alias); 29 Jan 2000 03:47:13 -0000
>Delivered-To: [EMAIL PROTECTED]
>Received: (qmail 15633 invoked from network); 29 Jan 2000 03:47:12 -0000
>
>Received: from slkcpop3.slkc.uswest.net (206.81.128.3)
> by 166.70.155.14 with SMTP; 29 Jan 2000 03:47:12 -0000
>Received: (qmail 4566 invoked by alias); 29 Jan 2000 03:46:47 -0000
>Delivered-To: [EMAIL PROTECTED]@fixme
>Received: (qmail 4549 invoked by uid 0); 29 Jan 2000 03:46:46 -0000
>Received: from unknown (HELO uswest.net) (166.70.155.10)
> by pop.slkc.uswest.net with SMTP; 29 Jan 2000 03:46:46 -0000
>Sender: tom
>Message-ID: <[EMAIL PROTECTED]>
>Date: Fri, 28 Jan 2000 20:46:44 -0700
>From: Tom Reinertson <[EMAIL PROTECTED]>
>X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.10 i686)
>X-Accept-Language: en
>MIME-Version: 1.0
>To: [EMAIL PROTECTED], [EMAIL PROTECTED]
>Subject: test --ignore
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>[root]$ cat /var/log/mail
>Jan 28 20:47:12 olympus qmail: 949117632.752882 new msg 600141
>Jan 28 20:47:12 olympus qmail: 949117632.753076 info msg 600141: bytes
>879 from <[EMAIL PROTECTED]> qp 15633 uid 7791
>Jan 28 20:47:12 olympus qmail: 949117632.773456 starting delivery 95:
>msg 600141 to local [EMAIL PROTECTED]
>Jan 28 20:47:12 olympus qmail: 949117632.773603 status: local 1/10
>remote 0/20
>Jan 28 20:47:13 olympus qmail: 949117633.188918 new msg 600139
>Jan 28 20:47:13 olympus qmail: 949117633.189213 info msg 600139: bytes
>986 from <[EMAIL PROTECTED]> qp 15637 uid 7790
>Jan 28 20:47:13 olympus qmail: 949117633.206512 starting delivery 96:
>msg 600139 to local [EMAIL PROTECTED]
>Jan 28 20:47:13 olympus qmail: 949117633.206659 status: local 2/10
>remote 0/20
>Jan 28 20:47:13 olympus qmail: 949117633.206761 delivery 95: success:
>did_0+1+0/qp_15637/
>Jan 28 20:47:13 olympus qmail: 949117633.206858 status: local 1/10
>remote 0/20
>Jan 28 20:47:13 olympus qmail: 949117633.206948 end msg 600141
>Jan 28 20:47:13 olympus qmail: 949117633.420290 delivery 96: success:
>did_1+0+0/
>Jan 28 20:47:13 olympus qmail: 949117633.420594 status: local 0/10
>remote 0/20
>Jan 28 20:47:13 olympus qmail: 949117633.420694 end msg 600139
>
>
>--
>
>"One, they speak English. Two, when they host a world championship,
>they invite other countries. Three, visitors to the office of the
>head of state are only expected to go down on one knee."
>-- John Cleese on why the British are superior to Americans
>
>
Mikael Schmidt <[EMAIL PROTECTED]> http://teddybear.cx/
http://www.itsec.nu/ "When you dream, there are no rules....
Certified Linux Administrator People can fly, anything can happen..."
watata tuoijombade dikombe - Astral Projection
Mikael Schmidt <[EMAIL PROTECTED]> wrote on Sat, 29 Jan 2000:
> >I want to receive mail for [EMAIL PROTECTED] and have it delivered
> >to dee on the local system.
>
> ehm, do you have a /var/qmail/alias/.qmail-deemac file?
> if not, create it and type [EMAIL PROTECTED] in it and it should do
> the trick for you.
Shouldn't the contents be "&dee@localhost" or maybe just "&dee"?
(The & is optional.) [EMAIL PROTECTED] is where it's going,
but he wanted it to go to the user "dee" on the local system.
Mikko
--
// Mikko Hänninen, aka. Wizzu // [EMAIL PROTECTED] // http://www.iki.fi/wiz/
// The Corrs list maintainer // net.freak // DALnet IRC operator /
// Interests: roleplaying, Linux, the Net, fantasy & scifi, the Corrs /
Note: Signature quote supply exhausted, please refill.
|
I was wondering where a setting existed that would
allow qmail to not be quite so verbose in its logs. Is there anyway, in
maillog, it could just say, for example, a smtp or pop connection was successful
from a certain IP rather than a barrage of junk? It seems counter-active
to put so much stuff. It's not possible to read it all anyways. I
could search the file for keywords with logcheck (as I am currently), but what's
the point of just filling the HD up with (I'm not going to say worthless because
it is.) stuff that'll never be touched.
There's got to be an obvious setting somewhere, so
could someone enlighten me?
Thanks,
Jacob Joseph
|
Hi ALL
I have an urgent problem - why does the stock standard installation of
qmail-1.03 take long (>30 sec)when answering an pop3 request - also is
it correct to have the following in an ps -ef (system is Solaris 7 -
Sparc ultra 450):, about 5-10 tcpservers spawning qmail-popup, and 4-6
rblsmtpd servers???
PLEASE help - suggestions??
Many thanks
--Tonino
On Sat, 29 Jan 2000, TAG wrote:
> Hi ALL
>
> I have an urgent problem - why does the stock standard installation of
> qmail-1.03 take long (>30 sec)when answering an pop3 request - also is
> it correct to have the following in an ps -ef (system is Solaris 7 -
> Sparc ultra 450):, about 5-10 tcpservers spawning qmail-popup, and 4-6
> rblsmtpd servers???
>
> PLEASE help - suggestions??
how are you starting qmail-pop3d? what command-line options to tcpserver?
what does the DNSsay abou the client
RjL
==================================================================
You know that. I know that. But when || Austin, Texas
you talk to a monkey you have to || Email: [EMAIL PROTECTED]
grunt and wave your arms -ck ||
On Sat, 29 Jan 2000 11:25:30 +0200 TAG wrote:
> Hi ALL
> I have an urgent problem - why does the stock standard installation of
> qmail-1.03 take long (>30 sec)when answering an pop3 request
Are you using tcpserver? Assuming that you are, look at the -R
option to suppress ident lookups, and if that doesn't help check
the DNS for the IP addresses your users connect from and/or look
at the -H option.
I can't answer the other questions.
Regards,
Giles
At 12:47 AM 27/1/2000 +0100, you wrote:
>At 03:22 PM 26/1/2000 -0800, Bill Rogers wrote:
>>Installing qmail and thought it would be a breeze just
>>to install daemontools and use old scripts. WRONG.
>>
>>Could someone point me to some standard qmail-* scripts
>>using daemontools .61
>
>I wouldn't call them 'standard', but I've been working on
>some flexible scripts for both qmail and dnscache.
... well, anything you want to run with daemontools, really.
>If you're interested, drop me a line and I'll document them
>and make them available somewhere.
Its is at
<URL:http://www.xs4all.nl/%7Evinces/software/daemontools-iniscripts.html>
Please direct your comments directly at me.
Thanx,
Vince.
