Re: DNS
> so I don't want to make it public until it is. Bullshit. When you expect to get mail there through a mx record your server IS public known. Simple question: is your SMTP server running? YOu can test it by telnetting to port 25 on your machine. Does your successful test connection show up in the logs? If not, you logging is broken. You SHOULD read a DNS book (DNS and BIND by O'Reilly f.e.) or get the qmail and DNS training by Russel Nelson in Oslo :) Regards, Frank
Re: Open Relay
On the qmail list [EMAIL PROTECTED] wrote: > >I am using Qmail and I want to receive mail for "mynet.com.pk" and want = >to forward it to our another mailserver=20 >"welcome.mynet.com.pk" for relaying. OK. >But I want to make the Qmail an = >open relay too. Umm, no. Trust me, you do not want to do that. What makes you think you want to do that? What agreeable things do you think will happen to your server if you run an open relay on it? I can think of several extremely *dis*agreeable things, that's not difficult. >So i deleted recpthosts to make open relay. I=20 Bad idea. >put "mynet.com.pk" in locals but not in rcpthosts. I put = You want to relay mail addressed to mynet.com.pk to welcome.mynet.com.pk, right? Then mynet.com.pk should be in rcpthosts, but not in locals. >":welcome.mynet.com.pk" in smtproutes. Now what i get problem is that,=20 You want mynet.com.pk:welcome.mynet.com.pk in smtproutes. The rest depends on whether you are using the qmail machine as an Internet gateway or not. >whenever I receive mail for "mynet.com.pk" Qmail tries to deliver it = >locally and doeasn't forward it to "welcome.mynet.com.pk". With ":welcome.mynet.com.pk" in smtproutes, *all* mail will be transmitted to welcome.mynet.com.pk. *Except* that addressed to mynet.com.pk, since you had mynet.com.pk in locals. Exactly the opposite of what you want, if I understand you correctly.
cannot remove files in pic directory
Hello, I wanted to stop sending males and I delete qmail/queue/mess and others. But I can never remove files in qmail/queue/pid. If I do, it happens Segmentetion Fault (Core dumpped.). How can I do? [EMAIL PROTECTED]
Qmail crashing TCP/IP-stack
Ok, I know, this sounds quite controversial, and it's probably not even qmail's fault, but I'm curious if anyone else has had the same sort of problem. 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. 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.) What could be the cause of this? Could it be qmail or just an instable linux kernel? Thanks for any comments. System information: PPro 180MHz 64Mb RAM 100Mb Swap 3Com 3c905B (Running in 100Mbit to the router) Slackware 4.0 Linux 2.2.12 (egcs-1.1.2) Using syslogd for logging (I know, I know.. I need to change. How about syslog-ng btw?) On the same server, I also run proftpd apache bind but it's on quite a small scale, and shouldn't matter much. Thanks, Henrik.
Re: Qmail crashing TCP/IP-stack
-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. Well, TCP/IP doesn't work this way. Each connection is trying to steal as much as possible - only if the replies from the opposite sides have (roughly) identical delays, the bandwidth is shared evenly; otherwise, the more responsive hosts get larger share of bandwidth. But anyway... > 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 Which processes are running (ie. actively working)? > and that the > TCP/IP stack is dead. (I can't get a ping reply from our local network and all > connections seem dead.) > > What could be the cause of this? Could it be qmail or just an instable linux > kernel? Unstable kernel. What you describe looks like memory leak somewhere in kernel (network part probably). Simply, by calling normal functions, you CAN'T crash anything in the kernel. qmail is a userspace program, not a kernel program. End of story. > 3Com 3c905B (Running in 100Mbit to the router) Do you use Becker's driver, or 3Com's one? > Linux 2.2.12 (egcs-1.1.2) If it were 2.2.11, I'd know where the leak is... :-) -BEGIN PGP SIGNATURE- Version: PGP 6.0.2 -- QDPGP 2.60 Comment: http://community.wow.net/grt/qdpgp.html iQA/AwUBOJF97lMwP8g7qbw/EQJ3+QCg41B/o5bAqxdHupOBYo+Muc5x+vwAoJnu I+X7+MDDQXvo/+PK8xxWUtuD =yh56 -END PGP SIGNATURE-
Re: Qmail crashing TCP/IP-stack
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. > > Well, TCP/IP doesn't work this way. Each connection is trying to > steal as much as possible - only if the replies from the opposite > sides have (roughly) identical delays, the bandwidth is shared > evenly; otherwise, the more responsive hosts get larger share of > bandwidth. But anyway... > Ok, yeah, I was being a little brief there, but anyway. ;) > > 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 > > Which processes are running (ie. actively working)? > The curious thing is, when I started top, the CPU was 98% idle, so the heavy load must have come during a very short peak. Also, memory usage had sunk to more normal levels after just a few seconds (next time I tried to log into a virtual console, I did not recieve an error message about memory shortage.) As I ran top, all the 20 qmail-remotes were S, as were all other processes (except for top.) The only difference from normal behaviour was that I could not establish any TCP/IP-connection whatsoever. > Unstable kernel. What you describe looks like memory leak > somewhere in kernel (network part probably). Ok, an upgrade is due anyway. Too bad the kernel didn't say anything about it. > Simply, by calling normal functions, you CAN'T crash anything in > the kernel. qmail is a userspace program, not a kernel program. > End of story. Okay, then it should definitely be a kernel level error. > > 3Com 3c905B (Running in 100Mbit to the router) > > Do you use Becker's driver, or 3Com's one? > Becker's. Any differences? Is 3Com's better? Oh, and sorry if I seemed to unrighteously accuse qmail of something. ;) Thanks, Henrik.
qmail Digest 28 Jan 2000 11:00:00 -0000 Issue 894
qmail Digest 28 Jan 2000 11:00:00 - Issue 894 Topics (messages 36220 through 36289): How to watch the current receiving messages? 36220 by: Ari Arantes Filho Re: About offline 36221 by: Faried Nawaz Re: remote root qmail-pop with vpopmail advisory and exploit with patch (fwd) 36222 by: Peter Haworth Loopback? Was: open relay problem 36223 by: Peter Green broadcast message 36224 by: TAG Outlook address book oddity 36225 by: Simon Rae 36229 by: Frank Tegtmeyer 36230 by: Dave Sill Annoyance 36226 by: Tim Hunter 36227 by: Peter Green 36228 by: Dave Sill 36235 by: Chris Johnson 36238 by: Paul Farber Re: problems with 'mail' (procmail?) 36231 by: Dave Sill Re: Queue Problem 36232 by: Dave Sill Re: qmail-pop3d: unable to write pipe 36233 by: Dave Sill Re: Message delivery failure question 36234 by: Dave Sill Re: Strange queue behaviour] 36236 by: Faried Nawaz 36252 by: Chris Readle 36264 by: Chris Readle Getting proper mail notifications 36237 by: Scott Schappell 36239 by: Mark Delany 36240 by: Charles Cazabon 36241 by: Vince Vielhaber 36243 by: Faried Nawaz Re: What MUA do you use? 36242 by: Chris Garrigues 36250 by: Dave Sill 36259 by: Matthew Brown 36277 by: Mark E. Drummond Re: Mail Stuck In Bin 36244 by: Dave Sill Re: smtp authentication 36245 by: Dave Sill Re: qmail delivery slowdown under high load 36246 by: richard.illuin.org Re: More setup questions 36247 by: Dave Sill Re: subdomain qmail locals 36248 by: Dave Sill 36256 by: Robert Sander 36257 by: Scott Schappell 36279 by: Scott Beck 36280 by: Scott Beck Re: VIRTUAL DOMAIN 36249 by: Dave Sill Qmail behaviour 36251 by: Adil Tahiri 36253 by: Dave Sill more about procmail and qmail 36254 by: Jennifer Tippens Re: [FIXED] Getting proper mail notifications 36255 by: Scott Schappell Supervise won't kill tcpserver 36258 by: Bill Rogers Mail stuck in queue - what to do about it? 36260 by: Chris Green 36261 by: Mark Delany 36262 by: Petr Novotny 36263 by: Chris Green 36265 by: Chris Green DNS 36266 by: Juan E Suris 36267 by: Ruben van der Leij 36268 by: Russell P. Sutherland 36269 by: Juan E Suris 36270 by: Chris Johnson 36271 by: Steve Wolfe 36272 by: Juan E Suris 36284 by: Frank Tegtmeyer Re: FLUSH QUEUE 36273 by: Stephen Mills Re: big fat qmail-command hole 36274 by: Stig Hackvän 36275 by: Phil Genera 36278 by: Magnus Bodin "Upgrade" causing "temporary failure" 36276 by: Mark E. Drummond Sleeping qmail 36281 by: Alok Bhatt Re: Duplicates on outbound mail, not inbound 36282 by: D. J. Bernstein Open Relay 36283 by: Muhammad Ali 36285 by: Lorens Kockum cannot remove files in pic directory 36286 by: $BCf@>(J $B??0l(J Qmail crashing TCP/IP-stack 36287 by: Henrik Öhman 36288 by: Petr Novotny 36289 by: Henrik Öhman 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] -- Hi, With qmail-qread, qmail-qstat and qmHandle, I can watch the queue, but how can I see the current open stmp session that are receiving messages? And how can I get more information about these messages? Best regards, Ari Md. Sifat Ullah Patwary wrote: I am running an offline Internet Server. I like to use qmail server in my LAN. How can I queue my out going mail from my LAN till the server goes online and how can i retrive my in coming mails which are also queued in other Inthernet mail (running qmail) server? Use serialmail -- http://cr.yp.to/serialmail.html. The AutoTURN feature will do exactly what you want. Pavel Kankovsky wrote: > On Wed, 26 Jan 2000, Russell Nelson wrote: > > > > 2. qmail-send is run as root? > > > > Yup. Well, qmail-start is run as root. Along the line it gives up > > its rootness, becoming qmail-send, and leaving only qmail-lspawn > > running as root. > > Login is run as root. It switches to my privs and execs my login > shell. Therefore my login shell is run as root. Right? :) Login is run as root. Once you've entered a correct username/password pair, it switches to that user, so it isn't running as root any more. Your login shell runs as your user. It wouldn't make sense otherwise. Maybe this was a troll after all... -- Peter Haworth [EMAIL PR
GFS and Qmail and BIG mail servers
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
Re: subdomain qmail locals
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
I'm implementing SMTP-AUTH testers needed
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
Re: Qmail crashing TCP/IP-stack
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
Re: big fat qmail-command hole
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]) http://www.eyrie.org/~eagle/>
Re: big fat qmail-command hole
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]) http://www.eyrie.org/~eagle/>
Mail accept without existing homedir
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
Re: GFS and Qmail and BIG mail servers
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
Re: Qmail crashing TCP/IP-stack
> 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
Re: Qmail crashing TCP/IP-stack
>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
logging problem on Solaris 7
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.
Re: Qmail crashing TCP/IP-stack
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
Re: Qmail crashing TCP/IP-stack
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 E1 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.
Re: subdomain qmail locals
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: > > > 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 > > > > > 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 > @.domain was to add an entry in /var/qmail/control/locals > for each .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.
Re: Qmail crashing TCP/IP-stack
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 E1 > 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. :)]
Re: Qmail crashing TCP/IP-stack
> > > 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.
Re: Sleeping qmail
Alok Bhatt <[EMAIL PROTECTED]> writes: Is there a way to solve this problem. cd to your qmail source directory, and do "make check".
Re: Qmail crashing TCP/IP-stack
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
Re: Qmail crashing TCP/IP-stack
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.
Open Relay
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
Re: Qmail crashing TCP/IP-stack
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
Re: Open Relay
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.
RE: Qmail crashing TCP/IP-stack
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]
Re: Qmail crashing TCP/IP-stack
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
Re: Qmail crashing TCP/IP-stack
> 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.
Re: Qmail crashing TCP/IP-stack
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!
Re: Qmail crashing TCP/IP-stack
>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)
Re: Qmail crashing TCP/IP-stack
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 E1 > > 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- Phone (412) 810-8886 Fax
Re: Qmail crashing TCP/IP-stack
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
Re: Qmail crashing TCP/IP-stack
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
Re: Qmail crashing TCP/IP-stack
> > 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
single-user-virtual-domain, rcpthosts, relayclients/domains -> no relaychecking vs. virtual domain only
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@
Re: GFS and Qmail and BIG mail servers
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
spammer lurking
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.
Re: spammer lurking
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
Aliases
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 - Delivered-To: [EMAIL PROTECTED] Received: (qmail 15633 invoked from network); 29 Jan 2000 03:47:12 - Received: from slkcpop3.slkc.uswest.net (206.81.128.3) by 166.70.155.14 with SMTP; 29 Jan 2000 03:47:12 - Received: (qmail 4566 invoked by alias); 29 Jan 2000 03:46:47 - Delivered-To: [EMAIL PROTECTED]@fixme Received: (qmail 4549 invoked by uid 0); 29 Jan 2000 03:46:46 - Received: from unknown (HELO uswest.net) (166.70.155.10) by pop.slkc.uswest.net with SMTP; 29 Jan 2000 03:46:46 - 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
Logfile
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
