Re: Mac OS X
On Fri, 21 May 1999, Joergen Persson wrote: > Hi > Does anyone have experience from Qmail under Mac OS X? It ought to work but > I thought I better ask... I would look carefully at the filesystem; in particular does MacOS X allow you to determine the inode number of a file? I'm not familiar with the filesystem under macosX but qmail-queue makes soe assumptions about how fs works. RjL == The problems of the world|| Fax: +44 870 0521198 can't be solved by fixing|| Email: [EMAIL PROTECTED] the working -- C. Daniluk|| Phone: +44 385 275 394
Re: Qmail+sendmail
On Thu, 3 Jun 1999, Hotdog wrote: > Hi, > I am using qmail 1.03 and sendmail 8.9.1 at the same server. Qmail used for receive > inbound letters and using sendmail -bs send our mailing list. > I had to say sometime sendmail is better than qmail,for example, > while talk to qmail, > rcpt to: [EMAIL PROTECTED] > rcpt to: [EMAIL PROTECTED] > rcpt to: [EMAIL PROTECTED] > (host 'hostN.com' is not a local host) > > then qmail will crack this letter to 3 letters,first [EMAIL PROTECTED],then > [EMAIL PROTECTED],and then [EMAIL PROTECTED] to send it . But sendmail not, it > will crack this letter to only two letters: [EMAIL PROTECTED],[EMAIL PROTECTED] > and [EMAIL PROTECTED] This is the reason I am using sendmail but not qmail > to send outbound letters. In testing I've done qmail may initiall appear inefficient, but in reality delivers mail faster than sendmail. this is due to the latency of the Internet connections to remote hosts -- in parallel sessions to the same machine I overcome this latency. > But the problem is, if I let sendmail to be a deamon(-bd),sendmail will > try to listen port 25(and now qmail listen ? ),and if I not, sendmail > cannot check the mail queue to delivert queued letters.(manual sendmail > -q &? :( ) > > Then how can I do? sendmail -q15m will start sendmail and leave it running processing the outbound queue every 15 minutes. read the manual to see how to specify other run-intervals. RjL == The problems of the world|| Fax: +44 870 0521198 can't be solved by fixing|| Email: [EMAIL PROTECTED] the working -- C. Daniluk|| Phone: +44 385 275 394
Re: Mass Mailign with Qmail vs. Sendmail
On Fri, 4 Jun 1999, Mylo wrote: > That's sounding happy, but how do you limit the number of qmail-remote's that are > gonna get spawned. Aren't you running the risk of thousands, or should I say > millions of them starting at once. maintain a list of current running children. when one dies start a new one. if is dies delivery failed pass that message off to qmail-queue before starting another qmail-remote. with a little twiddling with perl one would optimise the deliveries so identical message to same remote hosts use the multiple rcpt featuires of qmail-remote, one could also monitor the maximum per-host concurrency and prevent overloading of one host. RjL == The problems of the world|| Fax: +44 870 0521198 can't be solved by fixing|| Email: [EMAIL PROTECTED] the working -- C. Daniluk|| Phone: +44 385 275 394
RE: Secondary MX Delivery Problems (Returns)
On Sat, 26 Jun 1999, Karl Lellman wrote:
> Richard,
>
> Thanks for that info working on the theory that I've never ever modified
> qmail source before, can you explain which file I need to change and
> recompile and also whether this is an existing line that I'm changing or a
> new one that I'm adding (I know I sound pretty simple here, but I just want
> to get it right the first time)?
I'm afraid my comments were particulary carefully phrased so that if you
could find the routine you would know how to chnage it. I'm concerned
about suggesting you apply 'hack's such as this to your qmail installation
without first testing them. I don't have time to test them here, and if
they don't work I'm concerned that you won't be able to test them at your
end, forcing me into testing the changes here. I don't have time to test
the changes here. really. I'm moving continents shortly.
so once again, you modify the routine smtp() near the top of it changing
one line to return if the greeting message fails instead of dying.
I wrote:
> if (smtpcode() != 220) { close(&smtpto); return; };
>
> near the top should probably do the trick.
the alternative is to install qmail on your firewall as an
application-layer proxy. this is by far the best engineering solution
RjL
==
The problems of the world|| Fax: +44 870 0521198
can't be solved by fixing|| Email: [EMAIL PROTECTED]
the working -- C. Daniluk|| Phone: +44 385 275 394
Re: maildir format delivery problems?
On Wed, 30 Jun 1999, David Harris wrote: > I've been talking to Mark Crispin about the Maildir format and he as brought > up what really seems to be a valid concern to me. > > He says that Maildir is unsuitable for large servers because the filesytems > serialize creation and deletion of files in a single file system, because > the inode and free block tables have to be manipulated. Thus the file > creation part of Maildir drivery ends up being serialized and you spend all > your time in the filesystem. He states problems with servers processing more > than a few hundred messages per second (300+ or so). This is might be a bottlneck true if one were using the unix file system. At work we use Solaris' disksuite to make the file system 'logging' this boosts the performance of the system considerably. When XFS is availabale for linux there will be a considerably improved filestystem available there. RjL
Re: Qmail stops working
On Thu, 1 Jul 1999, Dave Sill wrote: > Doug Lumpkin <[EMAIL PROTECTED]> wrote: > > >Qmail seems to continue to run (i.e. qmail-smtpd and qmail-send are > >both running) > > qmail-smtpd should only be running when there's an active incoming > SMTP seesion. I run qmail-smtpd off supervise+tcpserver, and I've observed the problem on this machine where after an indefinate number of deliveries qmail-smtpd fails to spawn qmail-queue and so one connects to the smtp server but don't get a greeting back from qmail-smtpd the 'fix' is to stop supervise and restart it. -> the operating system isn't releasing some sort of resource when processes die and supervise is getting all stuck. I tried tracing supervise and the spawned processes, but stopeed after the problem wasn't reproducable. -> perhaps a complier/optimiser bug? It doesn't happen often enough on this machine (linux kernel 2.0.35)+libc1 for me to be able to reproduce it. it soesn't happen at all on the machines at work as far as I can see (solaris2.7/2.5.1). RjL == The problems of the world|| Fax: +44 870 0521198 can't be solved by fixing|| Email: [EMAIL PROTECTED] the working -- C. Daniluk|| Phone: +44 385 275 394
Re: Howto
On Fri, 2 Jul 1999, Scott D. Yelich wrote: > Ok, so we've beaten the dead horse with the fact that MX records can't > be CNAMES... so why does bind allow this? Go figure. for years bind allowed '_' in domain names. at one version they 'fixed' this and thousands of zone files around the world had to be fixed. Who is to say at some point in the future the server won't implement the checking. I guess bind doesn't check for this because it would be quite an expensive check to perform, given MX resords are cnames in a zone file don't have to refer to other entries in the same zone file. you could end up by performing a couple of thousand DNS queries every time a zone file were loaded in order to check this. Richard
Re: Howto
On Fri, 2 Jul 1999, Richard Letts wrote: > for years bind allowed '_' in domain names. at one version they 'fixed' > this and thousands of zone files around the world had to be fixed. Who is > to say at some point in the future the server won't implement the > checking. > > I guess bind doesn't check for this because it would be quite an expensive > check to perform, given MX resords are cnames in a zone file don't have to > refer to other entries in the same zone file. you could end up by > performing a couple of thousand DNS queries every time a zone file were > loaded in order to check this. urgh my fault for posting as soon as I come home from work. the last paragraph should have read: Since MX OR CNAME RECORDS in a zone don't have to refer to other entries in the same zone: you might end up by performing a couple of thousand DNS queries every time a zone file were loaded in order to check this. I know CNAME!=MX records.
Re: Qmail stops working
On Sat, 3 Jul 1999, Doug Lumpkin wrote: > I'm not sure what else it might be though. All other services run just > fine before, during and after the problem. It was a clean install of > Redhat 6.0 a little over two weeks ago and once the qmail is stopped and > restarted the problem disappears. You take a ps aux and none of the > qmail-daemons have died, there is just no response to anything sent to > port 25. If any one else has any suggestions, I'd be glad to listen :-) simple things first... if qmail-smptd stops working then the problem is either with qmail-smtpd or qmail-queue. qmail-queue writes the message in the queue and tells qmail-send that there is something new to look for. it doesn't complain when it cannot do this. I am seing the same problem under redhat linux kernel2.0.35, supervise+tcpserver, kernel2.0.35. this seems to me that there is some sort of resource not being freed by kernel when one of tcpserver's processes die, and perhaps its children have run out of (say) filedescriptors next time it happens I'll try stracing tcpserver and seeing what happens. Richard
Re: Qmail stops working
On Sat, 3 Jul 1999, Robbie Walker wrote: > Doug, > > This is a stumper. The lack of responses means "I don't know what's going > on here. I'm not going to speculate!" > > There is (most likely!!!) an obvious solution, but it's not apparent to me. > > Exactly what OS are you running? How often does the hang occur? When the > hang occurs, can you kill -ALRM qmail-send or kill -TERM qmail-send? (You > said you killed it, right? kill -9 or what?) What happens if you kill -9 > qmail-smtpd instead of qmail-send? > how I start tcpserver: (all one line) /usr/local/bin/supervise /var/lock/smptd /usr/local/bin/tcpserver -v -u 7791 -g 2108 -c 400 -R 0 smtp /usr/sbin/tcpcontrol /etc/smtp.cdb /var/qmail/bin/qmail-smtpd 2>&1 | /var/qmail/bin/splogger smtpd & I've finally had qmail-smtpd stop working on me, and I've done some straces. when tcpcontrol writes its log message to #2 it gets a SIGPIPE and aborts. Killing tcpserver didn't recusitate inbound SMTP connections. I tested this hypothesis by replacing the tcpserver with a shell script: --- #!/bin/sh exec /usr/local/bin/tcpserver.true $* 2>/tmp/straceout --- Inbound tcp connections now work again... if splogger dies it won't get restarted, all of the processes ignore the fact they can't write logging information, except tcpcontrol and so things appear to be working. why splogger died is a mystery I'll look into next. For now, I'd suggest looking at using cyclog instead regards, Richard
Re: does pine use qmail-inject?
On Mon, 12 Jul 1999, Robert Varga wrote: > > I tried to install a wrapper around qmail-inject... > > It had a call to id, with the output redirected to a file > It also had an echo writing to stdout in it.. I use qmail's sendmail replacement: sendmail-path=/var/qmail/bin/sendmail -oem -t -oi no QMAIL* variables set. pine 4.10 allows me to set any/all of the headers I'd wish to (including allowing me to edit the From: and automatically switching between roles. RjL == The problems of the world|| Fax: +44 870 0521198 can't be solved by fixing|| Email: [EMAIL PROTECTED] the working -- C. Daniluk|| Phone: +44 385 275 394
Re: does pine use qmail-inject?
On Mon, 12 Jul 1999, Robert Varga wrote: > That is exactly what I want to override... > > I want to do address rewriting for my users the same way it can be done > with the generics table in sendmail. That is, I want to ensure that my > users do not try to send mail in someone else's name. you're on a hiding to nothing. as long as they have any form of access to SMTP they can forge mail from whoever they like. you need to look at enforcing the use of cryptographic sugnatures.
Re: FW: qmail eats up my memory
On Tue, 2 Feb 1999, Sam wrote: > What kind of a stupid compiler would let this go by? Different > prototypes, you should get at least a warning. What prototypes? Richard - #ifndef STRALLOC_H #define STRALLOC_H #include "gen_alloc.h" GEN_ALLOC_typedef(stralloc,char,s,len,a) extern int stralloc_ready(); extern int stralloc_readyplus(); extern int stralloc_copy(); extern int stralloc_cat(); extern int stralloc_copys(); extern int stralloc_cats(); extern int stralloc_copyb(); extern int stralloc_catb(); extern int stralloc_append(); /* beware: this takes a pointer to 1 char */ extern int stralloc_starts(); #define stralloc_0(sa) stralloc_append(sa,"") #endif
Re: Am I being exceedingly silly?
On Thu, 11 Feb 1999, Eric Dahnke wrote: > If his machine is on a home network behind a dial-up conection what the > hell does it matter. given the number of hacking attempts I see against this machine when I'm online, and the ammount of mail some people try a and relay though me yes, it does matter! Richard
Re: On demand?
On Sat, 13 Feb 1999, Peter Gradwell wrote: > Second to that, perhaps you could make them primary MX, so that mail is > delivered directly to them if poss, but on fall back, it comes to you, > and then you dleiver it using the above scenario. in general this is bad idea: the lowest valued MX should be one with a high degree of reliability and connectivity. if you're trying to deliver to a machine which is intermittantly connected then you get exponential back-of on elivery attempts by some hosts on the Internet, resulting in the mail possibly never being delviered (and complaints from the customer "it's their setup") Richard
Re: On demand?
On Sat, 13 Feb 1999, Peter van Dijk wrote: > Err.. this is _very_ common practice, actually. I'm on a fixed-IP > dialup, but I'm my own primary MX nonetheless. Any mailhost failing to > deliver to a secondary MX is Very Broken(tm). Can you name one MTA which > is that stupid? the secondary MX Richard
Re: On demand?
On Sat, 13 Feb 1999, Peter van Dijk wrote: > On Sat, Feb 13, 1999 at 02:35:10PM +0000, Richard Letts wrote: > > On Sat, 13 Feb 1999, Peter van Dijk wrote: > > > > > Err.. this is _very_ common practice, actually. I'm on a fixed-IP > > > dialup, but I'm my own primary MX nonetheless. Any mailhost failing to > > > deliver to a secondary MX is Very Broken(tm). Can you name one MTA which > > > is that stupid? > > > > the secondary MX > > Err... come again? the secondary MX should not deliver to itself if it's the best preference reachable MTA. > Ok.. let me rephrase my question: do you know one MTA which is so stupid that it will > not deliver to a secondary MX if the primary MX is down? no. however the seocndary MX will (unless configured specially) exponentially backoff delivery attempts to the primary MX. If you're going to go to that effort (of specially configuring it) you might as well go the extra step and set it as the primary MX and configure it to avoid the DNS altogether. This benefits other sites, since they'll not waste time (and concurrency remotes) trying to connect to a system which is disconnected most of the time. the downside is an extra delviery delay whilst mail is relayed though the secondary MX, but given most dialup nodes (in the Uk atleast) are disconnected >50% of the time most of the inbound mail will do this anyway. Richard
Re: System w/o /etc/passwd
On Fri, 19 Feb 1999, Paul Gregg wrote: > In article <[EMAIL PROTECTED]> you wrote: > > On Wed, 20 Jan 1999, Robert Adams wrote: > > >> user on the system. Anyone know of a way to get around this? Say, to tell > >> qmail to drop all mail to something like /mail/u/s/username? > > > I don't believe qmail can deliver to hashed spools like this by default. > > I've just written a delivery script to deliver to hashed spools because I > needed it (gonna be *many* users). > > I nearly got it working with virtualdomains and users/assign with 26*26 > entries, but it ment that I needed a virtualhosts entry for every > virtuall domain and each user was going to have one so it was not > practical and thus I wrote my own script as ~alias/.qmail-default. I think it can if you use the qmail-users mechanism NAME qmail-users - assign mail addresses to users OVERVIEW The file /var/qmail/users/assign assigns addresses to users. For example, =joe.shmoe:joe:503:78:/home/joe::: says that mail for joe.shmoe should be delivered to user joe, with uid 503 and gid 78, as specified by /home/joe/.qmail. Assignments fed to qmail-newu will be used by qmail-lspawn to control qmail-local's deliveries. See qmail-newu(8). A change to /var/qmail/users/assign will have no effect until qmail-newu is run. ..snip... =local:user:uid:gid:homedir:dash:ext: Here local is an address; user, uid, and gid are the account name, uid, and gid of the user in charge of local; and messages to local will be controlled by home- dir/.qmaildashext. ...snip... so i would expect running the file though a little perl script which replaces homedir with the hased spool directory will work (assuming the user has permissions to their hashed spool directory.) or have I missed the point of the question? Richard
Re: SMTP proxies for Windows
On Wed, 3 Mar 1999, Roman V. Isaev wrote: > BTW, correct me if I'm wrong, but I never saw any good SMTP > authentication schemes -- all of them send the password in clear :( > Also, it's quite possible that users will send their passwords to > wrong servers... this means passwords must be mangled with MD5 or > something like that... wouldn't yu kow it the day after I delete the internet-draft off my had disk someone could make use of it. hopefully there;s an internet draft something like *overall-srap-* which is a draft for a simple roaming acess protocol written by someone at the ISP I use. they have windows and perl agents that run locally. and is intended to authneitcate systems rather than users. (ie this laptop has a valid demon account) otoh some ISPS, like freeserve.co.uk, automatically re-direct SMTP to their relays regardless of the actions of the client neatly avoiding the problems of reconfiguring the SMTP destination between the campus network and the ISP when mobile. (I don't bother to offer a dial-in service at work. pay-for ISPs will provide it for $100/user/year and free ones for nothing (they get 17% of the call charges whilst users are connected) ) The problems of the world can't be solved by fixing the working C. Daniluk
Re: migrating sendmail to qmail
On Mon, 8 Mar 1999, Francisco Yepes Candel wrote: > 3. run "sendmail -q" to force the delivery of messages that are still in > the sendmail queue if you start sendmail with the -qxx parameter but not -bd then it will sit there processing the queue every xx hours/minutes etc until the queue is empty. once it is empty to can kill the process permenatly Richard
Re: I couldn't find a mail exchanger...
On Tue, 9 Mar 1999, Czeh Istvan wrote: > % nslookup foo1.bar.com > Server: localhost > Address: 127.0.0.1 > > Non-authoritative answer: > Name:foo1.bar.com > Address: 10.10.10.10 > Aliases: foo.bar.com $ to doughnuts foo1.bar.com has something like: foo1.bar.comIN CNAME foo.bar.com. IN A10.10.10.10 which isn't allowed. qmail will problalbly follow the CNAME to foo.bar.com which then doesn't have an A record? richard The problems of the world can't be solved by fixing the working C. Daniluk
Re: qmail bandwidth usage versus other MTAs
On Wed, 13 Jan 1999, Dax Kelson wrote: > > Has anyone (Dan?) done real-world bandwidth measurements of how qmail > compares bandwidth wise to sendmail/zmailer/exim/postfix? > > A common complaint I hear is "qmail would use way more bandwidth, then XXX > MTA". > > It would be nice to point them at some number to take a look. practically the only time this is true is where the other maiolers compress several recipients of a message into one transfer. assuming most messages are about 4k and a recipient is <80 bytes then another mailer would save you about 4000 bytes of transferred data per additional recipient at a remote site (for each additional recipeint) <<< MAIL FROM: >>> 250 OK (plus greeting) >>> 220 illuin.demon.co.uk ESMTP note, this speedup only occurs where you have multiple recipients at a site; for most lists I'm member of a site typically only have one member on the list anyway and the difference is negligible. In my experience network latency doesn't affect mail thoughput half as much as: - disk IO (moving to a logging filesystem is a gret improvement) - memory footprint (less swapping, see above) the bottleneck will be on the smtp-sender, and again in the scale of things email is a really low volume acitivity in comparison to (say) web browsing. IF network latency (as opposed to bandwidth) is a problem then increasing remoteconcurrency gets over this. Richard
Re: dot-qmail security
On Sun, 14 Mar 1999, Joel Eriksson wrote: > Is it possible to restrict dot-qmail capabilities for some users and > allow it for others. I have not found any info on this in the FAQ / > README / etc. > > The thing I'm worried about is the feature of pipe'ing the message to a > command. > > If there is no standard way of doing it, I'll just hack the code of > qmail-local a bit, but maybe some of you know of a better way? sorry for the late reply, but the simplet answer is to modify PATH before qmail starts so a different 'sh' is before /bin/sh in the PATH and then add the checking to the replacement 'sh'. RjL
Important Mail From: (was Re: Melissa Virus)
On Mon, 29 Mar 1999, Mark E Drummond wrote: > Here we have a serious problem folks. Sendmail had a "fix" out for > Melissa very shortly after it came out, and we are sitting pretty. I > made a big push here to move our org to qmail because qmail seemed to be > way superior. Now I am really ticked by my inability to write/use simple > rulesets to solve this problem. laughs so you want to randomly reject mail which contains a subject of Important mail from something ??? it's hardly a sensible fix, really now is it?? Richard
Re: Melissa Virus
On Tue, 30 Mar 1999, Paul Farber wrote: > BZZT... but joe blow can't delete SYSTEM FILES, or any file the he does > not own. Log on a a LUSER and try rm -rf /etc see what gets deleted. Not > a darn thing. Same for /bin /sbin etc etc etc. funny, that doesn't work on my windows NT system when I logon as a LUSER either. RjL
Re: Melissa Virus
On Tue, 30 Mar 1999, Paul Farber wrote: > It IS a MS problem, they should not allow any indescriminate user to run > format or del *.* . IF you don't want a child to shoot themselves, don't > give them a gun to play with. ONE moment!!! you're comparing UNIX with win95/WIN3.1. I can assure you that when you login on my NT desktop machine as an ordinary user you can't just format the disk. > UNIX/Linux has the ability to say.. "Hey, you can't do that!" with a > simple feature like file permissions and file ownership. Why hasn't MS > followed suit with these basic security precaustions? Half the viruses in > the world would become obsolete with this one patch. they have, it's known as windowsNT... surely you've heard of it? I'm interested in discussions about how I can plug a proper anti-virus products into qmail. I have no interest in OS bashing like I'm seeing on this list at the moment. RjL
Re: Melissa Virus
On Tue, 30 Mar 1999, Paul Farber wrote: > You SHOULD have to type into a special "admin" account to install/remove a > program. Single user or not. You cannot make it any "righter" by saying > a single user is only hurting himself. It's just a bad policy/secruity > measure to alway log in as root, but MS seems not to care, let the user, > or IS or tech support figure out what go changed. funnily enough I have to login on my windowsNT machine as 'administrator' to install/remove a program. when I login as ais007 I can't ... > Windows already supports user profiles, why not extend that into a super > user that you must change to to modify the system? it does richard
Re: Melissa Virus
On Tue, 30 Mar 1999, Adam D. McKenna wrote: > From: Richard Letts <[EMAIL PROTECTED]> > > > : > Windows already supports user profiles, why not extend that into a super > : > user that you must change to to modify the system? > : it does > > It does, IF you have set up NT properly. If your system partition is on a > FAT drive, for instance, you have NO file security in NT. Same if you have > converted your FAT partition to NTFS. (system file security is not set at > this time). please! surely one would not run linux using UMSDOS if one were interested in security? I use a disk image built for use in a student lab on the NT machine in my ofice at work. most unixes don't ship secure out of the box, why should anything else? > Also, as long as a program doesn't try to modify something besides > HKEY_CURRENT_USER or write somewhere it's not allowed to, then WinNT has > no problem installing it. hey, I can install IRC into my filestore under a UNIX operating system as long as it doesn't try to write somewhere it's not allowed to. Richard
Re: AOL Cname lookup failure???
On Mon, 5 Apr 1999, Aaron L. Meehan wrote: > Well I say one thing here: it would be nice if AOL's TTL for the zone > was a bit higher. An hour seems a bit low and not net-friendly since > there are so many MX lookups, etc, for aol.com. Am I being > unreasonable or just highly pedantic? :) I have a mind to gather some > stats.. given the few numbers of packets required to obtain the information in comparison to the number required to transfer mail I'd not worry about it myself. I use TTL values down to <5 minutes for some names in the zones I'm responsible for. of course I normally only expect people on my campus to be using those and we're about to change them to something else. RjL
Re: QMTP suggestion
On Tue, 6 Apr 1999, Peter C. Norton wrote: > On Tue, Apr 06, 1999 at 06:31:03PM -0500, Chris Garrigues wrote: > > > > netstat -a |fgrep '*:qmtp' > > > > or the low-level C equivalent. > > I'm not concerned with this. I'm concerned with Fred's proposal > relying on the status of the remote smtp and qmtp server. If I'm > "local" and someone else is "remote" and remote's qmtp service is > down, but remote's smtp server is still advertising qmtp then I > shouldn't have my queue grow because of it. There should be some I think Chris' point was the remote SMTP server monitors the state of the remote qmtp socket/listener on itself. if there is something listening on the QMTP port isn't it fairly reasonable for qmail-smtpd to [configureabley] assume it's qmail-qmtpd ? Richard
Re: maildirserial -> ccMail Link fails
On 7 Apr 1999, Dirk Vleugels wrote: > > Hello, > > I deliver mails from a Maildir to a dial customer via > serialmail-0.72. The customer is runninc ccMail (don't know which > version), quit yields: "221 ccMail Link to SMTP closing connection". > The problem seems to be that the DATA submission end can't be detected > on the ccMail side (for certain mails): which version of ccMail link to SMTP? I found it so bad I wrote my own... earlier versions use FTP software's SMTP listener, later versions Lotus' own I think you can find a zip file of the source-code & binaries on ftp.salford.ac.uk if you want to use them feel free. I no-longer use cc:mail (and have also resigned from Salford to move to Austin, Texas) so have no interest in maintaining this. if it breaks you'll have the source. Richard
Re: Mail Message Replication.
On Wed, 7 Apr 1999, R Aldridge wrote: > Guys, > > I'm considering building a replicated mail service. If the primary goes > down for any reason (software or hardware), I need to be able to switch > over to the backup service, simply by changing the MX. Minimal mail > should therefore be lost or bounced and customers will not > inconvenienced when we try to fix a disk or whatever. Is there any > software already which will allow this to be done. I have had a quick > scan at the qmail archives, but that didn't really turn anything up. The > main issues are really "how to replicate imcoming messages" and "how to > replicate POP3 transactions", though I'm sure it's a bit more involved > than that. replicate at the filestore level, rather than the protocol level using something that so clustering: eg Two large NetWare servers running Netware clustering and NFS? You then have multiple pop-servers pointing at a different server over NFS. as they (or qmail) changes the filestore the chnages are replicated to the other servers. A couple of 1TB Netware servers should be able to store as much data as you require... RjL
Re: Is *anybody* using XTND XMIT in qmail-pop3d ?
On Thu, 8 Apr 1999, John Grant wrote: > So, is anybody using XMIT ? Since it's a standard feature in qpopper I would > hope that someone is doing this... it may be a standard feature in qpopper, the issue here is that it's not part of the POP standard, and so most mail clients don't seem to support it. Hence, since none of my users is clamouring for it there's no point in me spending time on it.
Re: qmail speed
On Fri, 9 Apr 1999, Dave Sill wrote: > A short-term, special purpose fix for "customized spam" applications > would be a high-speed queuer that does the queuing and preprocessing > of qmail-queue and qmail-send. E.g., > > 1) stop qmail > 2) invoke custom queuer which: > a) puts cutomized message in queue/mess/NNN/MMM > b) puts envelope sender in queue/info/NNN/MMM > c) puts recipient in queue/remote/NNN/MMM > 3) restart qmail > > Cuts out all the preprocessing junk: rewriting addresses, deciding if > local or remote, todo files, etc. Avoids all the work necessary to > keep the queue sane during the injection process. personlyy, I think it would be quicker to write a perl script to fire off lots of qmail-remote in parallel for each recipient, and if there's an error report pass the message off to qmail-queue for it to process. we're talking about cutting out all of the queue processing, much disk i/o for most recipients RjL
Re: procmail problem
On Sun, 11 Apr 1999, Adam D. McKenna wrote: > Sorry to post is here, but I am getting tons of messages in my logs that > look like this: What does the .qmail file which is being used for the delivery contain? then the procmail fans can tell what's up... Richard
Re: [Q] qmail speed "again"
On Tue, 13 Apr 1999, Keith Burdis wrote: > Remember that we're talking about sending one message to a large number of > addresses on the same remote host. In general qmail is faster, but I think in > this case any MTA that does multiple rcpt to's will be quicker. if the effect latency of the connection is greater than the bandwidth between the end systems multiple connections will complete faster than multiple rcpts. In general this is true: the latency of my dialup connection is a greater effect than the bandwidth on sending messages), the latency between my ISP and the rest of the Internet is greater than its bandwidth... I think you should get information on latency for message from a machine running a large distribution lst to see where it's spending its time Richard
Re: Solaris 7 x86 and number of process limitation
On Wed, 14 Apr 1999, Mark Delany wrote: > That's easy. The maximum for concurrencyremote is 256. I think this is mainly because the processes communicate by writing a single byte backwards to qmail-send. does the semantics of read&write of multiple-byte values mean that if I write 2 bytes into a pipe I'll always get 2 bytes out of the pipe in a single read? if so then one might be able to patch qmail to support 65k qmail-remotes? RjL
Re: oversized dns packet
On Mon, 19 Apr 1999, Adam D. McKenna wrote: > From: Scott Schwartz <[EMAIL PROTECTED]> > > > : Notice also that you might be sent a reply that is smaller than 512 > : bytes, but, because of information in your cache, the resolver might > : hand you more bytes than that. > > This is what I don't understand -- I didn't apply the dns patch, but I never > have trouble sending to AOL. Yet so many other people do. Is there a > reason for this? > lots of possible reasons: - entry in smtproutes (I hand AOL-mail of to my ISp to deliver for me) - transparent SMTP proxy firewall between you and AOL - serialmail Richard
Re: qmail displays GMT time instead of local time
On Wed, 21 Apr 1999, Troy Morrison wrote: > > | Because it is easier to track delays via Received: headers when they > | all use the same time zone. > > I don't mean to flame (I think this list is a little esoteric and > hot-tempered as it is), but this seems like a bogus statement, considering > that I haven't ever seen another MUA do this. (I'm not saying that they > don't, but I don't recall seeing it.) Is this a let's be different > because we can mentality, or is there a better reason than this? I know of no MUA which touches Received: lines RjL
Re: No HELO greeting from qmail-send?
On Thu, 21 Jan 1999, Daniel Garcia wrote: > hi, > I sent few hundred emails, after few days I got almost all of them back > with the same error below : > > > > Hi. This is the qmail-send program at . > I'm afraid I wasn't able to deliver your message to the following > addresses. > This is a permanent error; I've given up. Sorry it didn't work out. > > <[EMAIL PROTECTED]>: > Connected to 207.217.120.121 but my name was rejected. > Remote host said: 501 HELO requires domain address > I'm not going to try again; this message has been in the queue too long. > well.. it may have been that that machine was sending an invalid 5xx response to HELO (it's not doing that at the moment). since this invalid qmail assumes the remote system is broken and will be fixed sometime in the future, and will retry the message Richard
Re: qmail start problem
On Mon, 3 May 1999, Samuel Dries-Daffner wrote: > > Having a problem with getting qmail started after a system upgrade...(from > Solaris 2.5.1 to 2.6). This is what I had in my startup script (which used > to work fine!): > > nice -20 env - PATH="/var/qmail/bin:$PATH" qmail-start ./Mailbox splogger > qmail & the nice command is fairly pointless -- qmail bottlenecks on disk i/o on any machine with enough memory. if it doesn't have enough memory it'll probably not make much difference, and adding the memory will help more.
Re: What happens when qmail-send is killed?
On Wed, 5 May 1999, Fred Lindberg wrote: > Thanks for confirming this! This means that a cleaner shutdown might be > to kill all qmail-remote[/local] as well as qmail-send. possibly, but you don't know if it's /just/ done the CRLF '.' CRLF at the end of the message and is waiting for the confirmation back, in that case you might end up with duplication. myself, for a linux system only (killall behaving completely differently on a solaris machine!!] I do the following in my qmail.init script svc -d -x /var/qmail/supervise while (killall -0 qmail-send) do echo waiting for qmail to exit sleep 5 done the shutdown script then spins waiting for qmail-send to shutdown tidily before proceeding with the rest of the shutdown scripts Richard
Re: problems with list?
On Thu, 28 Jan 1999, Racer X wrote: > Has anyone else been receiving multiple copies of any messages to the > list? I seem to be getting multiple copies (like 3 or 4) of any message > that's sent to the list as well as to me. no, I'm not getting that problem, however I'm seeing loads of email that seems to belongs to some other list dealing with spammers and the such-like. Richard
Re: qmail: full disk?
On Mon, 17 May 1999, Tina Stewart wrote: > Hello, > > I am new to qmail. We have been sending messages all weekend long. We are > running qmail on an Ultra 5 with 512 MB RAM. Current state of the > /var/qmail disk: > > Filesystem iused ifree %iused Mounted on > /dev/dsk/c1t1d0s7 524498 149406226% /var/qmail > > Filesystemkbytesused avail capacity Mounted on > /dev/dsk/c1t1d0s71823222 948752 85623853%/var/qmail > > But the messages file and log files complain that the disk is full. what version of solaris? could it be that you've got horrendous file system fragmentation and that switching from time to space optimisation and reducing the root-reserved space allocation to 1% will fix the problem try fsck[1] on the filesystem and see what it'll do for you? RjL [1]I've tried to find another tool whoch reports the fragmenation statistics, but can't..
RE: qmail: full disk?
On Mon, 17 May 1999, Tina Stewart wrote: > We're running Solaris 5.6 Generic_105181-03. Last week before I did a > newfs, I ran fsck - the disk was 31% fragmented but this still did not fix > the problem. yes, but have you chnaged the alloocation scheme from Time (default) to Space using tunefs? you should proabably reduce minfree to 1% if it's still 10%. qmail has lots and lots of small configuration files, queue files, etc which will only consume part of a block and time allocation leaves you with lots of part-used blocks. (it's almost the degenerate case) > > > -Original Message- > > From: Richard Letts [mailto:[EMAIL PROTECTED]] > > Sent: Monday, May 17, 1999 11:57 AM > > To: Tina Stewart > > Cc: '[EMAIL PROTECTED]' > > Subject: Re: qmail: full disk? > > > > > > On Mon, 17 May 1999, Tina Stewart wrote: > > > > > Hello, > > > > > > I am new to qmail. We have been sending messages all > > weekend long. We are > > > running qmail on an Ultra 5 with 512 MB RAM. Current state of the > > > /var/qmail disk: > > > > > > Filesystem iused ifree %iused Mounted on > > > /dev/dsk/c1t1d0s7 524498 149406226% /var/qmail > > > > > > Filesystemkbytesused avail capacity Mounted on > > > /dev/dsk/c1t1d0s71823222 948752 85623853%/var/qmail > > > > > > But the messages file and log files complain that the disk > > is full. > > > > what version of solaris? > > > > could it be that you've got horrendous file system > > fragmentation and that > > switching from time to space optimisation and reducing the > > root-reserved > > space allocation to 1% will fix the problem > > > > try fsck[1] on the filesystem and see what it'll do for you? > > > > RjL > > [1]I've tried to find another tool whoch reports the fragmenation > > statistics, but can't.. > > > RjL == The problems of the world|| Fax: +44 870 0521198 can't be solved by fixing|| Email: [EMAIL PROTECTED] the working -- C. Daniluk|| Phone: +44 385 275 394
RE: qmail: full disk?
53% + 47% fragmentation=100%
there is a mention of this problem in relation to web caches in
the squid faq, http://squid.nlanr.net/Squid/FAQ/FAQ-14.html#ss14.1
""
disk write error: (28) No space left on device
You might get this error even if your disk is not full, and is not out of
inodes. Check your syslog logs
(/var/adm/messages, normally) for messages like either of these:
NOTICE: realloccg /proxy/cache: file system full
NOTICE: alloc: /proxy/cache: file system full
In a nutshell, the UFS filesystem used by Solaris can't cope with the
workload squid presents to it very well. The filesystem will end up
becoming highly fragmented, until it reaches a point where there are
insufficient free blocks left to create files with, and only fragments
available. At this point, you'll get this error and squid will revise its
idea of how much space is actually available to it. You can do a "fsck -n
raw_device" (no need to unmount, this checks in read only mode) to look at
the fragmentation level of the filesystem. It will probably be quite high
(>15%).
Sun suggest two solutions to this problem. One costs money, the other is
free but may result in a loss of performance (although Sun do claim it
shouldn't, given the already highly random nature of squid disk access).
The first is to buy a copy of VxFS, the Veritas Filesystem. This is an
extent-based filesystem and it's capable of having online defragmentation
performed on mounted filesystems. This costs money, however (VxFS is not
very cheap!)
The second is to change certain parameters of the UFS filesystem. Unmount
your cache filesystems and use tunefs to change optimization to "space"
and to reduce the "minfree" value to 3-5% (under Solaris 2.6 and higher,
very large filesystems will almost certainly have a minfree of 2% already
and you shouldn't increase this). You should be able to get fragmentation
down to around 3% by doing this, with an accompanied increase in the
amount of space available.
"
On Mon, 17 May 1999, Tina Stewart wrote:
> umounted the disk and ran fsck - 47% fragmentation...
> mako{root}: fsck /var/qmail
> 526455 files, 950898 used, 872324 free (872324 frags, 0 blocks, 47.8%
> fragmentation)
>
> I restarted qmail and now it is taking up lots of CPU...
>
> last pid: 803; load averages: 1.16, 0.95, 0.58
>
> 48 processes: 46 sleeping, 1 running, 1 on cpu
> CPU states: 0.0% idle, 0.4% user, 99.6% kernel, 0.0% iowait, 0.0% swap
> Memory: 512M real, 65M free, 768M swap free
>
> PID USERNAME THR PRI NICE SIZE RES STATE TIMECPU COMMAND
> 693 qmails 1 -250 1208K 936K run 7:56 94.90% qmail-send
> 803 root 1 330 2000K 1536K cpu 0:00 1.15% top
> 496 root 1 330 1792K 1488K sleep 0:07 0.05% sshd1
> 795 qmaild 1 340 1416K 864K sleep 0:00 0.03% qmail-smtpd
> 691 root 1 330 1416K 1016K sleep 0:00 0.02% splogger
> 155 root 6 80 3232K 1712K sleep 0:00 0.02% syslogd
> 801 qmaild 1 330 1416K 864K sleep 0:00 0.02% qmail-smtpd
>
> > -Original Message-
> > From: Adam D. McKenna [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, May 17, 1999 2:47 PM
> > To: Tina Stewart
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: qmail: full disk?
> >
> >
> > maybe it's a mount problem. I've seen this with linux before
> > -- I don't
> > have a lot of solaris experience. Try stopping qmail, unmounting and
> > mounting the filesystem and restarting.
> >
> > --Adam
> >
> > - Original Message -
> > From: Tina Stewart <[EMAIL PROTECTED]>
> > To: 'Adam D. McKenna' <[EMAIL PROTECTED]>
> > Cc: <[EMAIL PROTECTED]>
> > Sent: Monday, May 17, 1999 5:38 PM
> > Subject: RE: qmail: full disk?
> >
> >
> > : We sent 247,000 messages and there are about 85,000 more to
> > go in the todo
> > : queue. The body of the message is just under 2k.
> > :
> > : -tina
> > :
> > : > -Original Message-
> > : > From: Adam D. McKenna [mailto:[EMAIL PROTECTED]]
> > : > Sent: Monday, May 17, 1999 2:29 PM
> > : > To: Tina Stewart
> > : > Cc: [EMAIL PROTECTED]
> > : > Subject: Re: qmail: full disk?
> > : >
> > : >
> > : > From: Tina Stewart <[EMAIL PROTECTED]>
> > : > : > > Filesystem iused ifree %iused Mounted on
> > : > : > > /dev/dsk/c1t1d0s7 524498 149406226% /var/qmail
> > : > : > >
> > : > : > > Filesystemkbytesused avail capacity
> > : > Mounted on
> > : > : > > /dev/dsk/c1t1d0s71823222 948752 85623853%
> > : > /var/qmail
> > : >
> > : > Could it be that someone mailed one (or more) of your users a
> > : > ludicrously
> > : > large attachment, and qmail is trying to write it to disk and
> > : > running out of
> > : > space?
> > : >
> > : > --Adam
> > : >
> > : >
> > :
> >
>
RjL
==
The problems of the world|| Fax: +44 870 0521198
can't be solved by fixing|| Email: [EMAIL PROTECTED
Re: Server cluster
Michael Boman wrote: > > On Mon, Dec 27, 1999 at 08:33:10AM -0500, Dave Sill wrote: > > Michael Boman <[EMAIL PROTECTED]> wrote: > > > > >On Mon, Dec 27, 1999 at 07:08:01AM -0500, Dave Sill wrote: > > >> > > >> /var/qmail can't be shared, and shouldn't be remote. > > > > > >How can the mailservers help each other with outgoing mail then? > > > > There's really no way to have multiple servers responsible for > > delivering the same message. You can spread the load across multiple > > servers, but each server will be solely responsible for its messages. > > > > >Is /var/qmail/queue enough to share for that, or is each server for > > >itself? > > > > You can't share /var/qmail/queue. > Let me see if I get this right, it is OK to share the /home/vpopmail > directory, but not the others? Anyone have ideas how to keep the qmail > controlfiles etc up-to-date on each computer, or can I just share that > directory (/var/qmail/control and maybe /var/qmail/alias). > > Please advice Where I worked in the UK we used several machines (post.salford.ac.uk) which shared the same configuration; this was periodically updated using two files, one of which contained the length of the other file to ensure they were copied correctly between machines. (the copying being performed using ssh -- so corruption and security was not an issue). The machines acted purely as message switches storing no messages locally (unless the destination machine was down) If we needed to add more switching capacity another machine could be easily added to the cluster. If a machine blew up or needed upgrading we could take it out of the cluster and it would not affect the others directly. I do not think NFS is a reliable mechanism for sharing configuration files for reliable delivery. I like systems to be minimally dependent on others during normal operation. oh, the post servers could have been writing the mail into pop mailboxes over NFS, except we were using SMTP to move it to the pop mail servers which wrote locally. If qmtp had been built into the qmail-remote servers we would probably have used that too. Richard Letts, Austin, Texas
Re: Forcing the queue.
> "M. Richardson ( Technical Support - Big Net Au )" wrote: > > Hi, > > I've looked for this in the FAQ and HOW-TO but to no avail, and > I'm hoping somebody here can help me out. > > What I'm trying to do is combine 7 existing mail servers into one > large (massive) mail server... currently the largest server we have > (1400 users) is running a queue at an average of 20mb before I > merge these seven servers I'm wondering is there a way to have qmail > send messages straight from the queue, without waiting. (Much like > sending qmail an ALRM signal) ? > setup qmail on your new server, test it, then put ':big-mail-server.big.net.au' into /var/qmail/control/smtproutes on each of the little mail servers. Send the qmail-send process a 'ALRM' signal on each of the little servers. They should then attempt to deliver all of their outbound SMTP mail to your big server (thus emptying its queue). You'll then have tested your big server's ability to cope with large queues and sudden influxes of mail as well as moved the mail off the smaller machines. Hope this helps. Richard Letts
