Re: Rumours (was: Re: Recipe For A Good Book On Qmail)
let's see here. 63 characters is an enormously long domain name and you're saying in effect that each domain has an AVERAGE length of 63 characters. you're assuming 100k domains on a single machine, which again seems awful high to me. the argument about process size is less than convincing. a modern unix will not attempt to read that same file directly from disk every time qmail-smtpd is invoked, it will hit the buffer cache. every qmail-smtpd instance will be reading from the same cache, and unless i'm too mistaken, each instance will hit the same physical pages of memory. further, it's unlikely (at least based on my experience) that every qmail-smtpd will have to go through the entire rcpthosts file every single time a message comes in, so the CPU argument is a little iffy too. i'll admit for the sake of argument that a huge rcpthosts file could potentially cause problems, but one assumes that a sysadmin who has to deal with a setup that large can be bothered to read the documentation and see the notes about morercpthosts. shag - Original Message - From: "Chin Fang" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thu 1 Jun 2000 8:44 Subject: Re: Rumours (was: Re: Recipe For A Good Book On Qmail) \Maex, So please, measure, don't speculate. Get the following hardware, OS, and configuration file, then either the prstat(1) or top(1) will show you the size that I mentioned. o any SUN UltraSPARC IIi box. o SUN Solaris 8 o a /var/qmail/control/rcpthosts with 100k entries each entry 63 chars long. o qmail-smptd compiled using GCC 2.95.2 (for Solaris 8) I observed the aforementioned sizes first hand during a simulated DOS test that we did a while back. The numbers are reported by both prstat(1) and top(1), they are not based on speculation. It's not nice to call other's statements "speculation" before you can verify the accuracy yourself. Regards, Chin Fang [EMAIL PROTECTED] \Maex -- SpaceNet GmbH | http://www.Space.Net/ | Stress is when you wake Research Development| mailto:[EMAIL PROTECTED] | up screaming and you Joseph-Dollinger-Bogen 14 | Tel: +49 (89) 32356-0| realize you haven't D-80807 Muenchen | Fax: +49 (89) 32356-299 | fallen asleep yet.
Re: The current status of IETF drafts concerning bare linefeeds
- Original Message - From: "Russell Nelson" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Fri 19 May 2000 8:26 Subject: Re: The current status of IETF drafts concerning bare linefeeds Life *is* change. You can detect the absence of life by the absence of change. "Be liberal in what you accept" means accepting multiple versions of a protocol. This allows for change. It doesn't mean accepting anything thrown down your gullet, and choosing one of multiple interpretations of it. I prefer a different interpretation. "Be liberal in what you accept" means only that your program should not behave erratically or unpredictably in the face of bad data. It does not in any way mean that your program should never return an error code or blindly accept and attempt to deal with bad data. That philosophy leads to crappy software: sendmail, bind, etc. shag
Re: I want to leave this list
you'd have to post-process each and every message you delivered based on subscriber options. in this particular case, the option is on or off, so you could potentially have separate lists for the different options. but that could quickly spiral out of control if you had a bunch of options. personally i don't give a flip about stupid people who can't figure out how to unsubscribe. people will always find a way to get those damn messages through no matter what kind of hoops you make them jump through. i'd rather see mailing list owners boot people permanently from mailing lists for sending unsub requests to the list. maybe we could set up a blacklist of mailing list morons and ban them from every mailing list. shag - Original Message - From: "Kai MacTane" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Fri 19 May 2000 10:41 Subject: Re: I want to leave this list At 5/18/2000 09:47 PM -0700, Russ Allbery wrote or quoted: It breaks MIME structured bodies, which are often useful for particular purposes. It breaks some signed posts. It's useless information for 99% of the recipients. And I'm really sick of seeing mailing list posts accumulate more and more worthless junk to the point that it's practically more unwanted bytes in my mailbox than spam is. It's rather simple to skip over the messages from the completely lost people; footers that any intelligent person doesn't need are both intrusive and ugly. Say, here's an idea, which I'm not sure how difficult it would be to implement: What if, when you first subscribe, it automatically sends you messages with a footer, and the footer says something like: -- To unsubscribe, [do some stuff] To remove this footer, [do this other stuff]. Then people can self-select whether they're intelligent or not. Anyone that can remove the footer *must* have seen and noticed the unsubscription-instruction footer, and they can obviously read and follow directions (or they wouldn't have been able to ditch the footer in the first place). Since I use Majordomo, I know nothing of ezmlm internals, so I'm not sure how hard this would be to set up. But it's a thought for how to deal with the situation. - Kai MacTane System Administrator Online Partners.com, Inc. - From the Jargon File: (v4.0.0, 25 Jul 1996) finger trouble /n./ Mistyping, typos, or generalized keyboard incompetence (this is surprisingly common among hackers, given the amount of time they spend at keyboards). "I keep putting colons at the end of statements instead of semicolons", "Finger trouble again, eh?".
Re: MS SQL server with virtual domains?
To use Microsoft SQL with qmail, you'll need some sort of ODBC driver manager for Unix. The one we use is Openlink (www.openlinksw.com), which works fine for us. The main headache is getting ODBC up and running smoothly. Once that's done, you can access the database just like any other SQL database. I'm not familiar with any of the SQL code in vpopmail, but it shouldn't be too difficult to port it to ODBC, as the Openlink stuff comes with headers and libraries. Perl DBI is also an option, I believe the DBD/DBI driver for ODBC is based on Openlink. shag - Original Message - From: "Andy Grimberg" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wed 17 May 2000 15:20 Subject: MS SQL server with virtual domains? Does anyone know of a way to get an MS SQL server to work via ODBC with any of the virtual domain systems out there for qmail? I know that vpopmail 3.4.12 is supposed to have support when it is finished, but I currently can't find any mention of it in the current beta. OTH any idea how hard it would be to convolute the current MySQL code for it to work across an iODBC connection? Thanks, -Andy- -- Andrew J. Grimberg Programmer WebSuite.com 206-988-2233
Re: Backing up HUGE Maildir systems
some rdbms systems have the ability to snapshot the database and do a hot backup of the database. while that specifically does not answer the question of how to backup, if you stored all your email in the database somehow, you would be able to take advantage of the rdbms facilities for hot backup and not have to reinvent the wheel. shag - Original Message - From: [EMAIL PROTECTED] To: "Tracy R Reed" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thu 4 May 2000 9:02 Subject: Re: Backing up HUGE Maildir systems On Thu, May 04, 2000 at 01:14:25AM -0700, Tracy R Reed wrote: Anyone have any tips on how to effeciently backup Maildir systems with millions of files? I am pondering switching the company mail server over to Maildir. It's a very large and busy system. We have had situations before where there were millions of files to be backed up which took many days or perhaps even Above and beyond the comments of the other people wrt whether it's worth backing up in this way, I'm told that something like the dump command may more efficiently deal with large numbers of small files because it forks off multiple processes rather than serializes as other products/programs may do. Then again, many millions of file system lookup are probably going to hose your system for a long long time. Regards.
Re: Multi-RCPT vs. Single RCPT delivery - logic error?
One service that may be of interest for situations like this is Driveway (www.driveway.com). They offer 25mb of free storage space available from the Web (you can buy more), and the space can be shared (you can also put a password on it). In Windows 98/2000, you can even set up a "Web folder" in Explorer, which lets you treat the remote storage space like a Windows share. I'd LOVE to see more people using that rather than email for big files. Some email clients are really lame about handling large attachments (ahem, Outlook, cough), and they get bogged down encoding/decoding the attachment in the foreground. shag = Judd Bourgeois | Email: [EMAIL PROTECTED] Senior Software Developer | Phone: 805.520.7170 CNM Network | Mobile: 805.807.1162 or http://www.cnmnetwork.com | [EMAIL PROTECTED] - Original Message - From: "Chris Hardie" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Fri 28 Apr 2000 13:02 Subject: Re: "Multi-RCPT vs. Single RCPT delivery" - logic error? On Fri, 28 Apr 2000, Andy Bradford wrote: I may be rehashing old topics, and I may sound a little bit old fashioned (even at age 26), but I don't believe email was ever meant to handle that large amount of traffic. Or, in other words SMTP != FTP I am still of the opinion that one should instruct users to use the right protocols for the right reasons. Hence, put the 10MB PowderPoint file in a public or private ftp directory and then include a URL to fetch it in the email. I agree with this sentiment, but it's becoming increasingly difficult to find good ways to enforce it. Case in point: we do web development for an organization that has a PR firm develop brochures and then send them to us for posting on their website. The files are often 7-10 MB in size, large enough to be cumbersome for e-mail, small enough to make overnighting a ZIP disk seem a little excessive. The organization hosts their site with us, and so we could obviously instruct them to upload the files through FTP, but the PR firm shouldn't necessarily be able to do this. It gets more complicated when you think that it's not always going to be the same person at the PR firm sending the files, and that there are many cases where other third parties need to send us materials related to the site. Clearly it's a complicated issue, but it seems that as broadband access to the net becomes more common, businesses are going to expect to be able to use one "interface" to do all their communications, be it plain text messages or large multi-megabyte file transfers. I cringe every time someone sends me a 7 MB mail message, but it's difficult to explain to them why this is a bad idea. I'd be interested to hear if anyone's found a good general solution to this in a production/business environment. Chris -- Chris Hardie - - mailto:[EMAIL PROTECTED] -- http://www.summersault.com/chris/ --
Re: temporary failure warning message
- Original Message - From: "Brian Johnson" [EMAIL PROTECTED] To: "Qmail-List" [EMAIL PROTECTED] Sent: Mon 24 Apr 2000 13:47 Subject: Re: temporary failure warning message As things stand with qmail right now, a user sending mail through qmail gets one of three things: 1) A successful delivery. 2) A bounce message (liable to happen within a few minutes under most circumstances). 3) An eventual failure (which takes queuelifetime). you forgot the possibility of 4) Message gets totally lost and NO-ONE gets any warning... this can happen for many reasons. from entering the wrong e-mail address accidentally and whoever gets it ignores/deletes it, to the server failing and That happens to be a case of #1 above. The message was successfully delivered to the address specified by the user. Do you honestly expect any MTA to correct those "errors"? losing the message. this was my point earlier, you can't always count on getting an error message if there is an error, because there's _always_ a chance that the message will be lost without a trace. so if you do make errors Not if you have a halfway decent MTA. Writing bulletproof software is not impossible. There are only so many states the message can be in. Of course, the disk drive could always melt down with messages in queue, in which case you'd be screwed and the message could disappear. But I'd say that recovering from that kind of failure is a little outside the scope of an MTA. shag = Judd Bourgeois | Email: [EMAIL PROTECTED] Senior Software Developer | Phone: 805.520.7170 CNM Network | Mobile: 805.807.1162 or http://www.cnmnetwork.com | [EMAIL PROTECTED]
Re: Running qmail on a 4x Xeon 550MHz system
if i may jump in... the load average is the average number of processes in a runnable state. it says nothing about how much cpu time is actually being used. for instance, i run a very busy internet site (6+ million hits/day) on a p2-300 running freebsd 4.0. the load is always up around 5 or 6, sometimes closer to 8 or 9, because there are always 300-400 apache processes running. however, top reports that the processor is idle about 30% of the time. bottom line is that top doesn't mean anything about how busy the cpu is. it's strictly a snapshot measure of how many processes are in a runnable state (not sleeping). if you run the distributed net rc5 client, your machine will always have a load over 1.0, because that process is essentially always ready to run. that doesn't mean your machine is overloaded, or that there are too many tasks to run. shag - Original Message - From: "Bruce Guenter" [EMAIL PROTECTED] To: "Ruben van der Leij" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sat 25 Mar 2000 8:06 Subject: Re: Running qmail on a 4x Xeon 550MHz system On Sat, Mar 25, 2000 at 04:10:14PM +0100, Ruben van der Leij wrote: Does anyone have any idea what could be the problem? The disk IO is very low and my computer is *really* sleeping, with a load average (uptime etc) of approx. 1.4.. A loadaverage of 1.4 means you have on average 1.4 task waiting to run. Or, to put it in percentages: your machine has 140% of it's time filled with tasks that want to run. Not quite. It means that, on average, 1.4 tasks were ready to run. On a 4 processor machine, that means that there were still two completely idle CPUs. A load average of 4 would mean all 4 CPUs are 100% busy. -- Bruce Guenter [EMAIL PROTECTED] http://em.ca/~bruceg/
Re: Running qmail on a 4x Xeon 550MHz system
er, correcting myself: - Original Message - From: "Racer X" [EMAIL PROTECTED] Sent: Sun 26 Mar 2000 16:00 Subject: Re: Running qmail on a 4x Xeon 550MHz system bottom line is that top doesn't mean anything about how busy the cpu is. that should read "load average doesn't..." shag
Re: Vir Domains problems
"FAQ 4.6" refers to Dan's FAQ, the one included in the tarball. The FAQs on the site and in the tarball are not in sync; look for the "How do I create aliases with dots?" question under "Routing incoming messages by user." shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur. - Original Message - From: "Mark E. Drummond" [EMAIL PROTECTED] To: "Chris Johnson" [EMAIL PROTECTED] Cc: "qmail" [EMAIL PROTECTED] Sent: Tue 21 Mar 2000 17:38 Subject: Re: Vir Domains problems Chris Johnson wrote: FAQ 4.6 Er, please excuse my idiocy but what FAQ are you refering to? Dan's FAQ does not have section numbering ... http://cr.yp.to/qmail/faq.html. Nonetheless, I did check Dan's FAQ when setting this up. That is why I am stumped. The FAQ says, --BEGIN QUOTE-- How do I set up a virtual domain? I'd like any mail for nowhere.mil, including [EMAIL PROTECTED] and [EMAIL PROTECTED] and so on, to be delivered to Bob. I've set up the MX already. Answer: Add nowhere.mil:bob to /var/qmail/control/virtualdomains, and tell qmail to read virtualdomains. Add nowhere.mil to /var/qmail/control/rcpthosts. Now mail for [EMAIL PROTECTED] will be delivered locally to bob-whatever. Bob can set up ~bob/.qmail-default to catch all the possible addresses, ~bob/.qmail-info to catch [EMAIL PROTECTED], etc. --END QUOTE-- Now, I added nowhere.mil (well, a real domain of course but let's stick with the example) to control/virtualdomains (nowhere.mil:alias-nowhere.mil). I "told" qmail to read virtualdomains. I added nowhere.mil to control/rcpthosts. The MX records were changed accordingly. I created ~alias/.qmail-nowhere.mil-default with [EMAIL PROTECTED] as it's contents. Ergo, mail to *@nowhere.mil should go to [EMAIL PROTECTED] That is not happening. The mail is bouncing with the error quoted in my first message. If I then create ~alias/.qmail-default with any email address in it ([EMAIL PROTECTED]) then _all_ email is forwarded to that address, including all mail for nowhere.mil. Delete ~alias/.qmail-default and mail start bouncing again. I expect, perhaps incorrectly, that the correct behaviour would be, in the face of a message to say [EMAIL PROTECTED], to look for these files, in this order: ~alias/.qmail-nowhere.mil-info ~alias/.qmail-nowhere.mil-default ~alias/.qmail-nowhere.mil ~alias/.qmail-default ~alias/.qmail Now, maybe it does not check all of those but that is irrelevant. Obviously, assuming the setup I stated above, all mail to *@nowhere.mil should be going to [EMAIL PROTECTED] It is not and that is what I was hoping someone could help me out with. Claimer: I've read the docs, the HOWTO, LWQ, the FAQ. What I need is some extra eyes to locate what I am doing wrong, not scripture. -- Mark Drummond|ICQ#19153754|mailto:[EMAIL PROTECTED] UNIX System Administrator|Royal Military College of Canada The Kingston Linux Users Group|http://signals.rmc.ca/klug/ Saving the World ... One CPU at a Time
Re: Spam getting through despite closed relay; or even with no qmail-smtp running !
All those qmail remote processes are sending out that spam mail you thought you got rid of. My guess is that the stuff is still in your local queue, so use qmail-qstat/qread to check and see. qmail-smtpd/tcpserver do not need to be running for outgoing mail to be sent. What you probably want to do in this case is kill qmail as quickly and safely as possible, clean up the queue, and then restart qmail. I've had to do this a couple of times when I missed a relay rule or something, so here's my step-by-step list of stuff to do. Smarter people than me can feel free to correct it :) 1) If possible, unplug the box from the network, or ifconfig down the public interface. 2) Kill qmail-smtpd. 3) Send qmail-send a TERM signal, which will make it exit ASAP. 4) kill -9 all the qmail-remote processes that you see. 5) At this point qmail should be completely stopped and you can clean out the queue. Step #4 might be a little dangerous. I'm almost certain qmail will correctly assume the process failed and defer the message normally (this way you won't lose any legit mail), but I can't seem to find where in the docs or source this is made clear. But I trust DJB to do the right thing in this case :) shag - Original Message - From: "chas" [EMAIL PROTECTED] To: "qmail list" [EMAIL PROTECTED] Sent: Sat 18 Mar 2000 14:08 Subject: Spam getting through despite closed relay; or even with no qmail-smtp running ! I screwed up : I left my box open for a few days and already somebody found it and started to send spam. So, I installed ucspi-tcp and allowed selective relaying as described in the excellent document by Chris Johnson. "Selective relaying with tcpserver and qmail-smtpd" http://www.palomine.net/qmail/selectiverelay.html And I've tested this from the network as well as from http://www.abuse.net/relay.html and it would appear that relaying is not allowed. I just rebooted the machine and have not yet started tcpserver and qmail-smtp, and suddenly I find dozens of qmail-remote processes running. (see below) Could somebody pls tell me what is going on here ? Have these been queued ? (I couldn't find them in /var/qmail/queue or any of its subdirectories) How can they still be getting through to my box if qmail-smtp is not even running yet ? (telneting to port 25 won't even get you a connection). And how can I get rid of them ? (Oh, and if anybody knows the [EMAIL PROTECTED], pls break his kneecaps) Thanks for any help b/c this is obviously not a good thing - I'm just killing qmail-remote. chas qmailr 10836 0.0 0.1 788 428 p0 S 5:49AM 0:00.00 qmail-remote crazy.ucs.com.tw [EMAIL PROTECTED] 257@cra qmailr 10853 0.0 0.1 788 428 p0 S 5:49AM 0:00.00 qmail-remote crazy.ucs.com.tw [EMAIL PROTECTED] 274@cra qmailr 10859 0.0 0.1 788 428 p0 S 5:49AM 0:00.00 qmail-remote crazy.ucs.com.tw [EMAIL PROTECTED] 280@cra qmailr 10863 0.0 0.1 788 428 p0 S 5:49AM 0:00.00 qmail-remote crazy.ucs.com.tw [EMAIL PROTECTED] 284@cra qmailr 10869 0.0 0.1 788 428 p0 S 5:49AM 0:00.00 qmail-remote crazy.ucs.com.tw [EMAIL PROTECTED] 290@cra qmailr 10875 0.0 0.1 788 428 p0 S 5:49AM 0:00.00 qmail-remote crazy.ucs.com.tw [EMAIL PROTECTED] 296@cra qmailr 10877 0.0 0.1 788 428 p0 S 5:49AM 0:00.00 qmail-remote crazy.ucs.com.tw [EMAIL PROTECTED] 298@cra qmailr 10880 0.0 0.1 788 428 p0 S 5:49AM 0:00.00 qmail-remote crazy.ucs.com.tw [EMAIL PROTECTED] 300@cra qmailr 10881 0.0 0.1 788 428 p0 S 5:49AM 0:00.00 qmail-remote crazy.ucs.com.tw [EMAIL PROTECTED] 301@cra qmailr 10882 0.0 0.1 788 428 p0 S 5:49AM 0:00.00 qmail-remote crazy.ucs.com.tw [EMAIL PROTECTED] 302@cra qmailr 10883 0.0 0.1 788 428 p0 S 5:49AM 0:00.00 qmail-remote crazy.ucs.com.tw [EMAIL PROTECTED] 303@cra qmailr 10884 0.0 0.1 788 428 p0 S 5:49AM 0:00.00 qmail-remote crazy.ucs.com.tw [EMAIL PROTECTED] 304@cra qmailr 10885 0.0 0.1 788 428 p0 S 5:49AM 0:00.00 qmail-remote crazy.ucs.com.tw [EMAIL PROTECTED] 305@cra qmailr 10886 0.0 0.1 788 428 p0 S 5:49AM 0:00.00 qmail-remote crazy.ucs.com.tw [EMAIL PROTECTED] 306@cra qmailr 10887 0.0 0.1 788 428 p0 S 5:49AM 0:00.00 qmail-remote crazy.ucs.com.tw [EMAIL PROTECTED] 307@cra qmailr 10888 0.0 0.1 788 428 p0 S 5:49AM 0:00.00 qmail-remote crazy.ucs.com.tw [EMAIL PROTECTED] 308@cra qmailr 10889 0.0 0.1 788 428 p0 S 5:49AM 0:00.00 qmail-remote crazy.ucs.com.tw [EMAIL PROTECTED] 309@cra qmailr 10890 0.0 0.1 788 428 p0 S 5:49AM 0:00.00 qmail-remote crazy.ucs.com.tw [EMAIL PROTECTED] 311@cra qmailr 10891 0.0 0.1 788 428 p0 S 5:49AM 0:00.00 qmail-remote crazy.ucs.com.tw [EMAIL PROTECTED] 312@cra qmailr 10892 0.0 0.1 788 428 p0 S 5:49AM 0:00.00 qmail-remote crazy.ucs.com.tw [EMAIL PROTECTED] 313@cr
Re: Qmail Relay Question
- Original Message - From: "Lee Trotter" [EMAIL PROTECTED] To: "qmail list" [EMAIL PROTECTED] Sent: Fri 17 Mar 2000 10:58 Subject: Re: Qmail Relay Question My time is not more valuable then yours I never said it was however if I can You pretty clearly implied it was, if you didn't actually say it. find the answer in an easier fashion such as from someone who don't mind answering me why not use it? If you don't want to answer someone because Because most of the people on this list DO mind answering it, and they also mind having to see the same questions posted over and over again. My apologies if I'm speaking for too many people here, but I don't think my assumption is too far off. they you feel it would waste your time then don't. But expect the same response on what you might feel is a vaild question and someone else thinks would just be wasting their time. If all the questions have been answered then whats the point of a mailing list? Mailing lists are "push" sources of information. When new information comes out, it's sent to everyone. No one wants to have the same information fed to them over and over again; that's what we have "pull" sources (references, docs, man pages, FAQs, list archives, etc) for. Not to be rude here, but if you aren't reasonably sure your question is valid and important, you should go check the other resources first and make sure it hasn't been answered before. shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur.
Re: SMTP in distributed DOS
- Original Message - From: "Dirk Harms-Merbitz" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thu 2 Mar 2000 16:34 Subject: Re: SMTP in distributed DOS Neither bouncing messages nor return receipts make sense for ordinary messages. And for registered messages one needs authentication and encryption anyway. Bounces don't make sense? What other mechanism do you propose for signaling a failed delivery? [DOS rant deleted] As Russ said, there are far more effective and less traceable DOS attacks than this. Even legitimate email could be used as a "DOS attack"; what can we do to stop that? The truth is we don't worry about it. The value of legitimate email is much, much higher than the (comparatively minor) burden of receiving a bunch of crap. Somebody is going to write a program that does something like this. We might as well turn bounces off now before that happens. I'd hazard a guess that you'd be violating some RFC. Even if you weren't, what should happen to failed messages? They just get sent to the bit bucket and disappear? I don't think that it is the mail server's place to divulge which addresses are valid and which are not. Perhaps you should have a live postmaster read all bounces then before returning to sender. shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur.
Re: Safecat challenge
minor corrections:
the whole "challenge" was a marketing ploy by oracle (not novell), aimed
at exercising some little used feature of both oracle and microsoft, but
a feature which oracle had spent a boatload of time optimizing solely
for this challenge. i don't recall the specifics of it, but it was
debunked by infoworld and other news agencies as well as microsoft.
i think oracle's "challenge" didn't restrict the hardware that could be
used either or even require it to be the same, so basically oracle was
allowed to run on a high-end sun and could use the results from that,
while microsoft had to run on wintel stuff. sorta like taking the state
champion high school football team and put them up against even the
lowly cleveland browns. the browns would eat them for breakfast in
their street clothes.
a very smart move by oracle - if microsoft refuses, well then obviously
they aren't as fast, and if they didn't, well, oracle is free to use
whatever numbers it can cook up in cahoots with sun and will blow msft
away no matter what they do.
however, this is all totally off-topic for the list and it's getting
really tiresome. please, take it to private mail, or set up a web page
where those of us with that kind of morbid fascination can follow along
with this challenge.
shag
=
Judd Bourgeois| CNM Network +1 (805) 520-7170
Software Architect| 1900 Los Angeles Avenue, 2nd Floor
[EMAIL PROTECTED] | Simi Valley, CA 93065
Quidquid latine dictum sit, altum viditur.
- Original Message -
From: "Sam" [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Fri 25 Feb 2000 10:00
Subject: Re: Safecat challenge
On Fri, 25 Feb 2000, Len Budney wrote:
Just for fun, why not put your money where your mouth is? I'll give
you $250 if you can write a program which 1) Exactly conforms to the
maildir protocol (including fsync()), and 2) runs 50 times faster
than
safecat, in an independent benchmark using actual emails, and 3)
runs
at least 20 times faster on a Linux machine with an ext2 filesystem
mounted async, like mine. Since this is such a lock for you, you can
dictate terms: what will you pay me after you fail?
This reminds me of the "challenge" posed to Microsoft last year by, I
think, Novell. They bet Microsoft $1,000,000 if they can prove that
the
Microsoft SQL server is at least 1/100th as fast as their own database
server. Of course, Microsoft did not take the bait, because their
crapware runs only 1/20th as slow, and Novell would have gladly paid
Microsoft a million dollars for the privilege of publicising that
Microsoft admits that their own software runs 1/20th as slow as their
competitors.
So, basically, you want to be paid $250 for the privilege of writing
inefficient code? Come up, 'fess up, do you work for Microsoft?
Well, let's REALLY see how inefficient your code is, for which you
think
you deserve $250 dollars. I happen to have a stripped maildir
delivery
agent, which has been out there for six months, as part of
Courier-IMAP
and SqWebMail. It's a little bit more that just a maildir deliverer,
it
also calculates the current quota on the maildir, and the latest
version
also supports sharable maildir folders, which involves additional
sanity
checking to make sure that script kiddies aren't putting junk like
soft
links in a public maildir. But, even with, I estimate, four or five
times
more overhead than a completely basic maildir deliverer, looky what
happens when the very message where you issue your cough "challenge"
gets put through the ringer:
[mrsam@ny safecat-1.1]$ cat t.c
#includestdio.h
int main(int argc, char **argv)
{
int i;
int waitstat;
for (i=0; i1000; i++)
if ( fork() == 0)
{
execv(argv[1], argv+1);
exit(0);
}
else
wait(waitstat);
return (0);
}
[mrsam@ny safecat-1.1]$ time ./t ./safecat tt/tmp tt/new /tmp/msg1
[ snip ]
951500570.9689013621.ny.email-scan.com
951500570.0124413622.ny.email-scan.com
1.31user 2.03system 0:08.34elapsed 40%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (81074major+9017minor)pagefaults 0swaps
[mrsam@ny safecat-1.1]$ time ./t
/usr/lib/courier-imap/libexec/deliverquota tt /tmp/msg1 ""
1.14user 2.31system 0:03.44elapsed 100%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (86075major+12017minor)pagefaults 0swaps
So, even with me having four/five times of logical overhead (and I did
manually add the final fsync to my code), I'm still 2.5 times ahead of
you
on a small message. Most of the overhead here, certainly, is the
thousand
forks and execs. Then, if we move this into the enterpise setting,
with
PHBs sending 10 MB powerpoint presentations, I wish you the best of
luck
writing that one, a byte at a time, ba-hahaha. And, that is very much
real-life, real-world traffic
Re: Big and/or famous sites using qmail?
let's take a step back for a moment too and remember that this is Network Solutions we're talking about here, who seem to have an amazing ability to screw up anything they get their hands on. shag - Original Message - From: Dave Sill [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wed 9 Feb 2000 11.35 Subject: RE: Big and/or famous sites using qmail? [EMAIL PROTECTED] wrote: And Network Solutions, of course. Not something to be proud of, as 2 days ago Jon Rust claimed in message v0421013fb4c4c040b1e4@[209.239.239.22] that Network Solutions runs an open relay. It's no longer an open relay. I expect unsophisticated users like myself to stuff up, but if large sites can't run qmail properly, Large sites *can* run qmail properly. People--even people at large sites--make mistakes. maybe qmail could benefit from some more guard-rails. Arguably, qmail should deny relaying in the absence of control/rcphosts. Hopefully this will change with qmail 2. BTW, the historical record shows that the by-the-docs qmail installation disabled relaying well before the by-the-docs sendmail installation. qmail was anti-relaying before anti-relaying was cool. -Dave
Re: /var/spool/mail delivery using a dot-qmail file
if you need to actually STORE the mail spool under /var/spool/mail/*, then yes, you need procmail or similar. however, if you just need to fool stupid lusers/mail clients, you can deliver to the homedir and have a symlink from /var/spool/mail/user - ~user/Mailbox. of course, mbox delivery has its own problems, which are well known to this list :) shag - Original Message - From: Tim Hunter [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Fri 4 Feb 2000 7.37 Subject: RE: /var/spool/mail delivery using a dot-qmail file I agree, I used to deliver to /var/spool/mail/$USER but I am happy to say I do no longer. The only way I was able to do it was to use procmail and fastforward for my aliases. I cant remember the syntax exactly but you need a .qmail-default to call procmail from. Its ugly, unreliable, and a security risk. Why would you not use qmail in the way it was intended? just my .02 -Original Message- From: Peter Green [mailto:[EMAIL PROTECTED]] Sent: Friday, February 04, 2000 10:32 AM To: Kristina Cc: [EMAIL PROTECTED] Subject: Re: /var/spool/mail delivery using a dot-qmail file On Fri, Feb 04, 2000 at 05:10:01PM +0900, Kristina wrote: I want to configure qmail-local to deliver mail to /var/spool/mail. The /usr/share/man/cat5/dot-qmail.0 file tells you how to write a .qmail file to change delivery, however its too difficult for me to comprehe nd. Can someone help me here? Thanks in advance, Kristina P.S I do not want to use /bin/mail or procmail for /var/spool/mail delivery. I want to use qmail-local. "I would like to cut down the mightiest tree in the forest. P.S. I do not want to use an axe or a chainsaw. I want to use a herring." Sorry in advance, but that's what your question sounds like. I don't think qmail-local can do this because /var/spool/mail/$USER is not a good thing, in many people's opinion. Delivery to vsm is only supported by third-party apps, like procmail, as far as I know. Right tool for the right job, and all that... /pg -- Peter Green Gospel Communications Network, SysAdmin [EMAIL PROTECTED]
Re: workaround for port 25 block?
if you mean the ISP blocks inbound port 25 connections to your machine: yell at your ISP. they're being too nazi with their firewall rules. if they don't open the port find a new ISP. this is assuming, btw, that you have a static IP. if you don't, you really have no reason to complain, cuz people won't be able to send you mail easily anyway. if you mean the ISP blocks outbound port 25 connections from your machine to arbitrary internet hosts: as bruno mentioned, some ISPs (such as my company) block these connections to control spam. it's much easier to figure out who the spammer is if they have to relay through your server. we simply require our customers to relay through our mail servers. we don't have any restrictions on relay from our dialups, though; customers can use any address they want and send anywhere. some customers have complained about security or similar - "i don't want to send my confidential mail through your server." they neglect, of course, the fact that we own the network in between, so if we really wanted to sniff, merely avoiding one mail server isn't gonna help. most people smack their foreheads when they realize that, and so then i tell them about PGP or something similar. usually it tends to be just one remote server they need to hit, and so if they REALLY want to, i tell them to open up a high port on the remote server for smtp. in any case, your ISP should at least let you relay through their servers using any address(es) if they block your outbound connects. if they won't even do that, i'd just find a new ISP. shag - Original Message - From: Bruno Wolff III [EMAIL PROTECTED] To: Brian R [EMAIL PROTECTED] Cc: Qmail List [EMAIL PROTECTED] Sent: Fri 4 Feb 2000 11.04 Subject: Re: workaround for port 25 block? On Fri, Feb 04, 2000 at 07:46:17AM -0500, Brian R [EMAIL PROTECTED] wrote: My isp blocks port 25, I was looking for suggestions to get around this. The only thing I can come up with is: setting up a relay from an outside box to another port on my machine. Is this plausible? I am assuming you mean they are blocking connections to port 25 on your machine, but not other ports. You will need to find a host that will act as a relay for you. You need to get an MX record created that points your domain name to their domain name. If your ISP is also handling your DNS, this may not work. You need to have the relay server configured to accept mail for your domain. It needs to be configured to relay this email to your host on an alternate port. You might want to double check that it isn't actually connections to port 25 on remote hosts that is being blocked. Some ISPs are doing this to prevent spammers from causing them grief. If so, you might be able to get your ISP to lift the block. If not, you can use an outbound relay similar to the one above that listens on an alternate port.
Re: qmail-clean does not work
older than the current time, obviously. shag - Original Message - From: DeChavez , Andrew [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thu 3 Feb 2000 16.22 Subject: RE: qmail-clean does not work I meant: Which file/process does qmail compare the files in queue/info/* against? You suggested that I do touch -t 0101 so that files in the subdirs queue/info/* will become older than. tnx! -a -Original Message- From: Chris Johnson [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 03, 2000 4:15 PM To: DeChavez , Andrew Cc: [EMAIL PROTECTED] Subject: Re: qmail-clean does not work On Thu, Feb 03, 2000 at 04:11:07PM -0800, DeChavez , Andrew wrote: Which file/process does qmail check the files in queue/info/* against? I don't know what this means. How about files under queue/mess/* queue/remote/* queue/local/* ? Don't worry about them. When the message is bounced, they'll go away. Can I do this (touch -t) while qmail is up? I'm pretty sure it's safe, though I know someone will correct me if I'm wrong. Chris
Re: Retry Schedule and bounce time?
man qmail-send, search for queuelifetime, or see http://web.infoave.net/~dsill/lwq.html#retry-schedule qmail follows the quadratic retry schedule until the message is older than the max lifetime for the queue. at that point, it tries one more delivery and then bounces the message if it still fails. one thing i'm curious about - whether or not you could set queuelifetime to, say, 2 billion, and if that would essentially force qmail to retry forever at longer and longer intervals. is there any hardcoded queue lifetime limit, or will qmail retry "forever" if queuelifetime is set high enough? shag - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wed 2 Feb 2000 14.48 Subject: Retry Schedule and bounce time? Hello all qmailers! I'm new to qmail, so I'm still getting my sea legs. One question that has come up is how does qmail handle delivery problems and what schedule does it use? I think I've found the retry schedule... t(0) = start time [secs] t(i) = t(0) + (sqrt(t(i - 1) - t(0)) + 10)^2 [Local] t(i) = t(0) + (sqrt(t(i - 1) - t(0)) + 20)^2 [Remote] But I can't seem to find how qmail decides to give up on delivering a msg. My experience is that it's around 3 days, but I'd like to know exactly. Anyone know where/how this is handled ? Thanks, - Scott
Re: what makes ezmlm fast?
Like the master himself says, "Profile - don't speculate." In this case, look at the way qmail and ezmlm work. By "parallel SMTP processes" I'm assuming you're referring to the way qmail handles deliveries, which is to spawn one qmail-remote process for each recipient address. That all happens after the mail is injected by ezmlm into the qmail queue. shag - Original Message - From: Jeremy Hansen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tue 1 Feb 2000 13.39 Subject: Re: what makes ezmlm fast? I understand that qmail is the MTA, but there is also functionality in ezmlm which takes advantage of qmail in a way which makes things much faster. Something about parallel smtp processes or something like that. There's more to it then just qmail itself. -jeremy On Tue, Feb 01, 2000 at 03:03:22PM -0500, Jeremy Hansen wrote: Can someone explain to me what exactly makes ezmlm fast? I would like to try to adapt some of its functionality and speed to a customized list processor. Thanks for any input. One word: qmail. Greetz, Peter. -- Peter van Dijk - student/sysadmin/ircoper/madly in love/pretending coder | | 'C makes it easy to shoot yourself in the foot; | C++ makes it harder, but when you do it blows your whole leg off.' | Bjarne Stroustrup, Inventor of C++ http://www.xxedgexx.com | [EMAIL PROTECTED] -
Re: deleting from mail queue
- Original Message - From: Subba Rao [EMAIL PROTECTED] To: Qmail Users [EMAIL PROTECTED] Sent: Thu 13 Jan 2000 18.47 Subject: deleting from mail queue I have deleted a mail that was in the queue, since the domain name could not be resolved. nslookup too could not resolve the domain name. So I decided to delete the mail from the queue. I deleted the file number from /var/qmail/queue subdirectories. Now, I find the following message in the syslog. If the domain name is permanently unresolvable, qmail will eventually time out the mail and return it to the sender. I'm going to guess that there's some good reason you found it necessary to hurry up the process, but in general I'd let qmail do the work by itself. Jan 13 21:31:37 myhost qmail: 947817097.783376 warning: trouble opening remote/7/821705; will try again later Jan 13 21:33:41 myhost qmail: 947817221.783378 warning: trouble opening remote/7/821705; will try again later What else needs to be done to stop this message? For future deletions, what is the recommended way to delete a mail from the queue? There are a number of ways to do it. One of the easiest is to get the qmHandle tool from www.qmail.org. One thing to note is that qmail-send should not be running if you're going to monkey with the queue. In the particular situation you noted above, if you have a lot of mail for this domain, you can get rid of it quick: echo baddomain.com:alias-bitbucket /var/qmail/control/virtualdomains echo /dev/null ~alias/.qmail-bitbucket kill -HUP `pidof qmail-send` kill -ALRM `pidof qmail-send` (wait for queue to clear out) (remove baddomain.com entry from virtualdomains) kill -HUP `pidof qmail-send` shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur.
Re: Qmail daemon messages
- Original Message - From: Greg Owen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Fri 17 Dec 1999 14.12 Subject: RE: Qmail daemon messages opinion The problem you are having is not the default messages - it is newbie email users. I am consistently amazed how many people have trouble getting their own email address correct, much less analyzing bounce messages of ANY format. I have yet to find a good patch for this problem. /opinion I've found a solution of sorts. People have an obnoxious tendency to reply directly to qmail's bounce messages. I guess they think there's a little tiny human inside the computer shuffling messages around from mailbox to mailbox, and when he can't find a mailbox he types out a little message saying sorry. Then people reply saying "oh could you try this instead," as if this is directory assistance and whoops, they got the wrong city again, it's West Blunfingburg, not East Blunfingburg.. Anyway, I changed the default "from" address for bounces from "postmaster" to "qmail." I then set up "qmail@" to be an autoresponder that nicely tells the person that they need to actually bother reading the error message next time. postmaster mail still goes to me if someone has a legitimate "can you help me locate this address" query. If you'd like to see the actual autoresponder message, send an email to [EMAIL PROTECTED] Feel free to steal this idea for your own use. shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur.
Re: off-topic: include file des.h
From your address I can see that you aren't in the US or Canada, and despite the recent changes in encryption law, I don't think I could send this to you. But besides just that, you haven't specified what OS or version you're using. You'll also need the library that contains those crypt functions, not just the header file. This is also probably not legal to distribute, inside or outside the US. Finally, this message is pretty clearly off-topic unless you're trying to do something with crypt and qmail, and you haven't said what you're trying to do exactly. shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur. - Original Message - From: Ari Arantes Filho [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Fri 17 Dec 1999 14.17 Subject: off-topic: include file des.h Hi, I'm trying to work with a crypt system and the program is asking for include des.h. Can anyone send this file to me? Best regards, Ari
Re: Fw: failure notice
ah.. thanks for the info. i'll point out that the software involved is Eric Huss' autorespond.c, which is mentioned on www.qmail.org and also available at http://www.netmeridian.com/e-huss/autorespond.tar.gz. i believe this is also the autoresponder package recommended for use with the qmailadmin package at inter7.com. i'm kinda surprised i've never seen this before; we've had this autoresponder up for probably 6 months and i've never seen an error like this. thanks- shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur. - Original Message - From: Sam [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Fri 10 Dec 1999 18.42 Subject: Re: Fw: failure notice On Fri, 10 Dec 1999, Racer X wrote: can someone tell me what's wrong with the headers that would cause the message to bounce like so? i'm curious to know because this is an autoresponder that's generating the "bad" headers. [ snip ] [EMAIL PROTECTED]: 143.183.152.22 failed after I sent the message. Remote host said: 553 Header error --- Below this line is the original bounce. Return-Path: Received: (qmail 11920 invoked by uid 257); 10 Dec 1999 14:42:28 -0800 Date: 10 Dec 1999 22:42:28 - Message-ID: 944865748.11916.blah Your Message-ID: header violates RFC 822.
Fw: failure notice
can someone tell me what's wrong with the headers that would cause the message to bounce like so? i'm curious to know because this is an autoresponder that's generating the "bad" headers. thanks- shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Fri 10 Dec 1999 14.42 Subject: failure notice Hi. This is the qmail-send program at cnmnetwork.com. I tried to deliver a bounce message to this address, but the bounce bounced! [EMAIL PROTECTED]: 143.183.152.22 failed after I sent the message. Remote host said: 553 Header error --- Below this line is the original bounce. Return-Path: Received: (qmail 11920 invoked by uid 257); 10 Dec 1999 14:42:28 -0800 Date: 10 Dec 1999 22:42:28 - Message-ID: 944865748.11916.blah Delivered-To: Autoresponder To: [EMAIL PROTECTED] From: CNM Network [EMAIL PROTECTED] Subject: Your mail to "[EMAIL PROTECTED]" [remainder of message cut]
changing control/me
Is it safe to change control/me to something other than the "real" hostname of the machine? For instance, say I have 2 machines, romeo and juliet - can i set control/me to just "mail" on both machines? shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur.
Re: disk mirroring
read the message again, specifically the part about "non-volatile." this is starting to get pretty far off topic for this list, but i'll offer a couple of observations: software raid is pretty much by definition slower than writing straight to disk for a single block at a time, because you still have to write the same data out but you also have to do the bookkeeping involved. as you start to write multiple blocks, you can start to see improved performance as you get rid of a single bottleneck, but at the low end it's a waste. since we're talking about the qmail queue dir here, software raid is pretty silly for the queue dir. messages tend to be small - on our isp mail servers, something like 70-80% of all messages are less than 10k. software raid is useful to lump multiple identical disks into a single large store that spreads the load evenly across spindles, but it's really more of an administrative enhancement than a performance enhancement. we use sw raid for the actual mail spool storage, and local uw scsi disk for the queues. hardware raid is a different beast entirely, particularly when you're talking about stuff that has battery backed caches. i still don't know that it would be a win for qmail unless you had a LARGE queue with lots of large messages. shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur. - Original Message - From: Florian G. Pflug [EMAIL PROTECTED] To: John White [EMAIL PROTECTED]; qmail mailing list [EMAIL PROTECTED] Sent: Mon 22 Nov 1999 18.04 Subject: Re: disk mirroring I don't really mean to be a hardass here, but you need to know about how the qmail queue works. You have the qmail source right? Included with that source is an "INTERNALS" document which describes how the queue works. With qmail's insistance on fsync'ing, you can see how a writeback cache on the HW RAID controller can help. Or perhaps you don't know? HW RAID controllers can come with non-volitile RAM caches. When part of this cache is in "writeback" mode, scsi write commands are put in the cache, and the controller tells the OS that the command has been completed. Then the writes are committed to hard drive (which have their own caches). Thus, multiple small-block writes followed by fsync's should finish much quicker on a HW RAID with writeback cache. If you're relying on OS RAM to do the same thing for a filesystem, then the fsync will put an end to that. All this would make hw-cach *forbidden* for qmail queue dir, since then it is *not* guaranteed, that what is synced is writted on disk and will survive a power loss Anyway, what is noone mentioning raid 5? I just played with it under linux (software raid) until now - but it seems quite fast. Greetings, Florian Pflug
Re: Archiving all incoming and outgoing mail... Quite an unusual problem.
woops, i just saw that he runs the server too. i thought that the client was using your server. in that case, faq 8.2 looks like the best solution. but i'd talk to the client and make sure that's what he really wants, and if he wants archiving/indexing/etc. shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur. - Original Message - From: Racer X [EMAIL PROTECTED] To: Denis Voitenko [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wed 17 Nov 1999 20.33 Subject: Re: Archiving all incoming and outgoing mail... Quite an unusual problem. well, if i were you, i'd tell him to bloody archive it himself - i make it pretty clear to customers that we don't take responsibility for making sure their stuff is secured like that. at the very least, tell him to pay you (up front) for both the time required to implement the solution as well as the cost of all associated equipment and media, and make sure you work out a contract that limits your liability in case you botch it up. but it's not that hard, really. all you really have to do is CC a copy of every message to a maildir (just add a line in the dot-qmail-default). when the maildir gets up around 550-600 mb, copy all the files to another directory and offload them to tape/cd/whatever. there's probably a better way to do it, but i'd bet this is the simplest. i'd let the customer worry about any archiving/indexing, unless you do that sort of thing for a living, in which case i'm sure you already know how to do it and how much to bill for it :) shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur. - Original Message - From: Denis Voitenko [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wed 17 Nov 1999 23.18 Subject: Archiving all incoming and outgoing mail... Quite an unusual problem. My client has demanded a very strange thing. He wants to archive all incoming and outgoing mail that goes thru the qmail server (installed and configured by me). He has a small LAN of 20+ people but the mail traffic is pretty heavy since there is a ton of AutoCad 2K documents attached to mail :-) I told him that is was generally not a great idea 'cause the mail server has only 6 gigs of space but he said he'd be willing to burn stale stuff on CD's. So technically I have no choice but to make it work. Now, how in the world do I do this? Should I create some account like archive and rewrite headers (maybe add BCC field) of all mail? The system runs maildir so I think archiving files will not be a major problem... Denis Voitenko Mail: [EMAIL PROTECTED]
big todo patch
doh, meant to send this to the list instead of just to russ :) disclaimer: some of what i'm talking about may be slightly off. if i'm not mistaken, the point of the big-todo patch is to keep the individual queue directories from containing a huge amount of files. the default qmail install uses 23 directories, and if you have (say) 25000 messages queued up, each directory will probably have over 1000 files in it. the problem with that is that there are some filesystems that get VERY slow on readdir() calls with lots of files in the directory. i think this is a well known problem with ext2fs on linux, i know i've seen it happen before when i had 2 postmaster messages in my maildir one morning. using big-todo can alleviate this problem by reducing the number of files in each queue directory to something that readdir() can cope with better. however, it's probably only useful for a site that does a LOT of small messages, each with different senders and recipients. if you're just running a list server or something i doubt it will make much difference. still, i doubt it will hurt anything in any case, but someone else might want to comment on that. shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur.
Re: NFS mounted /var/qmail/queue directory
I'm not entirely sure about the answers here but I'll see if I can add something useful to the discussion... For starters, qmail-1.03/INTERNALS says the following: The queue is designed to be crashproof, provided that the underlying filesystem is crashproof. Whether NFS is considered crashproof or not, I don't know. I don't think it really is. The questions posed in the archive were: 1. Are inode numbers consistent across NFS? 2. Are named pipes possible across NFS? 3. Are link() and rename() defined to be atomic across NFS? 1. They appear to be, at least on Linux. I'm not sure if this is required by the NFS specification, or if the NFS inode is related to the "real" inode on the disk. 2. Yes (at least on Linux). However, they aren't a part of NFS; they're handled by the kernel. Named pipes are merely an extension of the anonymous pipe facility using the filesystem as the namespace. You can put the pipes wherever you want and once they are opened, I would think you could unmount the disk and pipe operations would still succeed. I'm not sure about that though. 3. They may be so defined; however, a better question is "on what implementations can this be guaranteed?" Also, I'm sure the semantics are different depending on which version of NFS you're running. My conclusion - Mounting the queue dir over NFS may very well be possible assuming you can count on certain things. However, there's no way I would EVER do it, and you're probably asking for trouble if you do. I'm sure you've thought about this issue and have good reasons for wanting to do this, but I'm curious to know why you need to put queues on each of these machines with "limited space." If these machines were diskless (or near-diskless) workstations, you'd be better off setting each machine up to relay to a central hub. You say this is for a server setup though, so I'm assuming the machines aren't diskless. Given that these are servers, they must have at least some reasonable amount of local disk in them, so you've almost certainly got enough room to put a queue on them. shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur. - Original Message - From: Curtis Generous [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Mon 1 Nov 1999 14.04 Subject: NFS mounted /var/qmail/queue directory Is it possible (and safe) to use an NFS mounted /var/qmail/queue/* directory? [NOTE: I'm _not_ advocating sharing /var/qmail/queue/* tree between several qmail servers via NFS, but instead want to use an NFS filesystem for the /var/qmail/queue/* tree instead of using local disks which have limited space on them in our configuration.] We have a NetApp 760 filer with lots of disks, and it makes better sense to use those disks rather than buying external disk packs to attach to our QMAIL servers (on which we already use NFS mounted MAILDIR for user mailboxes). There was a thread on this topic a couple of years ago but no resolution to this issue. Here is that URL: http://www.ornl.gov/its/archives/mailing-lists/qmail/1997/04/msg00619.html Would Appreciate any feedback/comments on this issue. Thanks, --curtis
Re: snoop and bare line feeds
This is a known bug in the Microsoft SMTP server (the thing that comes with the NT Option Pack). It correctly interprets temporary errors as temporary and retries the message, but unfortunately it tries again IMMEDIATELY, which causes a lot of useless traffic. I can't advise as to what the problem is with that particular message; I've seen the problem pop up with various temporary errors, but it's always MS SMTP on the other end. The solution is to tell the remote to get a real mail server - this is pretty broken behavior. You can also, if you have the tarpitting patches installed, tarpit the remote server, which will at least slow it down until the remote administrator fixes it. shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur. - Original Message - From: Michael Boyiazis [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thu 28 Oct 1999 21.07 Subject: snoop and bare line feeds Greetings, I occasionally have smtp servers begin to "chatter" with my servers and 99% of the time, a telnet to port 25 of the offending server yields the dreaded: Microsoft SMTP MAIL So I block the IP to prevent the chatter as they just keep coming over and over again trying to deliver mail which my servers must be saying no way to. I ass/u/me that this is a bare-line-feed issue. Since everything I've read says do the fixcr with "clients" sending buggy mail, my option seems to be to block those IP's from sending (tcpserver) and try to get mail to them telling them they've been blocked. I've tried running snoop to see if I could see anything odd with the smtp packets, but I really don't know what to look for that is out of the ordinary so I can tell these folks what to fix. Any suggestions as to what might look odd? and what to tell them to fix their mail server? Thanks, mike. __ NetZero - Defenders of the Free World Get your FREE Internet Access and Email at http://www.netzero.net/download/index.html
Re: SMTP connections
You need to clarify the problem here. When you say it takes 20 seconds to send a message, do you mean that it takes 20 seconds from the time you send a message to the time it arrives somewhere else? Do you mean that you're watching the logs and it takes qmail 20 seconds to process the message? Do you mean that it takes qmail-smtpd 20 seconds to respond with a prompt when you "telnet hostname 25"? Or something else entirely? Assuming network connectivity is good, DNS is working fine, etc., a Pentium class machine should process mail pretty quickly as long as it's not swapping or anything. Have you investigated to see what exactly the machine is doing in these 20 seconds? shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur. - Original Message - From: Bill Parker [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Mon 25 Oct 1999 13.01 Subject: SMTP connections Hello All, Since I didn't get a reply back with this msg, I thought I would try again :) With the help of Ken Jones at inter7.com, I have qmail running on a slightly faster pent-133 (as opposed to a pent-100), and things are working well, however, how fast should an SMTP connection take to this box (it has a static IP which is part of our companys class C), and runs NAT via IPchains, smtp/pop3 via qmail v1.03, sshd 1.1.27, samba, etc...to send a mail message takes on average (since this morning) about 20 seconds, and then it is gone...running tcpserver with -H -R, there is a caching DNS server running on the pent-133, and lookups go quite fast (IMO), and UUnet handles our DNS table...Any ideas guys? Or a better question is how long should an SMTP connection take to form on machine which IP address range is in 192.168.3.x (and that range is listed in tcp.smtp.cdb)...blink -Bill
Re: Neat sendmail feature
to this fallback host. That way the mail that's going to go through quickly just goes ft right through your main server, while the stuff that's going to be slow (because the other end is either slow to connect or down) goes off to this other machine and doesn't clog up the main machine. It turns out to be just an amazing win. And Any thoughts about how to do this with qmail? Or reasons why it's a bad idea? seems like more trouble than it's worth. if you run sendmail then perhaps "clogging up the main server" becomes more of an issue. but on my linux box each qmail-remote process is only taking up about 400k of resident memory, of which 300k is shared. i'd run out of network pipe long before i started to slow down the main machine. there might be some differences at the extremes, for instance if you tried to run 1000 qmail-remotes simultaneously you'd probably torch the scheduler. but that's more of a unix problem than a qmail problem. my solution would be to put multiple machines behind a layer 4 load balancing switch and inject mail via that mechanism, or if that switch is too much, change up your injection mechanism to load balance. allman suggests that this is a general purpose way to offload "slow" mail, but it looks more useful to me in massive injection situations where a whole bunch of mail gets queued at once. at steady state i don't think it will make a difference. shag
Re: Mail Return Codes.
you may have noticed that there's another thread similar to this on the list right now. i'd first suggest that you ignore the 471 part, as that would be changing the meaning of the error from permanent to temporary. my second suggestion would be to find out exactly what the customer thinks the difference in codes is, and to find out exactly why he needs to know the difference between 553 and 571. my last suggestion is to tell the customer to go pound rocks. changing the behavior of a production system just so a customer can get some strange package to work right is going way beyond the call of duty. other packages don't necessary depend on the difference in codes, so it would be one thing to change the return code in certain situations, but it seems pretty silly to change it for everything. shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur. - Original Message - From: Rich Aldridge [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tue 12 Oct 1999 6.44 Subject: Mail Return Codes. Hello again, I have a customer who uses a package called mailtraq. He calls our outgoing server from an external address sometimes. When using his mailtraq package to send mail via our outgoing server, he gets a 553 status code from the server. He has requested that we return a 471 or 571 code instead. I reckon that "toying" with these codes may not be a good idea as other packages may depend on them. What does anyone else think, and are there any other solutions ? Thanks and regards, Rich Aldridge Internet Systems Engineer, Cable Internet.
Re: getting qmail to retry
Conceivably, a smart MUA could resend mail when it gets a bounce back that it thinks is a temporary condition. In most cases when I get errors trying to deliver mail to people, I don't always assume they have passed away. The difference would be doing this in the MUA vs the MTA. For mail sent by a user, doing it in the MUA makes sense. For bounce mail, there isn't really a separate MUA. The approach I speak of is just a simple hack to effect a similar behaviour. you're missing the point. the remote side has already informed you that the error is permanent and should generate a bounce message. is your MUA so "smart" that it knows exactly when the error condition will be remedied? there are a lot of errors that could conceivably be considered "temporary," but the determination of whether the error is temporary or permanent should be determined by the server doing the mail delivery. to assume your client is smarter than the server, despite the fact that your client knows nothing about the server, is not only foolish, it defeats the purpose of having return codes in the first place. shag
Re: Is inetd really unreliable?
But about the other services? I'd perhaps like to use tcpserver for them too.. and I've heard that others have had success with this. But I don't like the idea of a whole bunch of programs all configured with command line directives running in the background just for these rarely used services. what exactly is a rarely used service? also, what's the problem with programs running in the background? if they're so rarely used, they'll be the first things paged out of memory if your system needs it. Why doesn't somebody patch tcpserver so that one daemon can handle multiple services and read the configuration all out of one file. That would be really neat, IMO. there's already a program written just like that, it's called "inetd." as was mentioned in a previous exchange, one of the problems of inetd is that you can't limit each service's resources separately. programs such as xinetd or some enhanced inetd might support this, but tcpserver has an advantage in that each service is compartmented and running by itself. Also, when you tcpserver devotees start railing about how the system can be attacked with inetd, it rings hollow to me because an attacker could use any service to attack, right? So if I have inetd in my system I'm vulnerable whether I used it for qmail or not. Wouldn't it be cooler if you could show the user how to easily replace inetd with tcpserver all together? why DO you have inetd in your system? there's only one or two things i can think of that people leave inetd on for: telnet, ftp, finger maybe. unless you really really need telnet, you'd be better off with ssh. finger is so widely disabled that i don't even bother with it anymore. that leaves only ftp to run from inetd. every other major service (http, smtp, etc) has its own service control program. replacing each service with tcpserver is pretty straight forward. figure out who the service needs to run as, how many concurrent connections you'll allow, and rtfm for tcpserver. shouldn't take more than a few minutes. note that you probably won't be able to run certain things like named/apache/sshd from tcpserver, but each of those have similar functionality built in and can be limited similarly to tcpserver. shag
Re: When will qmail back off to the next MX?
ok real quick let me say that i think we've beat this horse good and dead into the ground. that said, however, i think there's been a lot of useful discussion about an issue that really hasn't been researched in the light of modern SMTP systems. that is, the whole notion of MX records started about 15 or so years ago, and maybe it's time to clarify some of the behaviors we've been talking about. i would suggest that we form another list and attempt to draft some sort of standard or RFC - not necessarily to decide on fixed behaviors that are really issues of policy, but to better define the various possible situations so that MTA developers can easily compare what their MTA does in a certain situation. no, i'm not going to be the one to lead that effort, but i'll gladly participate :) intend to converse SMTP. A configuration of firewalls that causes the connection to happen even though the destination is not willing (perhaps at this time) to converse SMTP, is misleading at best. The firewall is certainly badly implemented, and I would consider it to be broken. yes, in this particular case, the firewall is the issue - it's pretty broken. but the discussion is over what qmail should do. qmail has no idea that there's a firewall in between. halfway done and then the connection times out. let's say you send EHLO, MAIL FROM, RCPT TO, and all is well, and you start your DATA but you never get an ok from the remote. does that mean you should fall back to the next MX? Does it mean you should not? it would be nice to have a state diagram that shows what paths the program might take depending on how far the SMTP transaction gets. at least then you'd know what the program does and (i guess) you could modify its behavior appropriately. A way to work around that failure is to try another MX host, if more than one is present, guided by the priority information given. It may not be mandatory to do so, but doing so is a way to work around failure. An implementation that does not fall back to another MX is an implementation that is not attempting to work around failure. "failure" is a subjective term. Which scenario are you referring to when you say "the DNS configuration IS broken"? Are you referring to the scenario where the firewall is broken, and just tossing this in to confuse the issue? Since when is having more than one MX record for a host to be considered "broken" when one of the hosts might be down? publishing an MX host that is never reachable seems pretty broken to me. it may be technically permitted, i suppose it's not explicitly forbidden anywhere, but publishing the record is like saying "what if 2 plus 2 equals 5?" interesting concept but pointless to bother with it. the firewall is clouding the issue. Just because one scenario which Qmail could "work around" happens to be a scenario which is either configured or implemented broken, does not mean that no other scenarios can exist which would involve the same issue. Just because one scenario represents a case which is not an interim failure does not mean that every scenario is likewise. agreed. Hosts do sometimes go down. They do sometimes fail. They do sometimes have problems which, while not entirely crashing, do prevent the completion of a protocol at ANY step along its defined path, including before and immediately after the TCP connection is established. Even Qmail could fail in such a way when running on a machine which has an interim problem providing Qmail with the resources to complete execution (e.g. memory exhausted). It's a failure. You might call it "broken" if you want. The issue is whether or not it is worthwhile to attempt to work around the failure. the issue is more than that - it's "to what lengths should qmail go to work around the failure?" shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur.
Re: ALRM and ongoing deliveries?
if he's demanding that you run the queue every 15 minutes, that would seem to suggest that he's permanently connected, in which case i'm wondering why the mail isn't delivered directly to his machine. assuming that's not possible though, i'm pretty sure that if you're acting as MX for him, your own qmail process should attempt to deliver mail immediately after it's placed in the queue. if for some reason delivery fails initially, qmail will retry according to its retry schedule. or am i missing something here? shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur. - Original Message - From: Toni Mueller [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Fri 24 Sep 1999 7.01 Subject: ALRM and ongoing deliveries? Hello, the qmail-send page says that sending it an ALRM makes it re-scan the queue. Well, somebody demanded that his qmail-send gets ALRMed every 15 minutes to minimize mail delivery time. BUT: He has a slow link and queued some 20+ megs of mail at once, in pieces around 3-7 meg each. His mail got NOT delivered for over a day while the link was constantly glowing. When I stopped that cron job the mail was out in about an hour. The exact command this cronjob executes is /usr/local/bin/svc -a /var/qmail/run/qmail So what gives? Did I assume correctly that sending the ALRM interrupted the ongoing transfers and restarted them? The log file mentions "SMTP connection died" several times... If so, how do I have the queue run every 15 minutes w/o disturbing the deliveries already in progress? This is qmail-1.03 with daemontools-0.53 and ucspi-tcp-0.84. "Stay tuned for more tuning questions" :-| Thank you! Regards, Toni. NIC: TM2155 Oeko.neT Mueller Brandt GbR sales: [EMAIL PROTECTED] v: +49 2261 979364 f: +49 2261 979366 http://www.oeko.net Unix, networking, administration, consulting, programming, Internet services
Re: A patched qmail-smtpd.c
I can give you a good point on #2 why it should be done by QMAIL-SMTP rather than TCPSERVER -- if you want to inhibit *all* connection from known SPAMmer IP blocks _except_ where the sender can do SMTP-AUTH... TCPSERVER has no way of handling this... Also, TCPSERVER doesn't provide SMTP error messages back (you can modify it fairly easily to allow QMAIL-SMTP to send the error message on it's behalf, and do tar pitting, etc etc etc). yes, tarpitting has to be done in qmail-smtpd, but using tarpitting implies that you're still accepting the mail. if you're not going to accept the mail anyway, why bother allowing the connection to succeed and then closing it? tcpserver will catch the IP blocks and just refuse the connection. smtp-auth isn't exactly a reason to move the ip checking into qmail-smtpd. if you're denying a net block unless they use smtp-auth, you aren't gaining anything - anyone on that net block can spoof the connection. if you want real security use ssh and forward ports. And, speaking from experience, putting a patch together sounds easy, but isn't always that simple. I run QMAIL with a fair number of changes that are of little interest to most people; building a patch is a little more tedious when it needs to be able to be applied to a generic QMAIL distribution. Don't get me wrong, PATCHES are the right way -- but sometimes providing the modified source is the most expedient to get comments from others and allow them access to your work. bah. "man diff" - it's fairly straightforward. if you intend to distribute your patches you should be building them and running diff's off of a pristine qmail install. otherwise there could be hidden conflicts between your changes and some other patch you've installed. shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur.
Re: When will qmail back off to the next MX?
How does the way the 1st MX fails to accept the message affect the working of other MXes (in a general case)? if the first MX allows a connection to port 25, there is an implied assumption that there is a program listening on port 25 that speaks SMTP. therefore, the sender should attempt delivery. the connection is never disconnected "immediately." assuming the connection succeeds it must stay connected for some minimum length of time. it could drop after 1 second with no traffic, or the SMTP transaction could get halfway done and then the connection times out. let's say you send EHLO, MAIL FROM, RCPT TO, and all is well, and you start your DATA but you never get an ok from the remote. does that mean you should fall back to the next MX? anyway, until an RFC or something clarifies exactly different situations should be handled i don't think it's particularly worthwhile to pick on qmail for 1) "not doing it like sendmail does," and 2) not handling a broken configuration in the way the breakers expect it to. say what you will about qmail, the DNS configuration IS broken (and no i don't care how many people do it that way - "everyone speeds" but that doesn't make it legal). until we can agree that, yes, someone was lazy and should fix the DNS first, i don't see the point in changing qmail's behavior. shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur.
Re: Having trouble with pop
uh, let's use our heads for a minute here and not waste time. outlook returned the exact error message: -ERR this user has no $HOME/Maildir rant are you really saying that outlook somehow changed this error message? i realize a lot of people on this list hate microsoft software, but let's at least give them the benefit of the doubt that when they say "server response" and an error message, it's really coming from the server. /rant if you'll look at qmail-pop3d.c, line 65, you'll see the same thing. you can see why these errors are raised if you look at the end of qmail-pop3d.c - either the program is passed no arguments (incorrect usage) or the program can't change to the user's directory (does not exist or permissions are incorrect). shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur. - Original Message - From: Tim Hunter [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Mon 20 Sep 1999 9.05 Subject: Re: Having trouble with pop Lets eliminate the *slight* possibly that Outlook could flub up the error message and just telnet grow.sd27.bc.ca 110 so that we can test properly. At 08:56 AM 9/20/99 -0700, you wrote: Quoting Mikko Hänninen ([EMAIL PROTECTED]): Tim Hunter [EMAIL PROTECTED] wrote on Mon, 20 Sep 1999: There was a problem logging onto your mail server. Your Password was rejected. Account: 'grow.sd27.bc.ca', Server: 'grow.sd27.bc.ca', Protocol: POP3, Server Response: '-ERR this user has no $HOME/Maildir', Port: 110, Secure(SSL): No, Server Error: 0x800CCC90, Error Number: 0x800CCC92 Do I read the Outlook error correctly, "Account: 'grow.sd27.bc.ca'", is that the same as "user"? If so, then it's unlikely that the server grow.sd27.bc.ca has a user called grow.sd27.bc.ca -- change that the desired username in Outlook settings. My installation of qmail-pop3d says "-ERR authorization failed" when I supply an invalid username. Reading the above Outlook error.. well it's wierd. Wouldn't surprise me if Outlook was just goofing up its error output! Aaron
Re: Sqwebmail and IMAP
DJB's specs on maildirs mention nothing about folders, so you cannot point to any implementation as being right or wrong, because there is no right or wrong way. Blame Dan Bernstein for an incomplete design. Maildir was designed to ensure that messages could be written safely by an MTA without having to worry about locking out an MUA that's accessing the folder at the same time. once the messages are on disk it's the UA's problem to filter/move them around. yes, i'm considering a filtering program run out of dot-qmail to be a UA; i don't think it's fair to consider it part of the TA. What is your recommendation for creating in Maildir format: somehow i doubt you're going to get an answer from dan on this one. my personal feeling is "let the UA decide how it wants to make folders," as it's an issue of policy and not function. shag
Re: Sqwebmail and IMAP
And yet, if multiple MUAs are free to implement any way they feel, then there is no recommended way and different MUAs cannot nicely co-exist. Take the example of a Mutt user who uses a webmail program to access mail. If the two MUAs work differently, they can't see each other's folders. If there were a recommended way to implement these well-known features, it could reduce confusion and support peaceful co-existence between UAs. as i mentioned in a message to the sqwebmail list earlier, there is already a recommended way to handle this. see the maildir page on dan's site, specifically the section about "info." btw, "co-existence between UAs" is generally limited to unix systems where the messages are stored in plain text files. it's not going to mean anything for people on other systems where messages are stored in a database particular to the UA (which, btw, makes for the vast majority of users). shag
Re: When will qmail back off to the next MX?
Make it configurable. ok, i get the point. i would say that it IS configurable in that different MTA's can handle it however they want. making it configurable at an even lower level would seem to be a rather difficult project and not something you could do without at least patching and rebuilding. that is, i don't think you could just have a simple qmail control file that detailed MX handling unless all the policies were already built into the source anyway. i do agree that fallback MX handling is an issue of policy and not function. an RFC would be the ideal way to answer these. doing it "like everyone else does" isn't valid. doing it "the way sendmail does" is even worse. Agreed. But in some cases I have found things can work better by violating RFCs. I don't like to distribute software that violates the RFCs, unless it would do so only if the administrator gets to choose to do so, and is aware that such a choice is a violation. I have no qualms about distributing or using any software that works that way. that's fine except in this case there IS no rfc to provide a baseline. there's "the way sendmail does it", which is in a sense a de facto standard, but it's only a standard because way back when, Eric Allman made some decisions about MX handling and for better or worse we're stuck with his decisions. Sticking to standards does have an important purpose. Deviating from them should never be done lightly. But it should not be ruled out, either. In many cases, such deviations have to be done to fully evaluate a proposed change in the standards. And sometimes, old standards are not re-visited because de-factor standards born out of deviant usage have established themselves and there is no pressure to formalize them when other standards work is more pressing. qmail is deviating from the established standard and handling things its own way. is it better or right? i don't know, there really hasn't been enough discussion. There is also another saying common in computers and networking, especially in regard to conformance to standards: Be conservative in what you produce and be liberal in what you accept. I have interpreted that to mean that if something does not conform to the standard, but I also don't have to go out of my way to detect and understand what is meant, I _may_ (and some would like this to be _should_) go ahead and accept it with the obvious semantics. the first part i agree with. the second part i'm not so sure about. my take on it is that programs should be prepared to handle any input. "handle" does not mean process necessarily, it just means that for any input, the program should have defined behavior. this means that the program has a very limited set of inputs and very well defined behaviors. if the inputs are bad, the program refuses the input. i do NOT believe that "liberal" means "should attempt to rectify problems automatically." report the problem, sure, and don't crash because the input is too big or malformed, but don't attempt to fix the problem. GIGO. I don't know of any protocol that specifically says that accepting a connection and then summarily dropping it with no output has any particular meaning in that standard. But I would readily classify this as a failure not unlike a connection refusal. I recognize this because I happen to know that there are cases where this is unavoidable. One example is that the UNIX socket API is a deficient standard for lacking the ability to allow user space processes to act on an incoming connection in a way that is seen as a connection refusal. how fast does it have to be dropped to be "summarily" dropped? 1 second? 5? 30? at what point does the connection become "established, but timed out, will try later" instead of "connection refused or immediately dropped?" shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur.
Re: When will qmail back off to the next MX?
Sorry? Did I miss an earlier message? Where does it say it's a violation? I thought this entire matter was due to it being an area not formally mentioned in the RFCs - as it isn't mentioned, neither Qmail or Sendmail/et al are right or wrong. My point was that "everyone else" does it a different way than Qmail. If Qmail did it "the same way", it would make Qmail more acceptable to users. i just did a quick search of some relevant RFC's, and all they seem to say is that MTA's may, but are not required to, try any fall back MX hosts. the only thing they seem to say is that the most preferred MX must be tried first. so qmail is within its "legal" boundaries in the way it handles MX records. without an RFC that specifies different behaviors for different situations, MX handling will always be a gray area. for instance: * if the primary host gives you a temporary error, should you fall back to the next MX? how fast, immediately or wait a while? if you wait a while, maybe the temporary error will go away? * what if a fallback gives you a temp error? should you reset your MX preference to the primary? how soon? * if any host gives you a permanent error, should you try all other hosts? (this may be answered in some rfc, i dunno) * there's clearly a difference between a "connect refused", "host not responding", "host answers but disconnects without notice", all these kind of error conditions. how should they be handled wrt MX? * how often do you check for an updated MX list? every time you send the mail? if so, should you keep track of what the preferences used to be? an RFC would be the ideal way to answer these. doing it "like everyone else does" isn't valid. doing it "the way sendmail does" is even worse. btw, in case you weren't aware, your "make qmail more acceptable to users" argument isn't going to impress people around here. shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur.
Re: Kurt's Closet on qmail
hate to jump in late here, but to both sides: where exactly does DJB say he doesn't support inetd? i can't seem to find anywhere in the source or on his site. in fact, the main qmail.html page sez: "qmail's design inherently limits the machine load, so qmail-smtpd can safely run from your system's inetd." www.qmail.org is the only place i see that actually sez "not supported," and it's reasonably clear that the creator of qmail does not maintain that page, so i'm not sure what the big deal is. shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur. - Original Message - From: Lyndon Griffin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wed 15 Sep 1999 13.24 Subject: RE: Kurt's Closet on qmail Not really... qmail out of the box doesn't support inetd. There are configuration changes you have to make *on your own* to get it to work, and the web site doesn't support or explain these changes. (I'm sure that if you wanted to support inetd stuff on this list, no-one else here would have a problem; and would probably even welcome that help, but I speak only for me.) (from INSTALL in qmail-1.03 source distribution) 16. Set up qmail-smtpd in /etc/inetd.conf (all in one line): smtp stream tcp nowait qmaild /var/qmail/bin/tcp-env tcp-env /var/qmail/bin/qmail-smtpd 17. Reboot. (Or kill -HUP your inetd and mke sure the qmail daemons are running.) There you have it... "make setup check" doesn't add/change that line in inetd.conf for you, but other than that it looks pretty "out of the box" to me. Then, to read that in conjunction with the statement on the web site IS confusing and misleading. Now, if this configuration isn't supported, the instructions in the distribution need to be changed. Or something needs to change, like maybe including tcpserver as part of the qmail distribution, if that is the supported method. Or is there a supported method?
Re: RCPTHOSTS and 533 Not in rcpthosts
ok i just checked a couple of things here: $ host gateway-s0.haven.k12.pa.us gateway-s0.haven.k12.pa.us has address 204.186.234.22 $ host 204.186.234.22 Name: gateway-s0.haven.k12.pa.us Address: 204.186.234.22 based on what you've told me, i'd have to say that 204.186.234.22 is the IP you're coming from. that net is NOT in the tcprules file you posted to the list. i would try adding: 204.186.234.:allow,RELAYCLIENT="" to your tcprules file and try again. shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur. - Original Message - From: Paul Farber [EMAIL PROTECTED] To: Racer X [EMAIL PROTECTED] Cc: qmail mailing list [EMAIL PROTECTED] Sent: Thu 9 Sep 1999 6.37 Subject: Re: RCPTHOSTS and 533 "Not in rcpthosts" I telnet to 209.173.3.254 and get the router login prompt. I did notice that I can lookup 209.173.3.254 and get gateway.shsd.haven.f-tech.net. 09:37:48.865856 gateway-s0.haven.k12.pa.us.25602 mail.f-tech.net.smtp: P 43:45(2) ack 49 win 2096 is what I get when I tcpdump host mail and port 25 then try and send a message using the cmd line. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 [EMAIL PROTECTED] On Wed, 8 Sep 1999, Racer X wrote: looks like one of two things - either the cdb is not what you think it is, or you're not coming from the IP you think you are. i'll assume the cdb is okay, but use tcprulescheck and make sure it tells you that RELAYCLIENT is set. when you telnet in from gateway.shsd.ptd.net, are you sure you are really coming from 209.173.3.254? when i do a traceroute to 209.173.3.254 i end up with this: 17 gateway-s0.haven.k12.pa.us (204.186.234.22) 91.351 ms * 84.715 ms and that's the last hop. strangely, i can't trace 204.186.234.22 directly (no route to host). is 209.173.3.254 a virtual interface maybe? use qmail-smtpd's logs on your mail server to check the connection and see where your server thinks it's from. shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur. - Original Message - From: Paul Farber [EMAIL PROTECTED] To: Chris Johnson [EMAIL PROTECTED] Cc: qmail mailing list [EMAIL PROTECTED] Sent: Wed 8 Sep 1999 19.03 Subject: Re: RCPTHOSTS and 533 "Not in rcpthosts" This is what I have now... just to make sure we area all on the same page: Done from thier router via telnet to my mail server: thier router ip is 209.173.3.254.. added to qmail-smtpd.cdb for this test gateway.shsd.ptd.nettelnet 207.44.65.16 25 Trying 207.44.65.16, 25 ... Open 220 mail.f-tech.net ESMTP helo dude 250 mail.f-tech.net mail [EMAIL PROTECTED] 250 ok rcpt [EMAIL PROTECTED] 553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1) config: 23893 ? S0:00 supervise /var/lock/qmail-smtpd tcpserver -v -H -R -c100 -x /etc/tcprules.d/qmail-smtpd.cdb -u81 -g80 0 smtp qmail-smtpd cat qmail-smtpd 207.44.65.:allow,RELAYCLIENT="" 146.145.48.133-159:allow,RELAYCLIENT="" 209.173.3.:allow,RELAYCLIENT="" 209.173.3.254:allow,RELAYCLIENT="" 127.:allow,RELAYCLIENT="" :allow made by: cat qmail-smtpd | tcprules qmail-smtpd.cdb qmail.tmp cat /var/qmail/control/rcpthosts localhost f-tech.net empirebeauty.com schoeneman.com goldwellofpa.com salonconcepts.com schuylkilldental.com rollingmeadowsgolf.com peace-inc.org teddybearus.com mail.f-tech.net login.f-tech.net admin.f-tech.net jonesandcopccpa.com biblicalstudies.com kochslg.com keystonedoors.com dreams-n-romance.com pritzauto.com wickerpalace.com benesch.f-tech.net haven.k12.pa.us Thier domain is haven.k12.pa.us. Why is it dying and not allowing thier domain/IP through ANy advise where to look next? Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 [EMAIL PROTECTED]
Re: Problems while downloading E-Mails with Outlook-Express
uh, evidently you don't speak german. I don't either but I do know that "Nein" means "No." OE allows POP and SMTP connections to be conducted using SSL. i'm not aware of any POP or SMTP servers that actually support that, but I suppose it's kinda neat that it can do it. Anyway, the error messages for OE always indicate whehter the connection is via SSL or not, so I don't think that's really an issue here. shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur. - Original Message - From: Adam D . McKenna [EMAIL PROTECTED] To: Cyril Bitterich [EMAIL PROTECTED] Cc: Qmail [EMAIL PROTECTED] Sent: Thu 9 Sep 1999 14.28 Subject: Re: Problems while downloading E-Mails with Outlook-Express On Thu, Sep 09, 1999 at 09:38:07PM +0200, Cyril Bitterich wrote: Nachricht Nr. 30 konnte nicht abgerufen werden. Konto: 'gunnet ', Server: 'pop gunnet.de', Protokoll: POP3, Serverantwort: 'Vielleicht sollte ich's mal mit "Learning by doing" versuchen???', Anschluss: 110, Secure (SSL): Nein, Serverfehler: 0x800CCC90, Fehlernummer: 0x800420CD. I like how Outlook Express reports a Secure (SSL) connection, even though it is obvious that this is just a regular clear-text POP3 connection. --Adam
Re: newbie problems with qmail-pop3d
you need to be running qmail-popup out of inetd or tcpserver, and qmail-popup must start as root so that qmail-pop3d can later change to the appropriate UID. the checkpassword thing may be related, if you're using shadow passwords for instance. fix is the same. other than that it looks like things are working okay. try starting qmail-popup out of tcpserver, and see if you can log in as a user. once you log in successfully, look at the process table and make sure qmail-pop3d is running as a normal user and not as root. shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur. - Original Message - From: Michael [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wed 8 Sep 1999 10.33 Subject: newbie problems with qmail-pop3d Thanks to all who suggested I uninstall daemontools 0.61 and reinstall 0.53. Everything seems to be up and running, however, now I am having problems with qmail-pop3d. I have tested the following: 1. Smtp sends mail out fine. I can send mail out from a local and remote account. 2. Receiving mail. I can receive mail locally and remotely (I see the messages appear in the /Maildir/new/ directory). I can't seem to pop any mail down yet. Checkpassword is installed and configured. When I run /var/qmail/bin/qmail-popup slave-1.net /bin/checkpassword pwd as a user, then enter a valid "user username" at +OK, then a valid "pass password" at +OK prompt I get an -ERR authorization failed. If I perform the same command with the same user and password as root, I get the proper /home/$user directory. Is it by design that only root can get the correct response with checkpassword? Given the above, it would appear checkpassword is working properly (I think). However, when I try to pop my mail down I get an invalid password response. I am using a WinNT mail reader. Does the mail reader have to support ./Maildir if I am only POP'ing my mail down? I am running qmail 1.03 on x86 Red Hat 6.0. Thanks.
Re: RCPTHOSTS and 533 Not in rcpthosts
well, first off, if you're running the script i'm thinking you are, it looks for qmail-smtpd.cdb, not qmail-smtp.cdb. note the trailing d on smtpd. these are the scripts written by Mate Wierdl i believe, we use the same ones here, and that's what they look for on our boxes. secondly, as Chris already mentioned, the process output you showed us clearly indicated that regardless of what's in your script, tcpserver is NOT running with the -x option. so you might want to try running it from the command line to get the options right before you run it with a script. also, the man page states that "10.1.2." (with a trailing dot) is the appropriate wildcard syntax to match everything in net 10.1.2.0/24, but "10.1.2" is not correct syntax for anything. running tcprulescheck will verify this. the 533 error is undoubtedly related to one of the above reasons. because tcpserver is NOT running with -x, it has no cdb to look at, and therefore it does not add the RELAYCLIENT variable to each instance of qmail-smtpd. this is giving you the relaying error. fix your script/invocation of tcpserver and check your tcprules. shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur. - Original Message - From: Paul Farber [EMAIL PROTECTED] To: Chris Johnson [EMAIL PROTECTED] Cc: qmail mailing list [EMAIL PROTECTED] Sent: Wed 8 Sep 1999 17.47 Subject: Re: RCPTHOSTS and 533 "Not in rcpthosts" Acutally the qmail-iniit script will check of the presence of qmail-smtp.cdb then add the -x option.. I'll assume you are not using a sysV based system. As for the trailing ., I have one line with it and one with... works fine either way. Also, tcpserver will not reply with a 533 error... that's generated by qmail. tcpserver will simple not allow the connection. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 [EMAIL PROTECTED] On Wed, 8 Sep 1999, Chris Johnson wrote: On Wed, Sep 08, 1999 at 05:33:53PM -0400, Paul Farber wrote: I had a qmail-smtp file with the class 209.173.3:allow,RELAYCLIENT="" And then made the cdb file. Still no go. It should be: 209.173.3.:allow,RELAYCLIENT="" (Note the trailing ".") But here's how you're starting tcpserver: tcpserver -v -H -R -c100 -u81 -g80 0 smtp qmail-smtpd So you can put anything you like in your rules file, and it won't have any effect whatsoever. You need to supply the rules file to tcpserver with the -x option. Chris
Re: RCPTHOSTS and 533 Not in rcpthosts
looks like one of two things - either the cdb is not what you think it is, or you're not coming from the IP you think you are. i'll assume the cdb is okay, but use tcprulescheck and make sure it tells you that RELAYCLIENT is set. when you telnet in from gateway.shsd.ptd.net, are you sure you are really coming from 209.173.3.254? when i do a traceroute to 209.173.3.254 i end up with this: 17 gateway-s0.haven.k12.pa.us (204.186.234.22) 91.351 ms * 84.715 ms and that's the last hop. strangely, i can't trace 204.186.234.22 directly (no route to host). is 209.173.3.254 a virtual interface maybe? use qmail-smtpd's logs on your mail server to check the connection and see where your server thinks it's from. shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur. - Original Message - From: Paul Farber [EMAIL PROTECTED] To: Chris Johnson [EMAIL PROTECTED] Cc: qmail mailing list [EMAIL PROTECTED] Sent: Wed 8 Sep 1999 19.03 Subject: Re: RCPTHOSTS and 533 "Not in rcpthosts" This is what I have now... just to make sure we area all on the same page: Done from thier router via telnet to my mail server: thier router ip is 209.173.3.254.. added to qmail-smtpd.cdb for this test gateway.shsd.ptd.nettelnet 207.44.65.16 25 Trying 207.44.65.16, 25 ... Open 220 mail.f-tech.net ESMTP helo dude 250 mail.f-tech.net mail [EMAIL PROTECTED] 250 ok rcpt [EMAIL PROTECTED] 553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1) config: 23893 ? S0:00 supervise /var/lock/qmail-smtpd tcpserver -v -H -R -c100 -x /etc/tcprules.d/qmail-smtpd.cdb -u81 -g80 0 smtp qmail-smtpd cat qmail-smtpd 207.44.65.:allow,RELAYCLIENT="" 146.145.48.133-159:allow,RELAYCLIENT="" 209.173.3.:allow,RELAYCLIENT="" 209.173.3.254:allow,RELAYCLIENT="" 127.:allow,RELAYCLIENT="" :allow made by: cat qmail-smtpd | tcprules qmail-smtpd.cdb qmail.tmp cat /var/qmail/control/rcpthosts localhost f-tech.net empirebeauty.com schoeneman.com goldwellofpa.com salonconcepts.com schuylkilldental.com rollingmeadowsgolf.com peace-inc.org teddybearus.com mail.f-tech.net login.f-tech.net admin.f-tech.net jonesandcopccpa.com biblicalstudies.com kochslg.com keystonedoors.com dreams-n-romance.com pritzauto.com wickerpalace.com benesch.f-tech.net haven.k12.pa.us Thier domain is haven.k12.pa.us. Why is it dying and not allowing thier domain/IP through ANy advise where to look next? Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 [EMAIL PROTECTED]
email postage
I'm wondering if anyone knows of any sort of protocol or system built to handle "email postage." I'm of the belief that as long as email is an essentially free service, people will always find a way to abuse it, and I'd like to know if there's any sort of work going on in this area, research, etc. Before you ask - no, I don't think the USPS has any business charging for email, nor any other governmental entity. I'm talking about doing this on a private, per-host basis, with the possibility of peering agreements, pay-as-you-go for email transmission, automated exchange of payment info, etc. Just bored at work and looking for something to fool around with. I've got a feeling QMTP could probably do something with this pretty easily. I've no idea how you'd be able to integrate MUA's. shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur.
hmm.. is this right?
I'm getting a lot of bounces to postmaster from some dumb mail client that isn't setting the To: or From: headers. I tested this out: telnet localhost 25 MAIL FROM: RCPT TO: DATA blah . qmail-smtpd accepts that, and then delivers a double bounce to postmaster. I'd rather it just not accept the mail in the first place. In this particular case, the dumb client is one of our customers, so I can go yell at them, but I'm kinda curious as to how this should be handled. Is there something obvious I'm missing here? shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur.
postmaster autoresponder
Hi, I'm toying with the idea of setting up an autoresponder for "postmaster@" mail. Reason: there's too many people, both customers and outsiders, who don't read the part about "this is the qmail program" and attempt to reply to postmaster with questions. (Granted, they don't read the abuse autoresponder either, particularly the part about "this is an autogenerated message", but at least this way they know they won't be getting a personal response...) Basically, I'd like to set up an autoresponder that looks for messages to postmaster, and sends the autoreply if the message is not also FROM postmaster (or mailerdaemon, or whatever). Are there any pitfalls involved in setting this kind of thing up for "important" addresses like postmaster? Thanks- shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 ...yours is not the less noble because no drum beats before you when you go out into your daily battlefields, and no crowds shout about your coming when you return from your daily victory or defeat. --Robert Louis Stevenson
Re: Performance
just to throw in my 2 cents- we've built a linux toaster setup here that we call our "cluster". right now it's 4 boxes sitting behind a layer 4 switch from foundry networks. the switch does automatic load balancing over the machines (right now it's round robin, but it can give weightings to different machines), and it will also remove a machine from the cluster if it stops responding. anyway, the 4 machines are kind of a mix, but they're all p2-300's or better with plenty of ram. what we've found from our testing is that the backend disk storage is almost always going to be the bottleneck and the single point of failure. our cluster does SMTP inbound and outbound, storing the messages on a central spool (currently NFS, gack), and it also does POP access. load testing proved that qmail could queue up the local disk substantially faster than things could be delivered to the final endpoint over NFS. still, we estimated that these 4 machines could probably handle around 3 million SMTP messages a day (that's from SMTP session start until message is queued), around 500k deliveries/day, or some combination thereof, but that's dependent on NFS. from the SMTP side, the cluster appears to scale almost linearly. on the local delivery and POP side, we're looking into some high end storage systems to better manage the load. EMC has a product called Celerra that looks neat; if anyone has any experience with it i'd love to hear about it. one thing we've done is to use separate network interface cards for the "front side" and "back side". that is, all internet traffic goes over one card, and all the NFS traffic goes over another. this keeps traffic from going over the same wire more than once (ie, a large message will go over the internet card once, and over the NFS card once, rather than a single card twice). anecdotal and empirical evidence seems to suggest it's faster, but YMMV. shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 ...yours is not the less noble because no drum beats before you when you go out into your daily battlefields, and no crowds shout about your coming when you return from your daily victory or defeat. --Robert Louis Stevenson - Original Message - From: David Dyer-Bennet [EMAIL PROTECTED] To: Qmail [EMAIL PROTECTED] Sent: Fri 6 Aug 1999 14.14 Subject: RE: Performance Tim Hunter [EMAIL PROTECTED] writes on 6 August 1999 at 16:36:48 -0400 Makes me amazed at the machines that people have to run mail anymore. My company mail server is a p75, 32M, 2G IDE I have only 30 users but alot of throughput, never had any problems with queuing or ever had to reboot for any reason other than a kernel update. Maybe I should run some benchmarks just to show how great qmail is on a piece of dirt machine. I'd be interested in seeing that sort of statistics too -- closer to my real world, for one thing :-) . Note that the person whose configuration you were marveling at is looking to move 10 MILLION customized individual email messages a day. His configuration is much bigger than I use for moving mail -- but he's aiming at moving several orders of magnitude more mail than I move, too, so that seems fair. (And gee it's smart to build a test configuration and do some benchmarking before committing to something that seems likely to push the limits of hardware / software technology!) -- David Dyer-Bennet ***NOTE ADDRESS CHANGES*** [EMAIL PROTECTED] http://dd-b.lighthunters.net/ (photos) Minicon: http://www.mnstf.org/minicon http://www.dd-b.net/dd-b (sf) http://ouroboros.demesne.com/ Ouroboros Bookworms Join the 20th century before it's too late!
Re: Radius Authentication
the obsticle I need to cross here is since the radius query would probaby only come from the main ip of the mail server we 'd only authenticate out of the domain1 users file. Is there a way to bind a radius client to perform queries from a certain IP so that the radius server can distinguish where to look? well, it depends on the implementation of the radius client. certainly you could tell it to bind to only one address, there's no unix reason you can't do that. however, what might be easier is to just modify your radius server config to support clients from whatever IP address your client appears to be coming from. i'm assuming you have permission to do this? But first is first. Where can I find a C checkpasswd that will perform radius auth anyway? I've been tinkering with that perl version, but Its not working for me, and would like a C version mainly due to speed anyway. we use the perl version here and it works great. i don't think speed will be a big consideration, especially when you consider all the code you'll have to write to do it in C (our perl version is about 40 lines i think, it's the one from qmail.org with a couple minor mods to support our convoluted directory structure). also, consider that you still have to access the network to talk to the radius server, that's going to be an order or two of magnitude greater than any difference between C and perl. what problems are you having with the perl version? shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 ...yours is not the less noble because no drum beats before you when you go out into your daily battlefields, and no crowds shout about your coming when you return from your daily victory or defeat. --Robert Louis Stevenson
Re: Howto
Wouldn't the person on the help line be just a bit negligent if they failed to ask. Do you have a learner's permit and are you seated next to a licensed driver over 18? No, I'm sorry, I really don't think it's GM's responsibility to make sure that everyone using their product is legally entitled to do so and is personally qualified to do so. In particular, I don't want GM to give me a driving test before they allow me to purchase a vehicle. Let me ask you this. If you got into an airplane, a Cessna 150, and I handed you a key, could you start it? Is the key what starts it? Should you turn it like a car key? Is there a difference between turning it left or right? No, I couldn't. Which is why I would not get in a Cessna 150 and attempt to fly it. I'm not fucking qualified to do it so I'm not going to attempt to do it. Can you grasp that concept? If I wanted to learn, I'd contact a qualified flight instructor who makes a living teaching people to fly. I would not post to the cessna-lovers mailing list and ask for instructions on how to start the engine. Incidentally, there are a number of qualified qmail instructors listed on www.qmail.org who make a living teaching people how to use and install qmail. shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 ...yours is not the less noble because no drum beats before you when you go out into your daily battlefields, and no crowds shout about your coming when you return from your daily victory or defeat. --Robert Louis Stevenson
Re: Howto
It's understandable that as a flying newbie, you would think that handed a set of keys, it would be "up to you" to know how to use the plane. I would? I know that planes are fairly complicated and dangerous pieces of machinery and that a pilot's license is required to fly legally in most parts of the world. If you or anyone else gave me the keys to a plane and said, "Take off," I'd politely return the keys and say no thanks. On the other hand, if someone held a gun to my head and said "Fly the damn plane," or if I was stuck on a desert island with just myself and the plane, I'm pretty sure that with a little work on my part, I could probably figure out how to start the engine and get the plane off the ground. In this case I'd have no choice but to figure it out for myself. Perhaps I wouldn't be able to land it, but given the choice between zero chance and some chance I'd give it a shot. Installing QMail is much closer to attempting to learn to fly. The Installing qmail is nowhere near as dangerous as learning to fly. Flying requires not only knowledge of theory but a large amount of practical skill, and a lack of skill has serious consequences when learning to fly. My guess is that the population in the U.S. of people who don't know what they need to know to install QMail as is on a system with a firewall already installed without assistance, and the population of people in the U.S. who don't know how to start a Cessna 150 even when handed a key, without assistance are very comparable. That doesn't mean that installing qmail is comparable to learning to fly a Cessna. shag
Re: Howto
Question: since, as you say, every competent system administrator needs to know the syntax of the base networking deamons his system uses, why don't you save us idiots some time. The following could be included in the QMail documentation since it is required knowledge. NO. Why don't YOU save US some time and read the manuals for your system first? Why is it OUR responsibility to tell you everything you need to know first? Do we need to teach you to read? To type? To learn how to use your own system's documentation? Shouldn't that be YOUR problem? "To get the syntax of any system daemon, for example inetd, type "man inetd" at the system prompt. What if I don't have inetd installed on my system? That's not such a silly question anymore, given people's feelings about security and the crappiness of inetd. Plenty of people haven't run inetd (myself among them) and there are systems that ship without inetd. Not many, sure, but they're out there. What if the man pages are screwed up or not installed? At what point will you stop telling the user the answer and just tell him that he'll need to know the answer before proceeding? Here is a list of the base network system daemons, including firewall daemons you need to know the syntax of to install qmail: 1) inetd "Firewall daemons" really don't have anything to do with qmail directly, and inetd isn't necessary for qmail to run. Also, what happens when you "need" some daemon on one system but not on another? Why don't you fill in the rest Adam. This sounds like a REALLY useful list, that would be useful to anyone on the list. I wish I had such a list beforehand. I wish I had such a list now. That's really great. I'm glad you think it's useful and that you wish you had it. I wish I had a million bucks, but sending emails with wishes isn't gonna get it done. If you want that list maybe you should work on it yourself, although plenty of other people have posted FAQs and checklists in the past that you might find somehow useful if you bother to look. shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 ...yours is not the less noble because no drum beats before you when you go out into your daily battlefields, and no crowds shout about your coming when you return from your daily victory or defeat. --Robert Louis Stevenson
Re: New qmail list et al
The whole point with setting up an adjunct mailing list is this: 1) The actual topicality of this list is fairly wide in scope, anything to do with QMail, it's installation, installation quirks, QMail interactions with other programs not in a Qmail tarball or RPM, QMail usage, getting QMail to work with various mail clients. "Anything to do with qmail" is a subjective term, and as recent discussions have made clear it can be extended to cover just about anything. Sometimes people ask questions that simply can't be answered without going off on some weird tangent that really has nothing to do with qmail, MTAs, or even general system administration. At that point, someone else steps in and says "Sorry, we can't really answer that here, you'll have to either ask someone else or go figure it out yourself." I don't see anything wrong with that. If you want to use the help available from this list you'll have to take the vinegar with the honey. 2) There is a reasonable supply of folks who have taken it upon themselves to claim that the scope of this mailing list is very very narrow in scope. DJB set up the list in the first place, so I'd say whatever he says the scope of the list is, it is. Given that he doesn't post too much though, and that the list is unmoderated, I'd extend that to say that the people who post here most often and know the most about qmail are the ones in the position to determine the scope of the list. As best I can tell, they all want to keep the scope of the list narrow. Again, nothing wrong with that. There are a zillion mailing lists out there that all have a narrow scope. That's so you can find the information you want when you need it rather than having to sift through a bunch of crap. 3) There is an insulting tenor to many folks on this list which seems to be cultural, as if there is a qmail list culture which prizes rudeness and insults. This reminds me of this guy I know on a chat network that I help run. Every day he comes on with utterly rookie questions. He's at work trying to get some task done and he comes onto chat crying that he can't figure out how to do it. For a while we put up with him and just answered the questions since they were so easy, and we figured he was just a newbie and needed some help. But lately it's become more often and more routine, as if we're only there to help him solve his problems. Now we chide him first and ask him if he's actually tried to solve the problem before asking for help. Forgive me if I see you acting the same way, but too many people post to this list without so much as raising an eyelid to look at their screen and attempt even a cursory inspection of the documentation and resources available online. The questions from and attitudes of those people back up that assumption all too often. I will post to the ezmlm list the questions relating to it's improved setup. I'd like to do the following: 1: Forward all mail (moderated) from the qmail crypto list to my list. That will make a delay, and not all emails will get through. You're going to moderate the [EMAIL PROTECTED] list yourself and repost it to your own list? Shrug. What makes you think I want to see your moderations of the list? 2: Have all qmail crypto mailings marked as such (If that can be done) Sure it can. I'm not going to tell you how but I can tell you that I know how. 3: Make a subscription announcement specifiying the broad topicality of my list and the prohibition of rule enforcement emails. So there's only one rule, that you're not allowed to enforce any rules? Sounds like a blast. What happens if I break the rule? Do you get kicked off the list too? shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 ...yours is not the less noble because no drum beats before you when you go out into your daily battlefields, and no crowds shout about your coming when you return from your daily victory or defeat. --Robert Louis Stevenson
Re: Load simmulator for testing qmail
Microsoft has a tool called InetLoad that does some basic load testing. While it only runs on Windows NT, it is free and it's worked pretty well for us. It has the capability to test various services besides just SMTP, and includes some basic scripting commands. You can find it at: http://www.microsoft.com/msdownload/inetload/inetload.htm shag - Original Message - From: Amit Vadehra [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wed 26 May 1999 5.20 Subject: Load simmulator for testing qmail HI, I need to find a load simmulator that will pump mails to a particular id or a set of ids that to check the the load generated by pumping that many mails at one point of time and how qmail handles it. We need something that will pump mails of different sizes and types so that we can test the total email infrastructure. Qmail is on Linux ( redhat 5.4) . Can one write some kind of a script that you do the same. Please let me know at the earliest. Thanks Amit Vadehra
Re: failover for an NFS mounted maildir spool?
sigh, after further testing i realized it was something else. yes, the
failover works fine if the mount isn't there. thanks for your help.
i do have one question tho - what happens to qmail-local processes that are
in the middle of delivery when the mount goes down? will they block until
the mount is back up?
thanks-
shag
=
Judd Bourgeois| CNM Network +1 (805) 520-7170
Software Architect| 1900 Los Angeles Avenue, 2nd Floor
[EMAIL PROTECTED] | Simi Valley, CA 93065
To ignore evil is to become an accomplice to it.
-- Martin Luther King, Jr.
- Original Message -
From: Jeff Hayward [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, April 28, 1999 2:08 PM
Subject: Re: failover for an NFS mounted maildir spool?
On Wed, 28 Apr 1999, Racer X wrote:
What I think is happening: qmail-local attempts to change to the root
path,
and the chdir for THAT fails because the NFS mount is down. Around
line 90
in qmail-local.c:
if (chdir(dir) == -1) { if (error_temp(errno)) _exit(1); _exit(2); }
Now according to the documentation, temporary failures are supposed to
have
an exit code of 111, but for the moment I'll assume the "error_temp"
stuff
is working as it's supposed to. The problem then becomes, why is
qmail-local apparently interpreting the error (NFS read timeout?) as
permanent and not temporary?
No, that's the code in maildir_child, which is exiting a subprocess
of the delivering qmail-local. It would probably be helpful to set
up a test bed to replicate the problem and do a system call trace of
qmail-lspawn and children to see what's actually going on.
If it really is bouncing immediately on NFS failure it shouldn't be.
It doesn't here.
-- Jeff Hayward
integrating patches into the distribution
so we can all see the huge number of patches that are listed on www.qmail.org, and i'd be willing to bet that anyone who has used qmail for more than a day or so has had to use at least one of those patches. i'm not particularly against the idea of patching my software to make it meet my needs. it is kind of a pain, but once it's done it's done and i don't have to worry about it. the only problem i have is, let's say there's a bugfix or cosmetic improvement to qmail at some point and the main source is changed, then i have to repatch and so on. i'm not going to attempt to say which patches "should" be folded into the main distribution, nor if any patches should be folded in at all (or, because of the possibility of licensing on some patches, whether they even CAN be). i am, however, curious as to how djb views these patches, and whether any of them will be integrated into the main distribution anytime soon. it might be interesting if people had a way to rate the usefulness of various patches, both for general usefulness and how well the patch integrates into qmail (that is, whether it should really be a patch or a separate program). just some random thoughts as i sit here late. shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 To ignore evil is to become an accomplice to it. -- Martin Luther King, Jr.
Re: QMail Book
i asked someone at the o'reilly booth last week at spring internet world in los angeles, the street date she gave me was i believe 1 sep 99. shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 To ignore evil is to become an accomplice to it. -- Martin Luther King, Jr. - Original Message - From: Jim Beam [EMAIL PROTECTED] To: Qmail (E-mail) [EMAIL PROTECTED] Sent: Wednesday, April 21, 1999 8:02 AM Subject: QMail Book Does anyone know the expected release date of the QMail book? I want to add it to my collection :-)
Re: poor documentation example
Uh, you're kidding, right? I think the assumption is that you won't be messing around with compiling a new mail server (or anything else for that matter) from scratch if you can't even figure out your compiler. I've yet to find a stock system with development tools installed where "cc" didn't invoke the compiler. shag Solaris? QNX? HPUX? AIX? Thank you Cris, for illustrating one of the prime shortcomings of all documentation ever printed - it can't force anyone to read, just as I can't force you to read my message before you typed out a reply. Should I have put "with development tools installed" in all caps? I'm personally rather tired of this thread, as it seems to be mainly between a) people who are too lazy to do a little research but evidently have lots of energy to bitch, and b) people who have no sympathy for those people in group "a." I apologize for continuing the thread but I felt this message might illustrate to group "a" exactly WHY they get no sympathy. shag
Re: poor documentation example
*sigh* You just don't get it... do you. I have a standard compiler set up. I have gcc. I do not have cc. ahem. earlier you were complaining about "cc" being installed on solaris but not working because hey, guess what, it WASN'T really installed. now you are saying that you have a "standard" compiler setup involving gcc. gcc is not a "standard" compiler on anything but linux or *bsd, and on those systems it's set up by default so that "cc" invokes "gcc", which means that your argument about "cc" not working doesn't really hold water. if you want to play a game of semantics, you'd better get your facts and your words straight. shag
Qmail for NT again
Sorry for not jumping in earlier, I was out of town. Anyway, I'm very interested in the idea of running qmail on NT. A couple of people have pointed out that there are some places where NT comes up short as compared to (for instance) Linux, and also that some real reworking of qmail might be necessary to get it to run on NT. That said, there are some places where Linux comes up short as compared to NT. I don't want to get into a holy war over this so if you disagree with the preceeding statement mail me privately, but I can think of some good reasons to run qmail on NT, and I'm of the opinion that any architecture changes can be done with a minimum of fuss and quite possible modularized in some fashion to make it easier to keep source trees in sync. There is a lack of a good, stable, highly configurable, fast, and free MTA for NT. There's a number of things out there for NT that fit a couple of these, but nothing like qmail. NT may have its quirks, but it offers a lot of the features and services of high-end Unix systems while running on commodity hardware. I've been sort of toying with the idea of a port to NT, but I wanted to see if there was any interest or work being done on this yet. So if anyone can give me any info on any current development efforts, I'd like to know about it. Failing that, I'd love to hear from you if you're interested in helping out with my own effort. shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 To ignore evil is to become an accomplice to it. -- Martin Luther King, Jr.
Re: Qmail mailing list and ReplyTo:
The problem (as I see it) is that there is no requirements or even guidelines for MUAs. How's about we get all the mailing list manager people together, and bash out a set of requirements that a mailing list-friendly MUA will have. Then we either find a group to publish them, or else create our own group, and publish them ourselves. But there ARE requirements and guidelines for MUAs. They're called RFCs :) Of course, I know plenty of people choose to ignore RFCs. I can offer some suggestions: * Publicize it as much as possible that XYZ Company makes defective software, or if you can't say "defective" say "non-compliant with generally accepted Internet standards". * Get companies (starting with your own) to adopt RFCs or similar as real standards, bound by contractual agreements with an industry association. Consumer electronics companies have done this for years. Everyone's VHS players read tapes the same way. Everyone's CD players read CDs the same way. * Refuse to help people who insist on using broken software. This is a matter of principle more than anything. The minute you start patching your good server against their bad client, you've lost the battle and it's only a matter of time before they ask you to fix this, and this, and this, and... * If that's not an option, support only the stuff you have to and make it clear that in the future you won't be supporting broken code. * If you're an ISP, don't distribute crappy software. Find something free or tell your users what works and what doesn't. I have no problem with software that has extra features to be able to take advantage of more featureful servers. But those clients should be able to handle servers without the features. shag
Re: Three solutions for spam
That's not what I hear. I hear some people arguing that mailservers on dynamically assigned (i.e. anonymous) IP addresses are suspect. I hear them give statistics explaining *why* they consider them suspect. This is not nearly so strong a claim as the one you say is being promoted. I'll be more than happy to argue that mail servers on dynamically assigned addresses are suspect, or at least should be considered untrusted. This does not seem like too big a stretch to me, nor does it seem like something requiring a lot of justification. I don't see how you can consider dynamic addresses anything BUT suspect, considering that in the space of 30 seconds one host could be replaced by another. Would you trust an rsh connection from an dynamic IP? I absolutely agree that lots of legit mail gets transacted on non-ISP mailservers. Nobody, in my memory of this conversation, has disagreed with this. I don't disagree with this either. But I do posit that mail from a dialup is more likely to be spam (based on my experience anyway) and also that one of the main sources of spam is unblocked dialups. shag
Re: Three solutions for spam
if you didn't sound so unpleasant i'd be more sympathetic to your premise. however that aside i'll just observe that, like many people you're making assumptions that work for you but might not where someone doesn't have a (reasonable) choice. I don't believe there are any places where someone doesn't have another reasonable choice. The only possible exceptions to this are areas where local telcos still have legally-enforced monopolies on all facets of communications service. To those people, I'll say I'm sympathetic to your plight, but if you expect me personally to do anything about it, you'll be waiting a long time. All I can suggest is to work within your laws to deregulate your telcos, or move to a more enlightened country. i could say that you're whining over your technical inability to find a solution less ham-fisted than the one you've chosen but it's apparent that you can only see the world through holier-than-thou-isp tinted glasses. it's a common problem that when you make hammers for a living every problem starts to look like a nail. And I could say you're a typical end-user who doesn't really have any idea about the technical, legal and financial issues involved, and that your own ignorance leads you to believe that I don't know what I'm doing and that you could do it better. I'd be more than happy to see whatever other solutions you have that will accomplish the same goals. I noticed that you didn't bother to offer any here, despite the fact that you think I could use some help. Perhaps you're a consultant looking to sell your services? shag
Re: Three solutions for spam
take russ saying he objects to anonymous spammers. i'm on a dial-up but it doesn't have ``anonymous'' spammers and they persue spammers that use their service aggressively. but i didn't hear anyone say ``I'll fix anonymous spammers.'' i hear folks saying ``Let's screw technically sophisticated users with particular desires that don't connect to my ISP''. I think we're arguing two different things here. When I'm talking about blocking dialup users, I'm talking about preventing my users on my network from sending mail directly out. I'm not talking about using the DUL, or RBL, or anything else to prevent inbound mail. As a matter of policy, we don't block or filter any inbound mail, except for addresses we've had particular and consistent problems with. I'm not sure who's on which side here. shag
Re: Three solutions for spam
No, it gives you recourse when they don't. The difference means that the service will require lots of babysitting. Or a deposit. Requiring a deposit would probably prevent a good bit of spam. Unfortunately market conditions make it impossible to do so and compete with other ISPs who choose not to require a deposit. shag
Re: Three solutions for spam
There are a growing number doing this already. Some don't and charge a hefty "cleanup fee" to the luser's credit card (don't know the details if anyone's tried to dispute the charge). Legally I don't know how valid this is. I suspect that it would be trivial to have this waived as "dispute with merchant." This can adversely affect the merchant's ability to use transaction clearing services (it's hard enough to get a merchant account in the first place), so it's not really a workable solution. Also, asking for a credit card up front for a "free trial" tends to scare customers. And, of course, this doesn't cover people who pay by check or invoice every month. Sad but true. One day it may very well get down to Dan's idea of prepayment for mail. I've tried something similar with telemarketers, asking them for a PO number prior to listening to their spiel stops them in their tracks! I'd really like to see a specification for this, something concrete and reasonably simple to install. I'd also be interested to know if anyone's thought of setting up email peering points, analogous to the NAPs in major cities. These peering points could have their own rules, and could use a new protocol without affecting the Internet as a whole. shag
Re: Three solutions for spam
Clearly different. Dial-up's are usually too much trouble for an ISP track who was using what when. You know who's responsible for a university faculty machine. (I'm aware of the student problem; my wife is a university faculty member.) The number of spams I get that I can identify as from university faculty machines is zero. I get them on occasion from open University relays that are identifiable as mail relay machines. If DSL lines are accountable, then they won't be major sources of spam unless the ISP that controls them deliberately allows spam. I want to comment on this and make sure everyone is aware of WHY it's hard to track who's doing what on dialup. It is certainly not too difficult to track when a user signs on. Obviously they have to authenticate somehow and you can tell when they do that. Usually you can tell when they log off too. Assuming you're using Radius, this is all a no-brainer. It's also pretty trivial to log what IP address they were given, how long they were on for, how many bytes they transferred, which particular modem port they used, what speed they were connected at, why they disconnected, caller ID information, etc. Some of this is dependent on your network hardware, but things like the address and connect time are pretty common. (*) This seems like a lot of information but in reality it's useless for tracking a spammer. If the spammer connects directly out to an open relay, there's nothing you can do short of sniffing his traffic. The victim may send you a log file saying who connected and at what time, but those logs can't be reasonably assured to be authentic. If it comes down to someone on the outside purporting to have logs catching someone spamming, and my user says they didn't do it, I have to take the side of the user. On the other hand, when the dialup user is forced to go through my mail server, a number of countermeasures become possible. Most spammers are too dumb (or desperate) to slow down their mail, so a simple "uptime" check every 5 minutes, coupled with a pager alert, checks most problems before they can really start. The logs are authentic; I trust my own servers, and I have my routers and dialup servers set up so that spoofing IP addresses would be next to impossible. I can also go into the queue and remove spam that hasn't gone out yet. So as an spam deterrent this is pretty effective. I wouldn't mind putting all this up on the web page for people to see (although I don't know whether they'd look). Something like "we WILL catch you in a hurry, and we WILL delete any spam that's in our queue, and we WILL have logs if we choose to file a claim for damages (which we can do under California law)." shag (*) I would like to point out that although we don't use any of this information in anything other than an aggregate format to track capacity requirements, and we never release it to outside sources, your ISP may not have the same policies.
problems with list?
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. If no one else has had this problem, feel free to ignore. I don't have any mail filters set up but I suppose it could be some problem with our mail server, but I'm feeling lazy today so before I go look through all that stuff I figured I'd bother everyone here :) Feel free to mail me off the list. Thanks- shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 To ignore evil is to become an accomplice to it. -- Martin Luther King, Jr.
solutions for spam
There is no such thing as the "right" of a user to all the services an ISP provides. The user is entitled to what he's paid for. That's it. If the ISP wishes to charge extra for certain services, or to refuse to offer certain services, that's that. The customer is free to go elsewhere. This is not "prejudice", "racism", or any other silly term like that. It's "business." Whether or not you think certain policies will hurt my business is your opinion, and although you're certainly entitled to it, you're foolish to say that it IS hurting my business. I've got the marketing information and the analysis of our user base to prove the facts. If you still think you're right and I'm wrong, you're free to set up your own ISP and offer any kind of relaying services you want. A number of people have suggested that blocking direct outbound mail delivery somehow violates RFCs by deleting mail, or causes mail to be lost, or... Refusing connections is well within the rules of every RFC I've ever read. Very few here have even suggested that mail be accepted and then deleted by the server, instead of just bounced or refused. For those of you who have an "unreliable" ISP who tends to lose your mail and still refuses to allow you outbound access - I have no sympathy for you. Go find another ISP. It's your own money you're wasting staying at the ISP who won't offer the services you want. I refuse to care about your own foolishness in where you spend your money. If you want a particular service, ask for it and offer to sign a contract with the ISP. If they won't do it, go elsewhere. No one here has claimed that any spam policy is a panacea. Most of us who actually run these large systems for a living will readily admit that fighting spam is a big pain in the ass and we'd rather not have to do it. But what we want to do really doesn't matter, because we have to fight it to at least some extent. We're not trying to hide our countermeasures. Admittedly, we don't advertise in big letters "we block spam" but if a customer calls and asks about our policies we'll gladly explain them. We don't mind that the spammers know our countermeasures; they'd figure them out anyway and it makes them keep trying different things we may not know about. In the absence of any real legal protections (and I mean practical ones that actually discourage this kind of behavior) there will ALWAYS be spammers. I'm not ready to admit that the problem is so bad that we need vague laws criminalizing "commercial email," but I'm not going to wait around while people take down my mail servers either. shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 To ignore evil is to become an accomplice to it. -- Martin Luther King, Jr.
Re: Three solutions for spam
Of course there is. Blocking port 25 for all their dialup lines is a simple router configuration. Re-enabling it on a customer-by-customer basis on dynamic dialups requires software to interact with the terminal authentication server that they'd probably have to write themselves. Wrong. It simply requires you to use Radius and network equipment that allows you to send back filters in your Radius authentication. Neither of these are esoteric or hard to do, and are the rule, not the exception, at any ISP with more than a handful of users. Lots of people scream loudly at an overworked ISP about spam from their dialups. ISP could (a) improve their tracking and reporting measures and their abuse staff and cancel spammer accounts faster, What exactly did you have in mind to "improve tracking and reporting measures?" Tracking and reporting is not the problem. Tracking is trivial for anyone who keeps dialup logs; rest assured that people who get spammed will report it to you. The point is not to cancel spam accounts "faster;" the point is to keep the crap from going out in the first place. (b) spend lots of time implementing a scheme where they can give their good customers the same service as they had before, You've lost me here. or (c) just do something fast and quick that reduces service for everyone in a way that 95% of their customers won't care about and that will get the anti-spam folks off their backs. Over 99% of typical dialup customers have no need to use anything but the ISP's mail server. I'm basing this number on my 4 years of experience doing contract and full-time work for 5 ISP's in 3 major metropolitan areas. I'm willing to admit that the number might be lower for other areas or other ISP's but I think 99% is a safe bet. The 1% that do care can either be provided with the service they need or (usually) talked out of it by simply explaining the nature of the service they're looking for. Some people have concerns for privacy but fail to realize that merely avoiding our mail server wouldn't keep us from snooping anyway. Others run Linux or something with sendmail and just don't know how to set up their machine properly. It's worth an hour of my time to keep a customer happy and educate them on how to better run their system. The notion that ISP's implement these policies as a way to "screw" the customer is foolish. These policies help the ISP become a better net citizen, provide a higher level of service to their customers and thus increase the value of the service. shag
Re: Three solutions for spam
* It takes a lot less time and effort to figure out when someone is spamming and who they are, since everything is occurring on your mail server. This is not a benefit to the customer. False. It saves time (read: money) on the admin side of things, allowing you to do other things with the customer's money than try to figure out when people are spamming. * It allows the ISP to take a pro-active role in spam prevention. It's fairly simple to write a shell script that checks the mail queue every few minutes, or sees how many connections occurred, and send an alert based on that. This is not a benefit to the customer. False. See above. All of these measures benefit the customers as much as the admins, in terms of the savings in time and resources needed to deal with spam. No, they don't. They benefit the admins in the amount of time and energy they have to spend dealing with outgoing spam, something that in a well-run ISP the legitimate customers of the ISP should never notice. Huh? Time and energy == money. If the ISP is spending all its time and money watching out for spam, they don't have any left to add new features that customers want. Don't fool yourself. The benefit to the customer in blocking port 25 outbound is basically nonexistent; it's entirely about administrative resources devoted to keeping one's site from abusing the Internet. It may be necessary, but you can't sell it as a feature. Methinks you've never actually worked in this business. Perhaps you can't "sell" the feature, no. But it makes the business more efficient and competitive by taking better advantage of scarce resources (and yes, resources are quite scarce in this industry). This is a Good Thing for everyone involved. As for the "nonexistent" benefits, I think I'll be the judge of that. shag
Re: Three solutions for spam
Wrong. It simply requires you to use Radius and network equipment that allows you to send back filters in your Radius authentication. Good, I'm glad to hear that it's improved. (It certainly used to be the case that this was hard.) So how many ISPs are going to be willing to do this? The cost that I was talking about is not only programming effort (thankfully apparently not an issue) but also administrative overhead. (See below.) FYI, it's fairly straight-forward if you use a halfway-decent Radius server (that is, not stock Livingston or Ascend) and a backend database for accounting. We use Radiator, a Radius server written in Perl, and Microsoft SQL 6.5. "Administrative overhead" is not a valid point. Any ISP with more than a handful of accounts will have different types of accounts they sell. Static IP, ISDN, POP only, hourly rates vs. fixed rates... Adding a rate class for "relay permitted" is no more bother than any of these other accounts. No, I disagree, because any measure that you use to prevent the crap from going out in the first place *will* result in loss of legitimate mail. This is the inherent problem with spam filtering, and is something that Dan's been rightfully pointing out on this list for a while. I *do* do spam filtering, but solely because there's currently no better alternative. Spam filtering may well result in the loss of legitimate email. Blocking outbound SMTP connections will not, as the mail will never be sent in the first place. The sender is clearly aware of the fact that his mail did not go out. This is very different from seeing mail acknowledged by the remote server and then having it mysteriously disappear due to a spam filter. Let's keep these two techniques distinct. I am pretty opposed to doing any kind of filtering after a message is received, but I'm not so opposed to refusing connections or sending back an error code to mailservers I don't like. The only *real* solution is to provide sufficient economic or legal disincentive (because that's the only thing people actually listen to) to stop spamming in the first place. Cleanup charges, laws that allow people to collect damages... that's what's going to make it go away. But in a world where ISPs routinely give out free trial accounts and certain large ISPs refuse as a matter of policy to even check credit card numbers to see if they belong to people who were previously kicked off for spamming, trying to do anything *real* about spam is almost a lost cause. ISP's don't give out free accounts as a matter of policy; they do it because customers demand it. To be competitive in our marketplace, we HAVE to let customers give our basic service a trial before they commit to it. This is something that a large portion of our customers have demanded before purchasing from us. If we refuse a free trial they will go to someone who will give them one. If you want to turn on port 25 for certain customers on a customer-by- customer basis, you have to implement some sort of tracking for those people, and a procedure for them to get approved, and See above. This is not a major consideration assuming you already have a generic billing/accounting/tracking procedure for other types of accounts. Like I said. And there are a few people who just want to be in control of their own mail. I know I would. I know lots of other people feel the same way. You may be a great, well-run, reliable outfit, but the fact remains that computers fail and things go wrong, often at the *remote* side, and unless you're running your own outgoing mail, finding out about it is a crap shoot. If you're purchasing service from us, that's an implicit assumption that we provide some sort of reliable service. Perhaps it's not guaranteed or insured, but you can assume that either your message will go through or that it will be returned to you with some sort of error code. If you DON'T trust us to handle mail correctly, then how do you trust us to handle your network connectivity correctly? I realize the two things are different, but if you trust us to give you an IP address when you want it then it seems you should trust us to send your mail for you. If this isn't the case, you can lease a line from a backbone provider and do whatever you want. We make no bones about the fact that we are not a backbone. I'm sorry, but this is simply not true. Less is not more. You're providing less service. There's no way to get around that. I'd be a lot friendlier towards people who feel that the realities of spam are forcing them into doing port blocking if they'd quit trying to misrepresent it as a "feature." "Less service" to whom? Because of the time we saved tracking down spam, we were able to bring up a chat server, which our research showed was much more in demand than being able to send outgoing email directly. It's a trade-off, sure, but we've made more of our customers happy with the trade-off. I don't see how an ISP can
Re: Three solutions for spam
But blocking 25 is still not a feature. Nor is it a benefit to the customer. You're arguing that it allows you to spend time providing other benefits to your customer. Fine. *Those* are the benefits to your customers, not the port blocking. And the hard reality of the situation is that that is neither your customer's problem nor *should* it be your customer's problem. The network *they* see is less available due to port blocking, and no matter how many other nice features you can then provide, it's still a reduction in service. As I mentioned before, it's not a problem for over 99% of our customers because it's not a need. You are implying that we are providing less service, merely because we only offer what people need as opposing to offering everything we possibly can. If it's a trade-off, fine. Present it as a trade-off. Not a feature. It's a net reduction in service that you have to do because you don't have enough time and people to do something better. It is not a "net" reduction in service, because we've taken the time savings and put them back into either bringing up some other service or making some other service better. It is therefore a "net" increase in the level of service provided. I'm not *arguing* with that, for heaven's sake. Don't you think I know the sort of shoestring budgets, particularly in terms of staff time, that ISPs run on? Read my messages. You'll find that I have not *once* said that ISPs should not be doing this. I've been saying that it's a damn shame and that there are better solutions that for one reason or another aren't feasible for most ISPs. I *know* why they're not feasible. I'm not claiming you're all lazy bastards or something. You literally don't have enough money or time or legal support to Fix things and this is the next best thing. It's a nice stretch of bathwater to throw out. Okay, well, we all KNOW that it's a shame to have to do this. It's a shame that we need passwords, and session limits, and idle timers, and... But the fact of the matter is that we NEED a lot of this stuff, and that the reasons WHY they suck really aren't relevant when compared to the reasons why we need them. We know why we do the things we do. We don't have to like them, and we're always looking for better mousetraps, but for now, we do have to take certain measures. As such, I don't see your point in complaining if you aren't going to offer some other possible solution. Whether or not the solutions are feasible depends on the ISP evaluating them, so don't assume that your proposed solutions are invalid or unworkable. What makes me mad is when people try to claim that a reduction in service that prevents people from doing things they want to do is a "feature" and that they shouldn't be trying to do those things in the first place. This is just newspeak, and I don't have a lot of patience for it. This is a trade-off, one that has benefitted us enormously while costing us relatively little. It is something we can pass on to our customers in the form of cost savings or additional services. If you can't call this a "feature," at least don't call it a "reduction in service." shag
Re: Three solutions for spam
Sure. It's a false economy. What if the mail doesn't go through? What if the destination host blocks mail from dialups? I wouldn't even begin to consider sending mail directly from any national provider of dialup service (which is what I presume you're using, since you indicate that you're not making a long-distance call). One thing that hasn't been considered - what if you're dialing up through a responsible ISP who doesn't let their users send mail directly out, by blocking outbound SMTP connections from dialups? We did this about 3 months ago after some recurrent and vicious spammers. Since then, we've had exactly 2 complaints about the procedure, both of which were resolved after we informed the customer that we did this as an anti-spam measure. I had my reservations about this policy at first, but given the problems it's solved so far, I must say it's been a good move. It forces spammers to go directly through our mail server, where we can keep an eye out for behavior that looks like spam. shag
Re: Three solutions for spam
Is this legitimate ? I mean, I am trying to use a mail host for which I am fully allowed to (Hell! I am in charge of the other mailers) and am being blocked. When my primary internet account was down, I was unable to send mail for 3 days !!! Then you've chosen the wrong ISP as your "backup". Either get a more reliable primary ISP or find a backup that allows you to use the mail sending methods you use. As someone else mentioned, it's generally not hard to get an exception if you really need it (we've done this for customers on DSL and static dialups). To me the blocking of port 25 is more of a CYA for the ISP. Nothing more, it benefits no one but the ISP. I can understand why an ISP would do it, but there must be better mechanisms for blocking spam Not true. Blocking port 25 benefits the customer as well: * It makes it far less likely that your dialup pool (or, for that matter, your whole net block) will end up in a blackhole list somewhere. * It takes a lot less time and effort to figure out when someone is spamming and who they are, since everything is occurring on your mail server. * It allows the ISP to take a pro-active role in spam prevention. It's fairly simple to write a shell script that checks the mail queue every few minutes, or sees how many connections occurred, and send an alert based on that. All of these measures benefit the customers as much as the admins, in terms of the savings in time and resources needed to deal with spam. Customers and business partners also will look more favorably upon an ISP that takes an active role in maintenance and spam prevention. I can speak from experience on this one. shag
Re: Three solutions for spam
Wouldn't that require the ISP to have the ability to change their packet filters on the fly (since it is an ISP where I get a random IP) ? Not if you do your authentication via Radius, which can send back attributes and sometimes filters on a per-user basis. It does, however, depend on your network equipment. I know Ascend and USR dialup equipment can do this; dunno about anything else. shag
using dot-qmail files with virtual domains
We have a qmail cluster of machines that handles all mail for both our "main" dialup domain (cnmnetwork.com) as well as our virtual domains. Because the main domain is so big, we've broken it out into a multilevel structure, so that mail for [EMAIL PROTECTED] will go to: /mailpath/vpop/cn/cnmnetwork.com/sh/shag/Maildir This all works, and to simplify things we do the exact same thing for our virtual domains. cnmnetwork.com is therefore essentially just another virtual domain on the box, and we don't really treat it any differently (other than having bounces come from [EMAIL PROTECTED]). So here's my problem. I can currently use dot-qmail files to handle mail at a domain level with no problem. I'd like to be able to handle it at a virtual *user* level, however, because the cnmnetwork.com domain currently has over 7000 users and at the current rate of growth will hit 10,000 by the end of January. To be able to handle forwarding/autoresponders/lists for the users in this domain, I currently have to put all the dot-qmail files in /mailpath/vpop/cn/cnmnetwork.com, which means all those files pile up in that directory. I'd much rather be able to put the files in the individual user directories and let the users manage the files themselves. I'm thinking that I could probably do this with a dot-qmail-default that changed directories based on the username and opened the next dot-qmail-default that it found, but I'm not quite sure how to go about this. Does anyone have any suggestions? If you need any more information let me know. I'll go ahead and add that the current dot-qmail-default looks like: | /mailpath/vpop/bin/vdelivermail BOUNCE (where BOUNCE is the address to deliver bounces to, or the keyword "BOUNCE" to return to sender). So I would guess that the change would just be some fancy thing to make it re-evaluate another directory for a dot-qmail file, but I'm not sure just how to do this. Thanks in advance- shag
Problem with mfcheck patch on www.qmail.org
I believe there is a bug in the mfcheck patch on the qmail Web site. I noticed a strange interaction between one of my mailing list servers and our main mail server. qmail generated a double bounce because of a problem with ezmlm (nothing major). It attempted to deliver the message to ~alias/dot-qmail-postmaster, which is forwarded to a remote address. qmail uses #@[] as the envelope sender on the message, but this is refused by the main mail server with the mfcheck patch, saying "envelope sender domain must exist." Now, I suppose that forwarding double bounces to a remote machine may not be the best practice, and I only do it on this one machine. However, I think that the mfcheck routine should check for the special sender address. It seems kinda silly that qmail should refuse its own "special" address, and besides that the mfcheck routine already allows through (yes, I know this is required anyway). I'm aware of the environment variable setting, which I will use for the time being. shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur.
