Non-ASCII-characters in Header
Hello, I'm searching for a patch which lets qmail to accept mails with characters >126 ( e.g. german umlauts ) in the mail headers. I searched all archives but it seems no one didn't ask for this up to now. I know in theory these characters musn't appear in EMail headers but some customers use brain dead mail clients that don't encode the mail headers correctly. To make it worse most mail servers accept mails with Umlauts in headers and without a correct MIME encoding :-( So some mails get bounced back to the customer and they ask us why our mail system doesn't work. I can't change their mail client settings and I'm tired of explaining them what went wrong and that conformant to the RFCs these characters musn't appear in headers. Well, sendmail accepts these mails and doesn't reject it ( which doesn't mean anything :-) ). I had a quick look at the qmail source in token822.c but I didn't see an obvious way to do this, it would be great if someone of you may have a solution for this. Regards Juergen
Re: ESMTP problems with Qmail 1.03
On Tue, Apr 13, 1999 at 10:55:43AM +1200, Karl Lellman wrote: > I have a customer who runs Qmail 1.03 on RedHat Linux 5.1 as a SMTP relay > between the internet and their internal MS Exchange server. > > They have started to encounter delivery and reception problems with a couple > of sites and the only thing I can narrow it down to is that these sites want > to use ESMTP. What are the delivery and reception problems? What's in the logs? They simultaneously start to have both delivery and reception problems with the same site? > They have been able to send and received emails from these sites fine up > until about 4-6 weeks ago. Are there any known issues with ESMTP? Has a > new version of Sendmail been released recently that does something different > with ESMTP? One person that we have talked to said it might be a problem > with qmail not being able to deal with two 220 responses? qmail-remote shouldn't have any problems with properly constructed multi-line responses. qmail-remote will read the response code from the first line of the response, and then just chew up and ignore the rest of the lines. The remote end could send a hundred consecutive 220 responses if it did it correctly. > The customers mail server is 'mail.renaissance.co.nz', one of the SMTP > servers that they are having trouble with is 'mail.compaq.com'. For a typical problematic message, what do the logs say? Chris
Re: ESMTP problems with Qmail 1.03
Quoting Karl Lellman ([EMAIL PROTECTED]): > I have a customer who runs Qmail 1.03 on RedHat Linux 5.1 as a SMTP relay > between the internet and their internal MS Exchange server. > > They have started to encounter delivery and reception problems with a couple > of sites and the only thing I can narrow it down to is that these sites want > to use ESMTP. > > They have been able to send and received emails from these sites fine up > until about 4-6 weeks ago. Are there any known issues with ESMTP? Has a > new version of Sendmail been released recently that does something different > with ESMTP? One person that we have talked to said it might be a problem > with qmail not being able to deal with two 220 responses? > > The customers mail server is 'mail.renaissance.co.nz', one of the SMTP > servers that they are having trouble with is 'mail.compaq.com'. You sent a similiar query about this a few weeks ago, did you not? Harald Hanche-Olsen said ``As far as I can tell, this falls into the `this cannot happen' '' category. I was able to send email to an address at eagle.co.nz, which apparently mail.renaissance.co.nz was having trouble delivering to, using our qmail 1.03 server. Hence, make sure that the version of qmail they are using there hasn't been patched or modified in some way. You said the renaissance.co.nz mail server behaved as below, which would be mighty strange for stock qmail (logs from eagle.co.nz's mail server, apparently): > | At Mon Mar 15 18:22:27 1999 > | call from renaissance.co.nz/203.97.88.2 > | 220-relay ESMTP SMTP/smap Ready. > | 220 ESMTP tried here > | HELO renaissance.co.nz > | 250 (renaissance.co.nz) pleased to meet you. > | QUIT > | 221 Closing connection Aaron
ESMTP problems with Qmail 1.03
I have a customer who runs Qmail 1.03 on RedHat Linux 5.1 as a SMTP relay between the internet and their internal MS Exchange server. They have started to encounter delivery and reception problems with a couple of sites and the only thing I can narrow it down to is that these sites want to use ESMTP. They have been able to send and received emails from these sites fine up until about 4-6 weeks ago. Are there any known issues with ESMTP? Has a new version of Sendmail been released recently that does something different with ESMTP? One person that we have talked to said it might be a problem with qmail not being able to deal with two 220 responses? The customers mail server is 'mail.renaissance.co.nz', one of the SMTP servers that they are having trouble with is 'mail.compaq.com'. Thanks, Karl Lellman Systems Consultant Extranet Technologies Limited PO Box 47-808, Auckland, New Zealand Mobile +64 25 771188, Phone +64 9 4795352, Fax +64 9 4795312 e-mail: [EMAIL PROTECTED]
Re: [Q] qmail speed "again"
On 12 Apr 1999 [EMAIL PROTECTED] wrote: > > ...the root problem is qmail's rudeness in this area. > > You may have a point here. Is there a well-defined rubric within which > we can assert, "It is ill-mannered to consume all available > connections to a remote server, just because those services are > needed?" Could be, I suppose--that's a question for admins. The point is that, in a lot of cases, they aren't needed. If you have 50 messages to go out with 100 messages to each of 5000 hosts, the claim that it is necessary to open 100 connections at once to any single remote server is obviously wrong. You can, in general, keep your system "busy" (where busy is often "running into the low concurrencyremote limit forced by qmail's design") just fine without opening a huge number of connections to any one server. Yet if you feed qmail the addresses in an order sorted by hostname, that is essentially what it will do. Heck, even if you had 50 messages to go to 1 host that doesn't mean you have to open 50 connections (well, bounded only by your local configuration and qmail's limits) to the remote host. You can claim it is just "broken mailers" that have trouble under such situations, but I have never seen a single "nonbroken mailer" by that definition.
Re: cyclog vs. syslog (was: Queue limit question)
Keith Burdis wrote/schrieb/scribsit: > On Mon 1999-04-12 (15:34), Stefan Paletta wrote: > > You can use ucspi-tcp to reliably send log messages from one program's > > stdout to a cyclog on another host. > > Please could you show an example of how you'd do this. mailto:[EMAIL PROTECTED] Stefan
Re: [Q] qmail speed "again"
Timothy L Mayo <[EMAIL PROTECTED]> writes: > Neither Keith nor I are talking about the mailer. If the remote MACHINE > cannot handle the load, it should be set up to reject the excess > connections. This is true no matter WHAT MTA is running on the remote > system. This is great in theory. In practice, does your tcpserver setup automatically start refusing connections when you're low on queue space or when you know the load will be too high? I bet it doesn't. The reason why it doesn't isn't because it's poorly designed. It's because it's hard to do this. You have to be partially psychic in order to always catch it. sendmail has a bunch of load-limiting features, particularly in the latest versions. It can start queuing instead of mailing directly, it can refuse connections entirely, and it can do this on the basis of the current number of running daemons, system load, or disk space. It's still relatively easy to make a machine running sendmail fall over under load. It's harder for qmail primarily because qmail is small and fast, not because it has any better load management capabilities near the boundary of what the machine can cope with than sendmail does. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/>
Re: [Q] qmail speed "again"
On Tue, Apr 13, 1999 at 05:35:19PM -0400, Craig I. Hagan wrote: > As for those bulk senders, a relatively painless solution is to randomize the > order of the domains and/or pull out the top 5 and serially send those. Your > tools *do* talk smtp, don't they? qmail-remote will handle multiple RCPT TOs in a single SMTP transaction. If you're into bulk mailing, you can write a script to sort your recipient list and call qmail-remote directly, one invocation for each remote host. Chris
BARE LF, again
what is considered the BEST method of accepting bare LFs patching smtpd? putting fixcr in the pipeline, and what would be the best way to do that? Thanks
Re: [Q] qmail speed "again"
> I think DJB has given a mathematically rigorous proof that "program > which is vulnerable to DoS" is one definition of "server". When a > server is serving all it can, it will refuse to serve any more. QED this is accurate for a single function server. in a multifunction server, it would be smart for the administrators to construct it in such a fashion such that one function can't seriously degrade other offered functionality. > > ...the root problem is qmail's rudeness in this area. > > You may have a point here. Is there a well-defined rubric within which > we can assert, "It is ill-mannered to consume all available > connections to a remote server, just because those services are > needed?" Could be, I suppose--that's a question for admins. i would add ineffient as well as ill-mannered. consider the system overhead requred to fork processes/threads on both servers combined with the network and application startup time for the connections, and it becomes obvious that when delivering a statistically large amount of mail to a single recipient server, it makes more sense to pipeline the mail. of course, we all knew this to begin with. OTOH, qmail works because in non-bulk sending mode (hint to folks) there is a reasonably random distribution of domain names which really only sees problems upon death/unreachability of a specific target. As for those bulk senders, a relatively painless solution is to randomize the order of the domains and/or pull out the top 5 and serially send those. Your tools *do* talk smtp, don't they? > Given that all service requests were legitimate, I would not mind my > server being pegged with connections from one host. When such > conditions become routine, from particular hosts, taking appropriate > action is why Sys Admins get paid. Of course, that's just MHO. better pegged from legit mail than pegged by script kiddies ;) -- craig
Re: [Q] qmail speed "again"
Marc Slemko <[EMAIL PROTECTED]> writes: > On Mon, 12 Apr 1999, Timothy L. Mayo wrote: > > > If you cannot limit the number of connections you will accept to > > something your system can handle, you need to re-think your setup. > > Erm... you just described a classic DoS attack. You put a limit of > x connections in. One remote system uses all or nearly all of them. > No one else can connect. Erm... DoS may be a sensitive subject on this list! :-) I think DJB has given a mathematically rigorous proof that "program which is vulnerable to DoS" is one definition of "server". When a server is serving all it can, it will refuse to serve any more. QED The upshot is that _preventing_ a DoS is not at all possible. Any rate-limiting, or other countermeasures you adopt, merely adjusts the parameters within which a DoS must be conducted. Limiting concurrency, ulimits, etc., are not about _preventing_ DoS, which is impossible, but about ensuring that even under maxed-out conditions the mail server will not die or become unstable. > ...the root problem is qmail's rudeness in this area. You may have a point here. Is there a well-defined rubric within which we can assert, "It is ill-mannered to consume all available connections to a remote server, just because those services are needed?" Could be, I suppose--that's a question for admins. Given that all service requests were legitimate, I would not mind my server being pegged with connections from one host. When such conditions become routine, from particular hosts, taking appropriate action is why Sys Admins get paid. Of course, that's just MHO. Len. -- 103. In Company of your Betters be not longer in eating than they are lay not your Arm but only your hand upon the table. -- George Washington, "Rules of Civility & Decent Behaviour"
Re: [Q] qmail speed "again"
Neither Keith nor I are talking about the mailer. If the remote MACHINE cannot handle the load, it should be set up to reject the excess connections. This is true no matter WHAT MTA is running on the remote system. What is a valid limit? Only the administrator of that particular machine knows since it depends on what the hardware is, what other software is running, etc... The sending qmail only knows one thing, you accepted the connection so you can handle the load. On Mon, 12 Apr 1999, Marc Slemko wrote: > On Mon, 12 Apr 1999, Keith Burdis wrote: > > > > qmail is great that way at inflicting remote DoS attacks against other > > > mailers. > > > > Well, the obvious question is why do mailers accept connections that they > > cannot handle? If the remote host accepts the mail it should be prepared to > > deal with it. > > blah blah blah. > > I don't know? Why does "qmail" accept connections that it cannot handle? > > It is a pretty simple concept: even if a mailer can "handle" it, if you > send 1 simultaneous bit of mail to 1 machine, while using all your other > slots for sending to other machines, you will get x% of each machine's > resources. If you send 120 simultaneous messages, then you only get y% of > the machine's resources, where y is between a little (eg. if the machine > normally has 1 incoming connections) to a huge amount (eg. if the > machine normally has 2 incoming connections) less than x. > > Because of somewhat nonsensical hard coded limits, when sending a lot of > outbound mail with qmail, the number of simultaneous connections open > total often is a big limitation. Because of that, the fastest way to send > mail is to ensure you aren't overloading any remote machine more than > necessary at any given time, so that each connection to that machine takes > the least time possible, even if that involves more seialization. > > Trying to blame the remote mailer for qmail's less than great behaviour in > this area is silly. > > - 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: [Q] qmail speed "again"
Marc Slemko <[EMAIL PROTECTED]> writes on 12 April 1999 at 13:24:34 -0700 > On Mon, 12 Apr 1999, Keith Burdis wrote: > > > > qmail is great that way at inflicting remote DoS attacks against other > > > mailers. > > > > Well, the obvious question is why do mailers accept connections that they > > cannot handle? If the remote host accepts the mail it should be prepared to > > deal with it. > > blah blah blah. > > I don't know? Why does "qmail" accept connections that it cannot handle? Because it's not intended to run as a standalone daemon; it runs either under inetd or tcpserver or whatever, and load-based decisions about accepting connections should be implemented at that level? > It is a pretty simple concept: even if a mailer can "handle" it, if you > send 1 simultaneous bit of mail to 1 machine, while using all your other > slots for sending to other machines, you will get x% of each machine's > resources. If you send 120 simultaneous messages, then you only get y% of > the machine's resources, where y is between a little (eg. if the machine > normally has 1 incoming connections) to a huge amount (eg. if the > machine normally has 2 incoming connections) less than x. The other pretty simple concept is that carefully sorting the queue out by the IP that will actually handle the connection, either to aggregate connections OR to deliberately spread out the load, is *very* expensive (DNS queries), and tends to swamp any benefit to be gained (at least on the aggregation side; the other side, deliberately spreading the load, hasn't to my knowledge been studied as carefully). > Because of somewhat nonsensical hard coded limits, when sending a lot of > outbound mail with qmail, the number of simultaneous connections open > total often is a big limitation. Because of that, the fastest way to send > mail is to ensure you aren't overloading any remote machine more than > necessary at any given time, so that each connection to that machine takes > the least time possible, even if that involves more seialization. I think I can guess what your on about here, and I agree that a byte isn't an appropriate size for the counter on outstanding qmail-remote's. Doesn't affect me personally, but people with heavy mail hubs might well be. Remember, when initially coded this was such a great step up in concurrency that nobody noticed the funny limit. Is this number (either the current count, or perhaps as an id number for a particular task) ever passed through a pipe? I wonder if the limit really comes from simplifying that? > Trying to blame the remote mailer for qmail's less than great behaviour in > this area is silly. I don't think you've made much of a case for "less than great behaviour", personally. -- David Dyer-Bennet [EMAIL PROTECTED] http://www.ddb.com/~ddb (photos, sf) Minicon: http://www.mnstf.org/minicon http://ouroboros.demesne.com/ The Ouroboros Bookworms Join the 20th century before it's too late!
Re: [Q] qmail speed "again"
On Mon, 12 Apr 1999, Timothy L. Mayo wrote: > Only if they are silly enough to accept more connections than they can > handle. :) One of the things a sys admin is "supposed" to do is tune his > machines for performance. If you cannot limit the number of connections > you will accept to something your system can handle, you need to re-think > your setup. Erm... you just described a classic DoS attack. You put a limit of x connections in. One remote system uses all or nearly all of them. No one else can connect. You can hack whatever sorts of other "oh, limit one remote IP to only so many, do this, do that" hacks on top of that you want, and some of them are actually quite useful, but it doesn't change the fact that the root problem is qmail's rudeness in this area. As someone using qmail (for various reasons...), I can't control every other system in the world, and even if I could, simple math still says that a remote machine only has so many resources so trying to make it do too many things at once is counterproductive and just eats up time in qmail-remotes, which is a limited resource in qmail.
Re: [Q] qmail speed "again"
Marc Slemko <[EMAIL PROTECTED]> writes on 12 April 1999 at 13:13:51 -0700 > qmail is great that way at inflicting remote DoS attacks against other > mailers. Well, the other side knows about its capability to accept additional connections. We don't. Basic self-protection, from both enthusiastic mail-movers like qmail *and* deliberate DoS attacks, would call for not accepting connections you can't handle. Rate-limiting should be applied by the side that has the information to do it right. -- David Dyer-Bennet [EMAIL PROTECTED] http://www.ddb.com/~ddb (photos, sf) Minicon: http://www.mnstf.org/minicon http://ouroboros.demesne.com/ The Ouroboros Bookworms Join the 20th century before it's too late!
Re: [Q] qmail speed "again"
On Mon, 12 Apr 1999, Keith Burdis wrote: > > qmail is great that way at inflicting remote DoS attacks against other > > mailers. > > Well, the obvious question is why do mailers accept connections that they > cannot handle? If the remote host accepts the mail it should be prepared to > deal with it. blah blah blah. I don't know? Why does "qmail" accept connections that it cannot handle? It is a pretty simple concept: even if a mailer can "handle" it, if you send 1 simultaneous bit of mail to 1 machine, while using all your other slots for sending to other machines, you will get x% of each machine's resources. If you send 120 simultaneous messages, then you only get y% of the machine's resources, where y is between a little (eg. if the machine normally has 1 incoming connections) to a huge amount (eg. if the machine normally has 2 incoming connections) less than x. Because of somewhat nonsensical hard coded limits, when sending a lot of outbound mail with qmail, the number of simultaneous connections open total often is a big limitation. Because of that, the fastest way to send mail is to ensure you aren't overloading any remote machine more than necessary at any given time, so that each connection to that machine takes the least time possible, even if that involves more seialization. Trying to blame the remote mailer for qmail's less than great behaviour in this area is silly.
Re: [Q] qmail speed "again"
Only if they are silly enough to accept more connections than they can handle. :) One of the things a sys admin is "supposed" to do is tune his machines for performance. If you cannot limit the number of connections you will accept to something your system can handle, you need to re-think your setup. On Mon, 12 Apr 1999, Marc Slemko wrote: > On Mon, 12 Apr 1999, Dave Sill wrote: > > > "Fred Lindberg" <[EMAIL PROTECTED]> wrote: > > > > > >qmail will always be faster than sendmail [unless you send one message > > >to a large number of addresses on the same remote host]. > > > > No, qmail will usually win here, too, because sendmail serializes. > > Sendmail only wins when the message is huge. > > Actually, if you are unfortunate enough to have a list of addresses sorted > by the right side of the @, qmail can be a big loser here. This is > because it will completely overload many remote hosts if there are a bunch > of recipients. eg. concurrencyremote = 120, you have 200 users > @somedomain, qmail will sit there with 120 connections to somedomain's > mailserver open while they all crawl along because somedomain can't handle > 120 connections at once. > > qmail is great that way at inflicting remote DoS attacks against other > mailers. > > - 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: cyclog vs. syslog (was: Queue limit question)
On Mon 1999-04-12 (15:34), Stefan Paletta wrote: > Dave Sill wrote/schrieb/scribsit: > > Disadvantages: only logs messages sent to stdout, only logs messages > > from local system > > You can use ucspi-tcp to reliably send log messages from one program's > stdout to a cyclog on another host. Please could you show an example of how you'd do this. - Keith > Stefan -- Keith Burdis - MSc (Com Sci) - Rhodes University, South Africa Email : [EMAIL PROTECTED] WWW : http://www.rucus.ru.ac.za/~keith/ IRC : Panthras JAPH "Any technology sufficiently advanced is indistinguishable from a perl script" Standard disclaimer. ---
Re: [Q] qmail speed "again"
On Mon 1999-04-12 (13:13), Marc Slemko wrote: > On Mon, 12 Apr 1999, Dave Sill wrote: > > > "Fred Lindberg" <[EMAIL PROTECTED]> wrote: > > > > > >qmail will always be faster than sendmail [unless you send one message > > >to a large number of addresses on the same remote host]. > > > > No, qmail will usually win here, too, because sendmail serializes. > > Sendmail only wins when the message is huge. > > Actually, if you are unfortunate enough to have a list of addresses sorted > by the right side of the @, qmail can be a big loser here. This is > because it will completely overload many remote hosts if there are a bunch > of recipients. eg. concurrencyremote = 120, you have 200 users > @somedomain, qmail will sit there with 120 connections to somedomain's > mailserver open while they all crawl along because somedomain can't handle > 120 connections at once. > > qmail is great that way at inflicting remote DoS attacks against other > mailers. Well, the obvious question is why do mailers accept connections that they cannot handle? If the remote host accepts the mail it should be prepared to deal with it. - Keith -- Keith Burdis - MSc (Com Sci) - Rhodes University, South Africa Email : [EMAIL PROTECTED] WWW : http://www.rucus.ru.ac.za/~keith/ IRC : Panthras JAPH "Any technology sufficiently advanced is indistinguishable from a perl script" Standard disclaimer. ---
Re: [Q] qmail speed "again"
On Mon, 12 Apr 1999, Dave Sill wrote: > "Fred Lindberg" <[EMAIL PROTECTED]> wrote: > > > >qmail will always be faster than sendmail [unless you send one message > >to a large number of addresses on the same remote host]. > > No, qmail will usually win here, too, because sendmail serializes. > Sendmail only wins when the message is huge. Actually, if you are unfortunate enough to have a list of addresses sorted by the right side of the @, qmail can be a big loser here. This is because it will completely overload many remote hosts if there are a bunch of recipients. eg. concurrencyremote = 120, you have 200 users @somedomain, qmail will sit there with 120 connections to somedomain's mailserver open while they all crawl along because somedomain can't handle 120 connections at once. qmail is great that way at inflicting remote DoS attacks against other mailers.
Re: [Q] qmail speed "again"
On Mon 1999-04-12 (11:41), Dave Sill wrote: > "Fred Lindberg" <[EMAIL PROTECTED]> wrote: > > > >qmail will always be faster than sendmail [unless you send one message > >to a large number of addresses on the same remote host]. > > No, qmail will usually win here, too, because sendmail serializes. > Sendmail only wins when the message is huge. Sendmail will win if you use multiple rcpt-to's. - Keith > -Dave -- Keith Burdis - MSc (Com Sci) - Rhodes University, South Africa Email : [EMAIL PROTECTED] WWW : http://www.rucus.ru.ac.za/~keith/ IRC : Panthras JAPH "Any technology sufficiently advanced is indistinguishable from a perl script" Standard disclaimer. ---
Main Domain Name
Hi Guys Apr 13 03:05:23 www qmail: 923965523.860137 starting delivery 195: msg 8500 to l ocal [EMAIL PROTECTED] How can i change this main domain name for qmail ? (eg. zechini.it) Best Regards, Luca Pescatore
One user, two email addresses from different real domains
I am trying to set up a new qmail system with three email accounts and am somewhat befuddled. Two users: user1 user2 Three email accounts: [EMAIL PROTECTED] [EMAIL PROTECTED] and user2 has a POP3 email at a local university and would like to check email there, too. So the third address is: [EMAIL PROTECTED] It's ok if user2 replies to emails as [EMAIL PROTECTED] , as long as the Reply To: field says [EMAIL PROTECTED] I think that I have everything working for the first two accounts but I don't really know how to get the third one working (fetchmail, yeah, qmail,no). I installed serialmail and did what the mail queue said: me: hal9000.isp.de rcpthosts: hal9000.isp.de locals: hal9000.isp.de defaultdomain: isp.de virtualdomains: :alias-ppp [EMAIL PROTECTED]:alias-isp [EMAIL PROTECTED]:alias-isp alias/.qmail-ppp-default ../pppdir/ alias/.qmail-isp-user1 &[EMAIL PROTECTED] alias/.qmail-isp-user2 &[EMAIL PROTECTED] I tried entering the uni account in virtualdomains and created an alias but mail addressed to [EMAIL PROTECTED] just ended up bouncing. Can someone help? Thanks, John Park -- Is not marriage an open question, when it is alleged, from the beginning of the world, that such as are in the institution wish to get out, and such as are out wish to get in? -- Ralph Emerson [EMAIL PROTECTED] John Park, Linux User
Re: trouble opening info/8/
It sounds like in between the time a message was being queued (todo/306659) and being processed (info/0/306659) that the information was lost (I am assuming that info/0/306659 does not exist but mess/0/306659 does). You can try running queue-fix (ftp://ftp.netmeridian.com/queue-fix.tar.gz) to clean up your queue. Chances are that message is lost. You may want to look into the OS/filesystem settings since it may not be responding to fsyncs (linux?) -Eric > Hi! > > After our crashed this comes in our log: > > Apr 10 23:32:06 penguin qmail: 923779926.882161 warning: trouble opening > info/0/306659; will try again later > > (and like 15 of them) > > What does this meen? > > -- > michael legart, [EMAIL PROTECTED] > sysadm, http://wiktor.dk >
Re: supervise(1) from the daemontools package
John Conover writes: > Does supervise(1) provide any protection against unauthorized root > access for a network program that faults, say, from a buffer overflow? No. Supervise is a substitute for ad-hoc methods for communicating with daemons. -- -russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | There is good evidence 521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
Re: supervise(1) from the daemontools package
On Mon, Apr 12, 1999 at 05:37:34PM -, John Conover wrote: > Does supervise(1) provide any protection against unauthorized root > access for a network program that faults, say, from a buffer overflow? Supervise just restarts programs AFAIK. How would you design a program where a parent process protects against bugs in the child process? Well... I mean in a reasonable size. I suppose that if you use electric fence and ran the program underneath it, it would sacrifice a word or two of memory on every *alloc and protect from buffer overflows by marking large chunks of memory read-only. That's not a really nice way to do things, but... -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one.
Re: cyclog vs. syslog (was: Queue limit question)
On Mon, 12 Apr 1999 09:05:35 -0400 (EDT), Dave Sill wrote: >dates/times aren't human-readable without "tailocal", throws away >oldest logs. Bruce Guenter has a patch to execute a program on the oldest log before throwing it away. I use cyclog and this feature, where the latter used matchup to add to a matched-up log file, which is what I then analyze once per day and rotate using normal tools. -Sincerely, Fred (Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)
supervise(1) from the daemontools package
Does supervise(1) provide any protection against unauthorized root access for a network program that faults, say, from a buffer overflow? Thanks, John -- John Conover, 631 Lamont Ct., Campbell, CA., 95008, USA. VOX 408.370.2688, FAX 408.379.9602 [EMAIL PROTECTED], http://www2.inow.com/~conover/john.html
Re: Errors retrieving large attachments
Allen Versfeld wrote: Eric Ess wrote: > > A user of my mail system is having problems retrieving emails with attachments >larger than 10k or so. They receive 'server timed out' messages. They are using >Outlook Express as their email client. I'm using qmail 1.03 on a RedHat 5.2 server. >The maillog doesn't show any errors. > :> Outlook Express is timing out, not qmail. I get this complaint a lot, :> because practically all of our customers use it. :> I'm surprised he has trouble with such small attachments, though... Is :> he using Windows 98? No, the user is using Windows NT. What did you do to solve the problem? (besides telling them to use a better client ;) Are there settings in OE or Windows I can tweak?
Re: How to change delivery search order?
On Mon, Apr 12, 1999 at 11:04:15AM -0500, Greg Moeller wrote: > Yes, this is the same setting up of Email on our big server. > Things are mostly working, but we have a problem with how the server decides > how to deliver. > As it is, it checks for a user, and if there is, then delivers based on that. > (and if the user has a .qmail file in their home dir) > I'm running Fast forward, and there are mappings in there for users that exist. > These mappings are supposed to override the users normal delivery, but they > don't. They're not supposed to override anything. fastforward delivery is normally set up in ~alias/.qmail-default, and ~alias/.qmail-default won't handle a delivery to a user until it's been determined that the user isn't in qmail-users, there's no account for user, and ~alias/.qmail-user doesn't exist. Then ~alias/.qmail-default handles the delivery, and your fastforward database is consulted. > How can I make it deliver to what's in the fast forward database over > anything else? There's over 50,000 users on the system, so just throwing in > a .qmail in the home dirs for each exception would be troublsum to program. You might make the domain a virtual domain instead of a local domain. In control/virtualdomains, put: yourdomain.com:alias-yourdomain In ~alias/.qmail-yourdomain-default, put: | fastforward -d -p /etc/aliases.cdb | forward "$DEFAULT" fastforward will get first whack at delivery. The -p causes fastforward to exit 0 if delivery fails, causing delivery to be handled by the next line, which forwards the mail to the local user $DEFAULT. Chris
RE: [Q] qmail speed "again"
Umm.. Why didn't you use /var/qmail/bin/sendmail ? > -Original Message- > From: Samuel Dries-Daffner [SMTP:[EMAIL PROTECTED]] > Sent: Monday, April 12, 1999 12:19 PM > To: Dave Sill > Cc: [EMAIL PROTECTED] > Subject: Re: [Q] qmail speed "again" > > > > On Mon, 12 Apr 1999, Dave Sill wrote: > > > Silver CHEN <[EMAIL PROTECTED]> wrote: > > > > > > The mail reason that I can't switch to qmail is that I'm NOT > > >familiar with qmail in early days, so I chose sendmail. > > > > You can install qmail without removing/breaking sendmail, so you can > > revert to sendmail easily. > > On our server (SGI Indy -- IRIX 6.5) this was mostly true, with one > exception-- BSD mail users. > > We had a problem with a sendmail that was re-installed by default on > our > IRIX upgrades. ...because it seemed to be called by those users still > using BSD mail on our system. Other users (like pine, IMAP, POP) had > no > problems. So we made a simple wrapper of sendmail that piped messages > to > qmail-inject. > > > FWIW--- > > Samuel Daffner > Mills College ITS
Re: question on mail relay
On Mon, 12 Apr 1999, Harald Hanche-Olsen wrote: > | Sorry for a noise.I've the following problem: > | /etc/tcp.smtp file as follows: [...] > | as in FAQ I do: > | cat /etc/tcp.smtp | /usr/local/tcpserver/bin/tcprules /etc/tcp.smtp.cdb >~/tcp.smtp.tmp > Bad idea. The cdb file and the tmp file must be on the same > filesystem. Your invocation would also have earned you a "Useless use them are on the same filesystem. > Good question. tcprules parsed your file without difficulty when I > tried it, so maybe there is a hidden control character in there. A > return character at the end of the line yields this error, for > example. unfortunately no ^M (or so) there. So I'll try to play w/ the code to add additional debugging messages... Bye.Olli.
Re: Queue limit question
At 10:32 PM Sunday 4/11/99, Matthew Harrell wrote: >: Above and beyond the standard reporting programs -qstat and -qread, I >: haven't heard of anything especially. The question is, how do you want to >: constrain users? >: >: Is it X message per day, X messages in the queue at any one time, X >: megabytes per day, X megabytes in the queue at any one time? Will you need >: to keep a history of what they have done? Will you want to differentiate >: between users such as any lists or system processes you're running? > >At the moment, I was thinking of X MB in the queue at any one time. Right. Well, there is nothing "out there" that I know of. You'll have to write stuff. Given that they submit almost everything from "some automated interfaces", you should be able to capture them fairly easily. You're problem is that qmail-qread doesn't give you enough information to determine the true origin of the email, you'll have to look inside each message to determine the uid and/or the source IP address. Relying on the sender address is of course, a very weak form of identification unless your automation processes generate that in an unforgeable way. Regards.
Re: qmail speed
>>>4 e-mail addresses would make for some small problems ... >>>have to split it up somewhat, I'd say. >> >>Incorrect. This is precisely how a "serious mailing-list" does it. Namely >>ezmlm. Admittedly via qmail-queue, but the queue insertion costs and >>sequences are the same. > >I didn't go to the bottom of recipient parsing in qmail-inject, >but putting 4 e-mail addresses on the command line is >obviously not possible. Making a file representing a message >with 4 recipients in Bcc for the sole purpose of catting it >to qmail-inject seems unreasonable. Using qmail-queue seems more >reasonable. Really? Why? Did you measure the difference? qmail-inject opens a pipe to qmail-queue - once per invocation. You're saying that one extra fork/exec for the insertion and delivery of 40K recipients is significant? I'd like to see the numbers on that rather than rely on a "seems more reasonable" analysis. By my reckoning the difference is, oh, 1 extra/fork exec in a pool of some 500,000 system calls of which at least 40,000 are opens and at least 40,000 are fsync calls and at least 80,000 are socket calls. I'd be very surprised if you could measure the difference above the noise. >>You miss the point entirely. A spammer can get better "performance" >>precisely because they don't need to worry about such things. A real list >>cannot - as you re-state. > >So why did I miss the point, then? Spammers get better >performance by implementing the shortcuts discussed, a serious >mailing-list can't use all of them, but can use some, which I >note. They're not shortcuts, they are a change in functional requirements. If the original poster can live with those changes, then he should purchase one of the spammer programs that are written solely to blast out a list and *nothing else*. As many people have repeatedly stated, qmail is a generalized MTA that is not as well adapted to offering those particular changes in functional requirements and I suspect it never can be. It may get more efficient at offering the current functions of course and that's what zeroseek is all about. Even then, the imposition of maintaining a queue such as that which qmail has to do means that it can never run at the same speed as a system without a queue such as a spam program. Regards.
RE: [Q] qmail speed "again"
We tried it but there were lots of funny interactions with BSD mail...for example it would add extra >'s at the end of addresses and cause lots of bounces. And another wierd thing was the interaction with the vacation program, also adding extra >'s and not working consistently in general. (Since then we have switched to Peter Samuel's version which works very nicely). I posted to this and other lists and eventually just wrote a oneliner that solved all these problems. Granted I never really figured out what they were exactly, but this worked for us: ella 28# more sendmail #!/bin/sh cat | /var/qmail/bin/predate /var/qmail/bin/qmail-inject [new mail arrives from Dave Sill] > qmail-aware SGI admins know this, and remove the sendmail binary and > relink it to qmail after upgrading. I didn't do the qmail...install it was already there when I got the system. And, it was my first IRIX upgrade...but this is exactly what I learned and resolved as I explained above. > You reinvented /var/qmail/bin/sendmail? Sounds like you didn't read > the installation instructions very carefully. Well if the one liner I wrote above is reinventing then I guess so :) But mostly I was just trying to satisfy a few users who insist on using the BSD mail client. Several qmail list experts (Harald/Mate) worked with me extensively and we ran outr of avenues, but I am still eternally grateful! Samuel Daffner Mills College ITS On Mon, 12 Apr 1999, Soffen, Matthew wrote: > Umm.. Why didn't you use /var/qmail/bin/sendmail ? > > > > -Original Message- > > From: Samuel Dries-Daffner [SMTP:[EMAIL PROTECTED]] > > Sent: Monday, April 12, 1999 12:19 PM > > To: Dave Sill > > Cc: [EMAIL PROTECTED] > > Subject:Re: [Q] qmail speed "again" > > > > > > > > On Mon, 12 Apr 1999, Dave Sill wrote: > > > > > Silver CHEN <[EMAIL PROTECTED]> wrote: > > > > > > > > The mail reason that I can't switch to qmail is that I'm NOT > > > >familiar with qmail in early days, so I chose sendmail. > > > > > > You can install qmail without removing/breaking sendmail, so you can > > > revert to sendmail easily. > > > > On our server (SGI Indy -- IRIX 6.5) this was mostly true, with one > > exception-- BSD mail users. > > > > We had a problem with a sendmail that was re-installed by default on > > our > > IRIX upgrades. ...because it seemed to be called by those users still > > using BSD mail on our system. Other users (like pine, IMAP, POP) had > > no > > problems. So we made a simple wrapper of sendmail that piped messages > > to > > qmail-inject. > > > > > > FWIW--- > > > > Samuel Daffner > > Mills College ITS >
Re: [Q] qmail speed "again"
Samuel Dries-Daffner <[EMAIL PROTECTED]> wrote: > >On Mon, 12 Apr 1999, Dave Sill wrote: > >> You can install qmail without removing/breaking sendmail, so you can >> revert to sendmail easily. > >On our server (SGI Indy -- IRIX 6.5) this was mostly true, with one >exception-- BSD mail users. > >We had a problem with a sendmail that was re-installed by default on our >IRIX upgrades. ...because it seemed to be called by those users still >using BSD mail on our system. No, IRIX upgrades/patches will always re-install sendmail because SGI considers it a necessary piece of the operating system. Most qmail-aware SGI admins know this, and remove the sendmail binary and relink it to qmail after upgrading. >Other users (like pine, IMAP, POP) had no >problems. So we made a simple wrapper of sendmail that piped messages to >qmail-inject. You reinvented /var/qmail/bin/sendmail? Sounds like you didn't read the installation instructions very carefully. -Dave
Re: [Q] qmail speed "again"
On Mon, 12 Apr 1999, Dave Sill wrote: > Silver CHEN <[EMAIL PROTECTED]> wrote: > > > > The mail reason that I can't switch to qmail is that I'm NOT > >familiar with qmail in early days, so I chose sendmail. > > You can install qmail without removing/breaking sendmail, so you can > revert to sendmail easily. On our server (SGI Indy -- IRIX 6.5) this was mostly true, with one exception-- BSD mail users. We had a problem with a sendmail that was re-installed by default on our IRIX upgrades. ...because it seemed to be called by those users still using BSD mail on our system. Other users (like pine, IMAP, POP) had no problems. So we made a simple wrapper of sendmail that piped messages to qmail-inject. FWIW--- Samuel Daffner Mills College ITS
Re: [Q] qmail speed "again"
On Mon, Apr 12, 1999 at 12:13:06PM -0400, Dave Sill wrote: > Peter van Dijk <[EMAIL PROTECTED]> wrote: > > > >The 'qmail for outgoing' claim is correct. The 'zmailer for incoming' > >claim is very ridiculous. > > See: > > http://www.ornl.gov/its/archives/mailing-lists/qmail/1997/08/msg01208.html > http://www.ornl.gov/its/archives/mailing-lists/qmail/1998/05/msg00660.html > > They may not be running it now, but they used to. I stand corrected. First time I checked there was no zmailer involved there :) Greetz, Peter -- | 'He broke my heart,| Peter van Dijk | I broke his neck' | [EMAIL PROTECTED] | nognixz - As the sun |Hardbeat@ircnet - #cistron/#linux.nl | | Hardbeat@undernet - #groningen/#kinkfm/#vdh |
Re: [Q] qmail speed "again"
Peter van Dijk <[EMAIL PROTECTED]> wrote: > >The 'qmail for outgoing' claim is correct. The 'zmailer for incoming' >claim is very ridiculous. See: http://www.ornl.gov/its/archives/mailing-lists/qmail/1997/08/msg01208.html http://www.ornl.gov/its/archives/mailing-lists/qmail/1998/05/msg00660.html They may not be running it now, but they used to. -Dave
How to change delivery search order?
Yes, this is the same setting up of Email on our big server. Things are mostly working, but we have a problem with how the server decides how to deliver. As it is, it checks for a user, and if there is, then delivers based on that. (and if the user has a .qmail file in their home dir) I'm running Fast forward, and there are mappings in there for users that exist. These mappings are supposed to override the users normal delivery, but they don't. How can I make it deliver to what's in the fast forward database over anything else? There's over 50,000 users on the system, so just throwing in a .qmail in the home dirs for each exception would be troublsum to program. Anyone have any ideas? Greg
Re: [Q] qmail speed "again"
On Mon, Apr 12, 1999 at 11:55:17AM -0400, Dave Sill wrote: > Hotmail, last time I checked, used qmail for outgoing mail, zmailer > for incoming mail. If it's slow and unreliable, it's not because it > uses qmail, it's because it's too busy or poorly run. If sendmail > would have been better than qmail+zmailer, they probably would have > used it. The 'qmail for outgoing' claim is correct. The 'zmailer for incoming' claim is very ridiculous. Until a couple of weeks ago (maybe even shorter) hotmail used a very nice SMTP agent of their own making. I don't know what it is they're using now, but it is quite broken: telnet mail.hotmail.com 25 Trying 209.1.112.253... Connected to mail.hotmail.com. Escape character is '^]'. 220-HotMail (NO UCE) ESMTP server ready at Mon Apr 12 09:01:20 1999 220 ESMTP spoken here EHLO attic.vuurwerk.nl an esmtp server that does not understand EHLO... Greetz, Peter -- | 'He broke my heart,| Peter van Dijk | I broke his neck' | [EMAIL PROTECTED] | nognixz - As the sun |Hardbeat@ircnet - #cistron/#linux.nl | | Hardbeat@undernet - #groningen/#kinkfm/#vdh |
Re: [Q] qmail speed "again"
Silver CHEN <[EMAIL PROTECTED]> wrote: > > The mail reason that I can't switch to qmail is that I'm NOT >familiar with qmail in early days, so I chose sendmail. You can install qmail without removing/breaking sendmail, so you can revert to sendmail easily. > I've read all the articles about the topic 'qmail speed'. Now I'm >wonder that if qmail can do this too? If the design spirit of qmail >can't afford such high-loading task in short time, then sendmail >takes the chance back. qmail was designed for higher performance than sendmail. The "qmail speed" thread was about a particular type of mass mailing that's much harder than sending the same message to a large list: in this case, the message was customized for each recipient. Instead of one message with 100,000 recipients, he was sending 100,000 different messages to one recipient each. > As I know, hotmail use qmail as its base(?) but hotmail is slow, slow, >and unreliable 'sometimes'. I don't know what will happen if hotmail >choose sendmail as its base now, but I'm curious on this topic. Hotmail, last time I checked, used qmail for outgoing mail, zmailer for incoming mail. If it's slow and unreliable, it's not because it uses qmail, it's because it's too busy or poorly run. If sendmail would have been better than qmail+zmailer, they probably would have used it. -Dave
Re: [Q] qmail speed "again"
"Fred Lindberg" <[EMAIL PROTECTED]> wrote: > >qmail will always be faster than sendmail [unless you send one message >to a large number of addresses on the same remote host]. No, qmail will usually win here, too, because sendmail serializes. Sendmail only wins when the message is huge. -Dave
Re: question on mail relay
+ olli <[EMAIL PROTECTED]>: | Sorry for a noise.I've the following problem: | /etc/tcp.smtp file as follows: [...] | as in FAQ I do: | cat /etc/tcp.smtp | /usr/local/tcpserver/bin/tcprules /etc/tcp.smtp.cdb |~/tcp.smtp.tmp Bad idea. The cdb file and the tmp file must be on the same filesystem. Your invocation would also have earned you a "Useless use of cat" award in comp.unix.shell; you can simplify to < /etc/tcp.smtp /usr/local/tcpserver/bin/tcprules /etc/tcp.smtp.cdb /etc/tcp.smtp.tmp | tcprules: fatal: unable to parse this line: | 192.168.0.1:allow,RELAYCLIENT=" " | | What could be wrong? Good question. tcprules parsed your file without difficulty when I tried it, so maybe there is a hidden control character in there. A return character at the end of the line yields this error, for example. | PS: I can make .cdb file by cdb itself Yes, but it's not a straightforward translation from the rules file. Better make tcprules work right. Russell has pointed out your more obvious error already, so I'll leave it at that. - Harald
Re: question on mail relay
> Hello. > > Sorry for a noise.I've the following problem: > /etc/tcp.smtp file as follows: > 192.168.0.1:allow,RELAYCLIENT=" " ^ Remove this space. Regardless of what tcprules is doing, you don't want it there. > tcprules: fatal: unable to parse this line: > 192.168.0.1:allow,RELAYCLIENT=" " > > What could be wrong? Hard to say. Dan calls die_bad() six times in tpcrules.c, and every one of them generates the same error. If he had included a parameter to die_bad() and printed it, one would be able to distinguish. -- -russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | There is good evidence 521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
question on mail relay
Hello. Sorry for a noise.I've the following problem: /etc/tcp.smtp file as follows: 192.168.0.1:allow,RELAYCLIENT=" " 192.168.0.2:allow,RELAYCLIENT=" " 192.168.0.4:allow,RELAYCLIENT=" " 192.168.0.5:allow,RELAYCLIENT=" " 192.168.0.6:allow,RELAYCLIENT=" " 192.168.0.7:allow,RELAYCLIENT=" " 192.168.0.8:allow,RELAYCLIENT=" " 192.168.0.9:allow,RELAYCLIENT=" " 192.168.0.10:allow,RELAYCLIENT=" " 192.168.0.25:allow,RELAYCLIENT=" " 192.168.4.120:allow,RELAYCLIENT=" " 127.:allow,RELAYCLIENT=" " as in FAQ I do: cat /etc/tcp.smtp | /usr/local/tcpserver/bin/tcprules /etc/tcp.smtp.cdb ~/tcp.smtp.tmp & I got the following answer: tcprules: fatal: unable to parse this line: 192.168.0.1:allow,RELAYCLIENT=" " What could be wrong? PS: I can make .cdb file by cdb itself (& I did) , but does it produce the same thing & why then tcprules fail? After I created .cdb file via cdb I commented out the following line from inetd.conf: smtp stream tcp nowait qmaild /usr/sbin/tcpd /var/qmail/bin/tcp-env /var/qmail/bin/qmail-smtpd & run the following script: #!/bin/sh killall -HUP inetd /usr/local/tcpserver/bin/tcpserver -R -x/etc/tcp.smtp.cdb -c100 -u599 -g598 0 smtp /var/qmail/bin/qmail-smtpd & After this when my user sends email to microsoft.com from 192.168.0.1 we see the following error: 553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1) The file rcpthosts is only 2 lines: localhost my.dns_host.name Well,I've read that in this situation rcpthosts is not used. Am I wrong? So - cdb & tcprules seem to use diffrent formats or I'm wrong in somth. else there? & if I'm not - what wrong w/ the linebelow: 192.168.0.1:allow,RELAYCLIENT=" " tcprules doesn't want to parse all strings in my /etc/tcp.smtp . Anyhow while compiling I got binaries w/o errrors. uname -a gives me: Linux my.dns_host.name 2.0.36 #1 ¿âÝ ¼Ðà 26 19:20:45 GMT+3 1999 i586 unknown VERSION file for tcpserver contains: ucspi-tcp 0.84 that's all. So could anyone tell me what's wrong? I'm tring to stop open mail relay (right now I've to make rcpthosts w/ commonly used domains in our company, so anyone there can use us as relay. :( ) Bye.Olli.
Re: cyclog vs. syslog (was: Queue limit question)
Dave Sill wrote/schrieb/scribsit: > Disadvantages: only logs messages sent to stdout, only logs messages > from local system You can use ucspi-tcp to reliably send log messages from one program's stdout to a cyclog on another host. Stefan
cyclog vs. syslog (was: Queue limit question)
[EMAIL PROTECTED] wrote: >What are the advantages/disadvantages of cyclog over syslog? Advantages: performance, automatic rotation, predetermined maximum size, ability to filter for unusual messages using "usually", no remote access and associated security problems, timestamps are more precise. Disadvantages: only logs messages sent to stdout, only logs messages from local system, doesn't chunk logs by day/week/etc--only by size, dates/times aren't human-readable without "tailocal", throws away oldest logs. -Dave
Re: qmail speed
On the qmail list [EMAIL PROTECTED] wrote: >At 01:38 PM Sunday 4/11/99, Lorens Kockum wrote: >> >>qmail-inject does not look at headers, does it > >Incorrect. qmail-inject is *the* program that does look at headers. How did >you deduce the above after reading the man page for qmail-inject? Obviously, my reading of that particular man page was lost in the mists of time :-( Fortunately, when you put recipients on the command line, the recipients in the headersare not taken into account, otherwise I would have sent quite q few unwanted mails... >>>Since the invocation happens just the once for the all recipients, there is >>>no advantage to using qmail-queue (and some disadvantages if you ask me). >> >>4 e-mail addresses would make for some small problems ... >>have to split it up somewhat, I'd say. > >Incorrect. This is precisely how a "serious mailing-list" does it. Namely >ezmlm. Admittedly via qmail-queue, but the queue insertion costs and >sequences are the same. I didn't go to the bottom of recipient parsing in qmail-inject, but putting 4 e-mail addresses on the command line is obviously not possible. Making a file representing a message with 4 recipients in Bcc for the sole purpose of catting it to qmail-inject seems unreasonable. Using qmail-queue seems more reasonable. >You miss the point entirely. A spammer can get better "performance" >precisely because they don't need to worry about such things. A real list >cannot - as you re-state. So why did I miss the point, then? Spammers get better performance by implementing the shortcuts discussed, a serious mailing-list can't use all of them, but can use some, which I note. My point was that a single low-cost machine dedicated to sending out one e-mail an hour to 200K recipients can afford to disregard the possibility of their machine failing ; one probably wouldn't care a jot about the risk of losing "mail", since nothing important would be lost; therefore the queue could very well be in RAM. Such a system would want to take into account errors during normal operation, but the risk for a hard crash would be small enough to probably warrant not recovering at all. "Sorry, you didn't get last hour's update because power went off for five consecutive hours and our UPS only managed 4 1/2 hours"... >>>FWIW. The best I've seen out of a single box Pentium with one or two high >>>speed spindles is around 100K per hour. The systems tend to run out of queue >>>disk I/O. (This of course is gross generalization as most people will >>>realise, but it gives a ballpark expectation for an unmodified qmail system). >> >>Therefore memory-based fs, yes. > >Nope. Memory-base fs don't tend to have high speed spindles I don't reckon. Neither do I. One or two high speed spindles => 100K an hour bottlenecked by disk I/O, but he wants better than 100K mess/hour, so get better disk I/O, right? Or was I also wrong in supposing a memory-based fs has better I/O performance than "one or two high speed spindles"? -- #include Lorens Kockum
adding a header to all e-mail
This must be a simple thing to do but I can't seem to find a good solution around it. I'd like to be able to add a header to all incoming e-mail (only remotely generated is necessary so it can be through qmail-smtpd). What is the simplest/cleanest way to do this? I am aware of the .qmail approach, but it seems like I'd have to do this for every domain. Is there a *global* .qmail-default, or can you force qmail-local to use a global qmail-command instead of the one in the recipient's home directory? I'd rather NOT modify any of qmail's stock distribution (either modifying qmail-local, for example, or renaming it and running something before it's actually called) if possible. Thanks, Tim
RE: SMTP Error...
Thanks for that - I got SMTP to respond now, but it will not find any of my users. I have all of my local domains listed, but it keeps coming back with: "Your message did not reach some or all of the intended recipients. Subject: test Sent: 4/12/99 6:07 AM The following recipient(s) could not be reached: Kees (E-mail) on 4/12/99 6:07 AM The recipient name is not recognized" I can check this user via POP3, and it finds the record just fine. I can send this user an email local and it works ok - what am I missing? -Original Message- From: Ramesh Panuganty [mailto:[EMAIL PROTECTED]] Sent: Monday, April 12, 1999 5:53 AM To: Jim Beam Cc: Qmail Mailing List Subject: RE: SMTP Error... Create a file called "smtproutes" in /var/qmail/control/ with entries like yourmachine:[IPaddress] yourmachine.fulldomain:[IPaddress] another file "me" in the above directory with entries like localhost yourmachine yourmachine.fulldomain Cheers, Ramesh | OK - I have been messing with this one all weekend... H E L P! | | I have just started looking at Qmail as an alternative to Sendmail, and | I cannot seem to get passed this one error. | | 421 unable to read controls (#4.3.0) | | This is what I see when I connect to the SMTP port running Qmail.. | | What am I doing wrong, or what do I not have configured? | | Thanks, | | James Beam
Re: how to turn of logging?
+ "Ramesh Panuganty" <[EMAIL PROTECTED]>: | Is there anyway I can turn of logging in qmail? If I comment out | "logger" in /etc/init.d/qmail, will any default loggin mechanism | come into action? If you do that, qmail-send will write its log entries on stdout. You can redirect that to /dev/null if you really don't want to see it. - Harald
RE: SMTP Error...
Create a file called "smtproutes" in /var/qmail/control/ with entries like yourmachine:[IPaddress] yourmachine.fulldomain:[IPaddress] another file "me" in the above directory with entries like localhost yourmachine yourmachine.fulldomain Cheers, Ramesh | OK - I have been messing with this one all weekend... H E L P! | | I have just started looking at Qmail as an alternative to Sendmail, and | I cannot seem to get passed this one error. | | 421 unable to read controls (#4.3.0) | | This is what I see when I connect to the SMTP port running Qmail.. | | What am I doing wrong, or what do I not have configured? | | Thanks, | | James Beam
SMTP Error...
OK - I have been messing with this one all weekend... H E L P! I have just started looking at Qmail as an alternative to Sendmail, and I cannot seem to get passed this one error. 421 unable to read controls (#4.3.0) This is what I see when I connect to the SMTP port running Qmail.. What am I doing wrong, or what do I not have configured? Thanks, James Beam PDQ/Entech
how to turn of logging?
Hi All, Is there anyway I can turn of logging in qmail? If I comment out "logger" in /etc/init.d/qmail, will any default loggin mechanism come into action? Thanks, Ramesh
qmail Digest 12 Apr 1999 10:00:00 -0000 Issue 608
qmail Digest 12 Apr 1999 10:00:00 - Issue 608
Topics (messages 24124 through 24158):
qmail speed
24124 by: [EMAIL PROTECTED] (Lorens Kockum)
24125 by: Harald Hanche-Olsen <[EMAIL PROTECTED]>
24126 by: Richard Letts <[EMAIL PROTECTED]>
24138 by: Mark Delany <[EMAIL PROTECTED]>
24154 by: Bruce Guenter <[EMAIL PROTECTED]>
24155 by: "Peter C. Norton" <[EMAIL PROTECTED]>
24156 by: Bruce Guenter <[EMAIL PROTECTED]>
procmail problem
24127 by: "Adam D. McKenna" <[EMAIL PROTECTED]>
24128 by: Harald Hanche-Olsen <[EMAIL PROTECTED]>
24129 by: Richard Letts <[EMAIL PROTECTED]>
24130 by: "Adam D. McKenna" <[EMAIL PROTECTED]>
Qmail IMAP4 Setup Instruction
24131 by: Greg Owen {gowen} <[EMAIL PROTECTED]>
24132 by: Juan Carlos Castro y Castro <[EMAIL PROTECTED]>
24134 by: "Postmaster" <[EMAIL PROTECTED]>
24135 by: Eric Ess <[EMAIL PROTECTED]>
24137 by: "Greg Owen {gowen}" <[EMAIL PROTECTED]>
24150 by: Todd at NM Technet <[EMAIL PROTECTED]>
Queue limit question
24133 by: Matthew Harrell <[EMAIL PROTECTED]>
24136 by: Matthew Harrell <[EMAIL PROTECTED]>
24139 by: Mark Delany <[EMAIL PROTECTED]>
24140 by: Matthew Harrell <[EMAIL PROTECTED]>
24141 by: [EMAIL PROTECTED]
24142 by: "Adam D. McKenna" <[EMAIL PROTECTED]>
24143 by: [EMAIL PROTECTED]
24144 by: "Fred Lindberg" <[EMAIL PROTECTED]>
24149 by: Mark Delany <[EMAIL PROTECTED]>
24152 by: Russell Nelson <[EMAIL PROTECTED]>
24153 by: Matthew Harrell <[EMAIL PROTECTED]>
mailman mail list and rcpthosts
24145 by: Bob Ruddy <[EMAIL PROTECTED]>
24146 by: Chris Johnson <[EMAIL PROTECTED]>
24147 by: Russ Allbery <[EMAIL PROTECTED]>
maildir setup.
24148 by: Andy Walden <[EMAIL PROTECTED]>
Qmail, IMAP, POP
24151 by: "Brad (Senior Systems Administrator - Americanisp, LLC.)"
<[EMAIL PROTECTED]>
adding a header to all e-mail
24157 by: Tim Tsai <[EMAIL PROTECTED]>
24158 by: Anand Buddhdev <[EMAIL PROTECTED]>
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To bug my human owner, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
--
On the qmail list [EMAIL PROTECTED] wrote:
>>On Fri, Apr 09, 1999 at 05:01:48PM -, Lorens Kockum wrote:
>>> Just for the sake of discussion, what would be the best way?
>
>Use qmail-inject with multiple Bcc: recipients as suggested a few days ago.
qmail-inject does not look at headers, does it, so Bcc or not is
of no concern, is it?
Say you're running a list with 2 subscribers, you cat the
mail to qmail-inject with as many recipients as possible, no?
>Since the invocation happens just the once for the all recipients, there is
>no advantage to using qmail-queue (and some disadvantages if you ask me).
4 e-mail addresses would make for some small problems ...
have to split it up somewhat, I'd say.
>On the matter of comparison to spammers,
I'd prefer "serious mailing-list" ...
>here's what you need to do to get
>comparable results:
>
>1. Turn off all disk I/O
Me too.
>2. Ignore the SMTP transaction
?
>3. Don't care if a recipient sees the mail zero or more times
No good for a mailing-list
>4. Ignore system and network failures
Hmm... Disregard the possibility of your system failing, but a
serious mailing-list can't ignore remote systems failing.
>If you want to go part way down this path I suggest putting /var/qmail/queue
>on a memory-based file system rather than twiddling fsync() calls in the code.
Sounds good.
>FWIW. The best I've seen out of a single box Pentium with one or two high
>speed spindles is around 100K per hour. The systems tend to run out of queue
>disk I/O. (This of course is gross generalization as most people will
>realise, but it gives a ballpark expectation for an unmodified qmail system).
Therefore memory-based fs, yes.
>>> I'm envisioning using xargs to distribute the rcpt addresses to
>
>No point. Put the recipients in bcc: headers and only invoke qmail-inject
>the once.
So if there is a Bcc: header in the mail catted to qmail-inject,
it will be used and discarded, right?
--
#include Lorens Kockum
+ [EMAIL PROTECTED] (Lorens Kockum):
| On the qmail list [EMAIL PROTECTED] wrote:
| >>On Fri, Apr 09, 1999 at 05:01:48PM -, Lorens Kockum wrote:
| >>> Just for the sake of discussion, what would be the best way?
| >
| >Use qmail-inject with multiple Bcc: recipients as suggested a few days ago.
|
| qmail-inject does not look at headers, does it,
Yes it does, more than any other program in the qmail suite.
| so Bcc or not is of no concern, is it?
Only in that supplying address
Re: qmail speed
On Mon, Apr 12, 1999 at 01:04:50AM -0400, Peter C. Norton wrote: > > On the other hand, if your recipients list is larger than can fit on a > > single command line, it would be better to go the Bcc header field route > > to put all the recipients in. > That's what xargs is for. Unless you want to have exactly one message for all the recipients. Having said that, using xargs would probably still give you at least 1000 recipients per message (assuming a conservative 32K space for command line arguments and ~30 character email addresses) which is lots for most purposes. -- Bruce Guenter, QCC Communications Corp. EMail: [EMAIL PROTECTED] Phone: (306)249-0220 WWW: http://www.qcc.sk.ca/~bguenter/
Re: qmail speed
On Sun, Apr 11, 1999 at 10:49:22PM -0600, Bruce Guenter wrote: > On the other hand, if your recipients list is larger than can fit on a > single command line, it would be better to go the Bcc header field route > to put all the recipients in. That's what xargs is for. -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one.
Re: adding a header to all e-mail
On Mon, Apr 12, 1999 at 03:01:42AM -0500, Tim Tsai wrote: Look at your qmail-start line. It goes something like: qmail-start ./Mailbox splogger qmail The part "./Mailbox" is a default instruction to follow for any user who does not have a .qmail file. You could replace it with a small script that inserts the header of your choice. However, that default instruction will be overridden by a user if they create their own .qmail files. Instead of using your own script to insert the header, you might want to investigate procmail or maildrop. These are mail delivery agents which come with tools to insert headers. An example using maildrop is: qmail-start '|preline reformail -A"X-Header: my header" | \ maildrop -f "$SENDER"' splogger qmail This one uses the reformail program from the maildrop package to add a header, and then passes the message to maildrop to actually deliver it. If you really want to add a header to *all* email regardless of user's own .qmail files, you'll have to use the the "fixup" method as described in FAQ 5.5 > This must be a simple thing to do but I can't seem to find a good solution > around it. > > I'd like to be able to add a header to all incoming e-mail (only remotely > generated is necessary so it can be through qmail-smtpd). What is the > simplest/cleanest way to do this? > > I am aware of the .qmail approach, but it seems like I'd have to do this > for every domain. Is there a *global* .qmail-default, or can you force > qmail-local to use a global qmail-command instead of the one in the > recipient's home directory? -- System Administrator See complete headers for address, homepage and phone numbers
Re: qmail speed
On Sun, Apr 11, 1999 at 04:05:54PM +0200, Harald Hanche-Olsen wrote: > | so Bcc or not is of no concern, is it? > > Only in that supplying addresses in a Bcc field requires qmail-inject > to parse that Bcc field; supplying recpipients on the command line > ought to be slightly faster. Check the -a argument to qmail-inject. On the other hand, if your recipients list is larger than can fit on a single command line, it would be better to go the Bcc header field route to put all the recipients in. -- Bruce Guenter, QCC Communications Corp. EMail: [EMAIL PROTECTED] Phone: (306)249-0220 WWW: http://www.qcc.sk.ca/~bguenter/
