Re: Mail Protocol Issue: BCC only?
Scott Sharkey [EMAIL PROTECTED] wrote: I asked a few weeks ago about known issues with qmail not delivering BCC messages. None I know of. After investigating further, the client is claiming that the messages that are not delivered have ONLY a BCC (no to, no cc)...So, in theory, a message with a BCC only would have no To:, CC:, or Bcc: headers, at least in some cases. Dan thought of this. He puts an empty list in the "cc:" field, so his messages are definitely valid. It is possible that the client's MTA is broken, and can't handle empty recipient lists; they look like this: "CC: recipient list not shown: ;". Len. -- Moral: Don't assume that you can omit random pieces of punctuation. -- Dan Bernstein
Re: Off-Topic: Maildirs as folders
"Chris, the Young One" [EMAIL PROTECTED] wrote: Quoted from Len Budney: Emacs is not a command line interface. Although I often use Emacs to read a buch of messages, I don't feel like taking 42 times too long to read just *one* message. Okay, go for nmh then (with no frontend). That's hopefully command-line enough, even though I've never used it myself. :) That's where this thread started. I do indeed use MH mail, as well as front-ends to MH like Mew, GNUs, xmh, etc. And I really miss vmh. However, MH is not reliable; concurrent deliveries can destroy .mh_sequnces and (I've heard) can clobber messages. I want to put together a CLI which uses maildirs as folders, in the spirit of MH (but not necessarily a clone). I posted to this list to see if there was any interest. There is a little, but not as much as I'd rather hoped. "Maildir MH" is a non-trivial project; it will be a failure (in my view) if it doesn't fully support concurrent folder access. Anyone interested in discusssing the subject can join the mailing list; send an empty message to [EMAIL PROTECTED] and follow the directions in the reply. Also see http://www.pobox.com/~lbudney/linux/mdmh.html. Len. -- The concept of ``security-critical'' depends on what you're trying to protect. -- Dan Bernstein
Re: Off-Topic: Maildirs as folders
"Chris, the Young One" [EMAIL PROTECTED] wrote: Quoted from Len Budney: I want to put together a CLI which uses maildirs as folders, in the spirit of MH (but not necessarily a clone). I'd be interested...Yes, I'll join the mailing list. Cool! I must get to grips with how MH works, but after that it shouldn't be hard... I hope. Well, not too terribly hard. Hmm...it's just now occurring to me that not many people are already familiar with MH. It was the default at Syracuse University (until they switched to Pine), so I sort of assumed that every one had used it at some point in their lives...Don't I feel like a dinosaur. The paper that Peter van Dijk mentioned is "How to Process 200 Messages a Day and Still Get Some Real Work Done"; it's available from http://www.nb.net/~lbudney/linux/projects/mdmh/realwork.ps.gz. Len. -- "Accept incoming mail? Changes to inbox will be discarded!" Okay? Cancel? None of the above: http://www.pobox.com/~lbudney/linux/mdmh.html
Re: Off-Topic: Maildirs as folders
"Robin S. Socha" [EMAIL PROTECTED] wrote: * Len Budney [EMAIL PROTECTED] writes: "Robin S. Socha" [EMAIL PROTECTED] wrote: * Len Budney [EMAIL PROTECTED] [000825 20:30]: The problems with that are (1) I *want* a command-line interface... (2) I'd like to see the job done right, once... I don't see the problem, really. Use Gnus http://www.gnus.org/ and you're there. "There" meaning that I'd have an email CLI using maildirs as folders? I was unaware that GNUS was a CLI... Go "xemacs -nw -f gnus" in a shell. Happy reading. Sigh. I'm not sure you know what "command line" means. % runtime show cur /dev/null 0.120 sec % runtime emacs -nw -f save-buffers-kill-emacs 5.053 sec Emacs is not a command line interface. Although I often use Emacs to read a buch of messages, I don't feel like taking 42 times too long to read just *one* message. Advocating emacs to an emacs user, when he happens to want a CLI, is pretty darned annoying. Len. -- The moment you run that, a local attacker can take over your machine. Isn't security fun? -- Dan Bernstein
Re: Off-Topic: Maildirs as folders
"Robin S. Socha" [EMAIL PROTECTED] wrote: * Len Budney [EMAIL PROTECTED] [000825 20:30]: The problems with that are (1) I *want* a command-line interface... (2) I'd like to see the job done right, once... I don't see the problem, really. Use Gnus http://www.gnus.org/ and you're there. "There" meaning that I'd have an email CLI using maildirs as folders? I was unaware that GNUS was a CLI; I thought it ran inside Emacs. Best MUA on earth, anyway. Yes, I do like it. Supports maildir...(tentatively reaching beta status) as a native select method. I can't find anything about this at the GNUS site. Can you give me a more specific pointer? If GNUS supports maildir as a folder, then that makes three such mailers (mutt and Pine being the other two). Note, though, that I'm only interested in mailers which don't break concurrency. I'm still evaluating the choices, but they do things which make me nervous, like using collision-prone file names. It also speaks IMAP, MIME and basically everything else one needs... Although I question the wisdom of mailreaders getting into the MTA/MDA business. Len. -- Run two mailreaders; never lose messages! http://www.pobox.com/~lbudney/linux/mdmh.html
Re: SMTP port 25
"Brett Randall" [EMAIL PROTECTED] wrote: Running on anything other than port 25 is pretty silly considering that all applications and all mail relays attempt to deliver to port 25 on every mail server in the world...Internally, you could do it, but why? There are several reasons why this is done, usually amounting to "security through obscurity". Sometimes an SMTP server on a non-standard port is run as an open relay, so remote customers can forward outgoing mail through it. Sometimes spam checking, size limits, or other policies are waived for an odd-port SMTP server. Len. -- Why is modularity ``wholly unreasonable''? -- Dan Bernstein
Off-Topic: Maildirs as folders
I know there is a recurring thread, "Which readers use maildirs as folders?" The problem is, the answer is always the same: mutt. No other mailer uses maildirs as local folders, although a few can use maildirs as incoming mail spools. (If I'm wrong about this, please let me know!) Yes, mutt is just fine. However, we emacs users are discriminated against; switching to mutt is just not acceptable because it means losing all the rest of emacs's features from our mail reader. Also, fans of MH are out in the cold; there is no command-line interface for handling messages in maildir folders. I believe that the solution is a CLI maildir-enabled mailreader, similar in spirit to MH (but without any defects). The resulting tools should be easily imbeddable into things like Emacs mailreaders (GNUs, mh-e, and brand-new readers). If anyone is interested in exploring this idea, please send an empty email to [EMAIL PROTECTED] and follow the directions in the reply. If anyone knows of such a project already underway, please let me know at [EMAIL PROTECTED] For more information, see http://www.pobox.com/~lbudney/linux/mdmh.html. Len. -- Don't believe anything RFC 1912 says until you've verified it elsewhere. -- Dan Bernstein
Re: Help on smtp and rcpthosts !!
"Xionghui Chen" [EMAIL PROTECTED] wrote: This is real urgent: every time when I send mail via port 25, if the domain of the mail address is not belong in the file control/rcpthosts, it says: 553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1) do this mean that I have to put all my possible rcpt domains in the rcpthots file? i.e, i have to put yahoo.com in rcpthosts, or else I cannot send mail to [EMAIL PROTECTED] No! (New qmail users often become scared about this; don't worry!) The rcpthosts file is only for SMTP connections. SMTP connections are usually for _incoming_ mail. So rcpthosts only lists allowed destinations for _incoming_ mail. Usually, rcphosts will contain the domains listed in control/locals as well as control/virtualdomains, and should all be fully-qualified domain names. But some of your software uses the SMTP port for _outgoing_ mail as well, which is what made you ask your question. The answer is found at http://cr.yp.to/qmail/faq/servers.html#authorized-relay. The magic word is RELAYCLIENT. Hope this helps, Len. -- Do not confuse complexity with security. It is a grave mistake. -- Bruce Schneier
Re: Does someone knows what is this about?
Peter van Dijk [EMAIL PROTECTED] wrote: On Mon, Jun 05, 2000 at 10:48:24AM -0500, Mate Wierdl wrote: More evidence that the person running ORBS is incompetent. He's not. I've spoken to him on several occasions and he is quite clueful. Not to restart another perennial flame-war, but why then does he blacklist people who block his probes? Is it really his intention to provide the service of blacklisting both a) open relays and b) people who disagree with him? If he is clueful, then his ethics come into question. He's better off being thought clueless, in my book. Len. -- Frugal Tip #16: Dry clean your wax paper for reuse.
Re: securing pop3 sessions
"Louis Theran" [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Len Budney) writes: [ using SSH forwarding to tunnel POP3 ] That's a dandy idea. However, once you do that it's not POP3 anymore. Nonsense. What exactly would you call the protocol running inside the tunnel if not POP3? Um, the protocol INSIDE the tunnel is POP3. But the protocol YOU MENTIONED is POP3+SSH. In particular, it cannot be implemented using standard POP3 clients from machines which don't have SSH installed. Which, please note, is what the original poster asked for. Len. -- Frugal Tip #30: Let a large corporation pay you big bucks to tattoo their company logo on your bald spot.
Re: securing pop3 sessions
[EMAIL PROTECTED] wrote: What's the best way on the server side to prevent passwords from being sent as clear text over the network for a pop3 session? I'm afraid the best way is also the only way, and it doesn't exist. You cannot use POP3 without sending passwords in the clear. Len. -- VENONA traffic was broken by the NSA because the Soviets reused their one time pads. -- Bruce Schneier
Re: securing pop3 sessions
"Louis Theran" [EMAIL PROTECTED] wrote: My original comment was merely pointing out that `there is no way' is correct only in a narrow sense. Right; namely, the sense in which the poster asked. He asked for a way to modify the server ONLY, and end up using POP3 without any passwords traveling en claire. I replied that THAT is impossible. Other things, of course, may or may not be impossible. However, if ``most clients'' actually support SSL, then I may have simply been wrong. (I'm not gonna quibble that POP3+SSL isn't POP3, because although it isn't, who cares?) The original poster needs to know the definition of ``most clients'', and probably will have to run two POP3 servers--a secure one for savvy clients, and an insecure one for stupid clients. Unless ``most clients'' is an inclusive enough class. Len. -- It will work, and it's probably secure; but I didn't design it to run setuid, so don't do it. -- Dan Bernstein
Re: I want to leave this list
Troy Frericks [EMAIL PROTECTED] wrote: [footer giving unsubscribe information] Has anybody given an explanation as to why this simple change has not been implemented on this list. Kinds of seems silly that it has not been done, especially given the extra messages not having it generates. Sigh; your post is also a FAQ (though it isn't in the FAQ). The answer is that unsubscribe information is provided in the header of every post (partly because Dan would like MUA authors to implement list-handling functions which can easily read headers automatically). If users will not read the header, they will not pay attention to the footer either. You will probably get replies from people who've subscribed to lists which use footers that way, and they will tell you that the same questions are posted to those lists. Nothing is saved (though some bandwidth is wasted). I once actually wrote to a jackass who did exactly that. He replied that it was a waste of his time to grovel around looking for instructions: all he had to do was hit ``reply'' and post ``unsubscribe'' messages, and sooner or later he would be unsubscribed. It was Somebody Else's Problem (tm). Len. -- Frugal Tip #50: Have everyone in your family agree to share the same toothbrush.
Re: Metering POP related email traffic?
Peter van Dijk [EMAIL PROTECTED] wrote: On Mon, May 15, 2000 at 11:11:17AM -0700, Chin Fang wrote: I have a strong suspicision as of now, based on some casual snoop output reviews, that POP traffic is consuming about 30% of the total email bandwidth usage. Unless people have forwards to more than 1 address, logic dictates that POP3 should be at least 50% of your traffic. This strikes me as a ``Profile. Don't speculate.'' moment. ``Logic'' might argue instead that 30% is about right: one might expect roughly equal volumes of incoming SMTP, outgoing SMTP, and POP traffic, assuming no mailing list servers. The moral: measuring is better. Len. -- Frugal Tip #63: Leave your penny loafers empty. It's cheaper!
Re: ANN: Filtering out already delivered mail
Jozef Hitzinger [EMAIL PROTECTED] wrote: Here's a little tool I made to get rid of unwanted mail already delivered to ~/Maildir/...It's not meant to replace on-delivery mail filtering, but to supplement it. You might also want to look at maildircmd, my addition to the serialmail package. http://www.nb.net/~lbudney/linux/software/maildircmd.html It generally assumes that the maildir is a ``spool'', and that every message in it will be delivered somewhere (Delivering back to the spool is a recipe for infinite loops, of course). Since most MUAs use maildir as a spool, not a folder, you can use maildircmd compatibly with your existing setup. As a fringe benefit, it will automatically generate bounces if you want. Len. -- Frugal Tip #7: Manage a multifamily housing complex in the back seat of your SUV.
Re: Open Today.
Peter van Dijk [EMAIL PROTECTED] wrote: Not listing themselves in the DUL gives other ISPs _not_ the choice of rejecting dial up mail from them. ...rejecting all of my mail, for example. I have no problem resisting stupidity by not volunteering information. Casting it as a choice issue is a red herring. For example, what about my ISPs privacy right? It's nobody's business what runs behind a given IP. Should they also list OS and version, plus modem make and model, in the cracker phoneboook? Len. -- A good business is not always a good purchase--although it's a good place to look for one. -- Warren Buffet, 1983
Re: Open Today.
"Timothy L. Mayo" [EMAIL PROTECTED] wrote: And his ISP won't. :) Especially since I was a dial-up user when the whole "block the dial-ups" discussion started... I must say, I like my ISP! :) One of these days, I'll have to meet Tim and buy him a beer. Len. -- P.S. ezmlm sent you some mail. Read it. Pay attention this time. -- Dan Bernstein
RE: FW: FW: VIRUS PEOR QUE MELISSA II *** Importante***
Kai MacTane [EMAIL PROTECTED] wrote: IOW, this is one of the standard hoax email virus warnings that's been littering the Internet for past six years or more, only translated into Spanish. You mean, I can't find out how to give my cat a colonic? Len. -- Frugal Tip #31: Incrementally reduce your year-to-year operating expenditures while aggressively recognizing unrealized receivables in the current quarter.
Re: Open Today.
John White [EMAIL PROTECTED] wrote: On Sat, May 06, 2000 at 04:30:54PM -0400, Len Budney wrote: (BTW blocking DUL has not interfered with my own email in a couple of years now...) Amazing. In one year, our office ran across: [7 domains snipped] We had to smtproute them all to our dialup provider. A glance at your list indicates I haven't written to anybody at any of those domains in at least a couple of years. If I had, I'd have done what you did, and smtproute-ed them through my ISP (which uses qmail!). I'd also send those correspondents an email explaining why their mail is late whenever I'm on the road. Len. -- Frugal Tip #45: Cheat at cards.
Re: Open Today.
Johan Almqvist [EMAIL PROTECTED] wrote: On Sat, May 06, 2000 at 07:50:44PM +0200, Peter van Dijk wrote: - too much qmail users mail from dialups to this list, so blocking dialups would not be a good thing. It's not very probable that they'd use list.cr.yp.to as their outgoing mail host, is it? No, they use their own computer as the outgoing mailhost. Thus, their outgoing mail originates from a dialup. It wouldn't get through at all if list.cr.yp.to blocks email from dialups. I for one send my mail directly from my laptop. I don't care about religious objections that I shouldn't do that; it saves the annoyance of re-aiming my outgoing mail at the smarthost of whatever connection my laptop is using at the moment. (BTW blocking DUL has not interfered with my own email in a couple of years now. So despite the big talk of folks who use it, I continue to send mail directly from my machine. DUL blocking only works because it is a rarely-taken measure.) Len. -- That's security through obscurity. The more people know about it, the more useless it is. -- Dan Bernstein
Re: accustamp|tailocal|matchup
"David Dyer-Bennet" [EMAIL PROTECTED] wrote: Peter Samuel [EMAIL PROTECTED] wrote: And you editor can't read in the results of a program? I can think offhand of a couple of ways of doing it, but all of them are grossly inefficient and take lots of keystrokes. There may well be an easy way I'm overlooking, too. Nothing exotic, I'm an emacs user. I'm not starting a new instance, I'm visiting the log file from my existing instance. rant ``Nothing exotic, I'm an emacs user''? Emacs? Have you heard the debates whether Emacs was an OS, a shell, or an editor? Have you seen the emacs mailreaders, shell modes, IRC interfaces, and web browser? What you want to do is absolutely trivial in emacs, and you can bind it to a single keystroke. /rant Anyway, what you want to do is absolutely trivial in emacs, and you can bind it to a single keystroke. Len. -- You're repeating the same old ``forks are bad and execs are disastrous'' litany without _profiling_ where your time is actually going. -- Dan Bernstein
Re: Qmail filter for ILOVEYOU
Rodney Edwards [EMAIL PROTECTED] wrote: This has probably been asked already but I've literally just joined. How can I filter and reject ILOVEYOU messages in Qmail? Congratulations! You may be the first new subscriber whose question is at least 1) timely, and 2) not a FAQ! You get a cigar! Any pointers would be appreciated Let me point you to the qmail archive: http://www-archive.ornl.gov:8000/. There have been some quick-and-dirty hacks suggested over the last couple of days, but since I don't run Windows I haven't paid much attention. Searching on ``ILOVEYOU'' should turn them up. Hope this helps, Len. -- Frugal Tip #31: Incrementally reduce your year-to-year operating expenditures while aggressively recognizing unrealized receivables in the current quarter.
Re: shim before final local delivery?
Paul Farber [EMAIL PROTECTED] wrote: Is there a way to insert a shim (or shell wrapper) before qmail-local delivers a local message? Simple; write a wrapper called ``qmail-local'', which in the end exec's the original qmail-local (which you should rename, of course). The interface is remarkably simple. From qmail-local(8): SYNOPSIS qmail-local [ -nN ] user homedir local dash ext domain sender defaultdelivery DESCRIPTION ... The standard input for qmail-local must be a seekable file, so that qmail-local can read it more than once. See? It's a snap. (If you don't know how, I'll do it for a small fee.) It would seem administratively easier to apply these type of filters for a large group of users that way rather than ~/.qmail-default 'ing all the home dirs. In fact this latter ``solution'' doesn't work anyway--unless the users cannot create .qmail files. Extensions for which more specific .qmail-ext files exist are delivered according to those instructions, bypassing .qmail-default entirely. Len. -- Frugal Tip #19: Discover the secret to happiness, then sell the franchise rights.
Re: accustamp|tailocal|matchup
Kins Orekhov [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: And can't you look at them by passing them through tai64nlocal each time? Can you spell "shell script wrapper"? :) I *asked* the list about *some program* which can do reverse time translation for my *already existing logs* - from Local to TAI. Correct. And Peter answered your question: ``Can you spell `shell script wrapper'?'' Translated, he just told you to write a script called ``look-at-old-logs'', which runs tai64nlocal on the old log files, and then displays them to you. Then, whenever you want to look at old logs, you run ``look-at-old-logs'', and voila! The magic happens all over again. That's the wonderful thing about computers: they never get bored. And your response(s) (especially last one) never answered my question. It did. However, to benefit from the answer required some work from you. If you want somebody to do the work for you, pay them. (I'll do it if you prepay, in US dollars. Say, $250 for 2.5 hours work, and if I'm done sooner, I'll refund the difference.) Len. -- Frugal Tip #41: Remember, the best things in life are free. That means if you can resell them, that's a 100% profit margin.
Re: Limit file size--HELP HELP HELP
Shakaib Sayyid [EMAIL PROTECTED] wrote: ...there is one user who wants to send a file thats ~20M. Is there a way to do this? Instruct the user to send it in five pieces. Such a huge email is likely to jam the recipients' POP accounts; they will have to ask their ISPs to delete the message so that they can fetch the rest of their mail. Multiple pieces are less likely to mess things up. Plus, while the recipient is waiting for that hour, at least he will see the message count increase every twelve minutes. If the recipients use windows, and don't have any split/unsplit utilities (available from tucows), then have the user stick it in his web space, and make him pay the over-quota charge for that month. Len. -- Anyone can create an encryption algorithm that he himself cannot break. -- Bruce Schneier
Re: LF Patch
Mike Lichtenwalner [EMAIL PROTECTED] wrote: ...patch qmail (as opposed to the fixcr solution)... I'm staying out of this; it's sure to provoke a holy war. However, do please be aware that the patched qmail _will_ corrupt some messages, in the name of compatibility with software which flagrantly violates the standards. Even if you do adopt the solution you mention, please do consider informing the other postmasters that their software is violating the standards, and at least suggest that they fix their servers. Len. Millersville, PA Hey, we're practically neighbors! -- Frugal Tip #36: Take the stairs instead of the elevator. No, wait -- that belongs on the "How to Develop Steely, Rock-Hard Buns" list. Sorry.
Re: E-Mail Address Harvesting
"Dennis Duval" [EMAIL PROTECTED] wrote: ...I believe they then compare the bounces ( [EMAIL PROTECTED] in this case), against the database of addresses that were sent to... The method here is perfectly correct. Indeed, using VERP there is no need for bounce parsing, so the attack can be trivially adapted to attack ALL mailers. ...resulting in a list of valid email addresses of my users. What on earth do these lists cost these days?!? This method is so astonishingly inefficient that I can't believe there's a positive payoff. (Especially since spam listers can sell invalid addresses if they want--who would ever know?) I wonder if it isn't something else--like harvesting login names for a stupid password crack? I'd be a _little_ less flabbergasted if that were the case. Len. -- Frugal Tip #49: Try owning lots of jewelry, negotiable securities, and tax-free municipal bonds. Many rich people are known to have them.
Re: Multi-RCPT vs. Single RCPT delivery - logic error?
Dave Kitabjian [EMAIL PROTECTED] wrote: Dave Sill: "Say you're an MTA [ sending three messages. you could: ] 1. ...[ send three copies through one connection, ]...then close the connection. 2. ...start three processes, each of which...sends a copy of the message... 3. ...send a [ single ] copy of the message addressed to all three users..." Dave Kitabjian: Clearly, the rank of efficiency is, from best to worst,: 3, 1, 2 That might be true, if the situation you described were complete, but it's not. The MTA handles hundreds (thousands) of messages per day, and in typical situations a very small fraction of them are both 1) the same message, and 2) bound for the same host. For qmail to implement solution #1 or #3 means that qmail must identify any mail traffic it can combine, and then must handle it specially. That takes some work. The extra code becomes a possible source of bugs and security holes. Does it speed qmail up noticeably? No, for several reasons: 1. Only a tiny percentage of email can even potentially benefit from this ``optimization''. Hence, even a large speedup would have a small overall effect. (The only major exception to this is mailing list traffic. If enough of your local users subscribe to a remote mailing list, then it's worth your while to set up a sublist.) (The other major exception, corporate email, isn't an exception at all. Corporate email typically runs at LAN speeds, where the difference in speed is negligible.) 2. Connection caching (strategy #1) is actually terrible for performance, because all mails for a given destination are serialized. They would arrive faster if they were delivered in parallel, which is what qmail does. Connection caching also impairs the remote mail admins' ability to limit throughput to levels his server can handle. If his server goes down temporarily, for example, then you will probably try to shove thousands of emails down his throat as soon as you see he's back up. This effect is what Dan calls ``opportunistic bombardment''; it's why sendmail typically clobbers recovering mail hosts. (After an outage, AOL typically is taken down again, several times, by incredible waves of sendmail bombardment.) Connection caching is also unfair. It means that once you have a connection, you exploit it to send everything you've got. Meanwhile, if the server is near capacity, others are completely denied service. qmail'l parallel delivery, which at first seems more greedy, is actually fairer--admins can easily limit per-site connections, causing qmail to wait its turn. Meanwhile sendmail users hog up connections, forcing their mail through without waiting their turn. 3. Option #3 is mainly harder for the outgoing server; it means that the server has to notice opportunities to combine emails into one message with several recipients. a. There are cases where a server will be fooled anyway. b. Ignoring that, his work will pay off only in a tiny minority of cases. c. This approach also has privacy implications: if I give a message with multiple recipients to another SMTP server, and some of those are BCC recipients, then the upstream server may violate privacy be recording the complete envelope. d. This approach makes things like VERPs impossible. VERPs are why ezmlm can handle bounces so conveniently. They actually have convenient uses for individuals, as well: it lets you map bounces of important emails to the exact address you were sending to (which may not be the address which caused the bounce). So your logic is fine by itself, but it misses the bigger picture of what's going on with email traffic. Len. -- Frugal Tip #4: Keep skipping town two days ahead of the collection agency.
Re: Multi-RCPT vs. Single RCPT delivery - logic error?
Dave Kitabjian [EMAIL PROTECTED] wrote: We had a situation with a customer who was consulting for a college. So every few days, she had to send a 10MB PowerPoint file to about 50 recipients at that college. Under qmail, a separate thread was opened up for each qmail-remote. Warn her, firmly, to send Zip disks by email or to rent space on an FTP server. If she persists, kill her. Then find and kill the manager who would email me 6MB presentations, clogging my modem for half an hour--instead of waiting 45 minutes and giving it to me when I arrived at work. a) That means a total transfer of 500MB rather than simply 10MB. Right! That's not what email is for! Not only your pipe is being abused; the downstream servers are, too. And think of the poor recipients! If they use modems, then they will be _extremely_ ticked at the wait. Worse, many POP servers and/or clients will jam on such large messages, forcing retries. Some will fail forever, blocking receipt of any further emails until someone at the ISP deletes the offending message. This is a MAJOR case for customer education. Len. -- Frugal Tip #65: Get a cushy TMF job where you can get away with making goofy lists like this one for a living.
Re: Multi-RCPT vs. Single RCPT delivery - logic error?
"Len Budney" [EMAIL PROTECTED] wrote: Warn her, firmly, to send Zip disks by email or to rent space on an FTP server.^ Should be ``mail'', of course. My patented ``matter emailer'' is not yet on the market. :) Len. -- Frugal Tip #14: Sell your used Q-Tips as modern art.
Re: sorry, that domain isn't in my list of allowed rcpthosts?
"snowcrash" [EMAIL PROTECTED] wrote: What do I need to do to allow people on diffrent ISPs to send mail through my server to any other domain besides mine? That's called ``relaying'', and if you relay _indiscriminantly_, then you will eventually be abused by spammers, and blacklisted by ORBs. (Just a caution; I know that's not what you're trying to do.) The quickest ``solution'' is to delete control/rcpthosts, which makes you a wide-open relay. (Now reread the caution above!) The second quickest, if you know where your friends send mail to, is to add those destinations to control/rcpthosts. Since they won't be in control/me or control/locals, qmail will do the right thing. (This is only slightly less dangerous than the previous suggestion, unless the list of target sites is quite small.) The best solution is to enable relaying, temporarily, from hosts which authenticate themselves. One approach is the SMTP-after-POP solution; You can read about it at http://www.palomine.net/qmail/relaying.html. That page also gives more information about relaying and its implications. The recommended solution, by Bruce Guenter, is available from http://em.ca/~bruceg/relay-ctrl/ _after_ you read Chris Johnson's page. Hope this helps, Len. -- Frugal Tip #20: Take hostages.
Re: temporary failure warning message
Dave Sill [EMAIL PROTECTED] wrote: "J.M. Roth \(iip\)" [EMAIL PROTECTED] wrote: is it possible to configure qmail to send out a "temporary failure" message or something if mail can't be delivered rightaway? No. But if you're desperate, you can create this feature easily. Write a Perl script which either 1) grovels through the queue directories, or 2) runs /var/qmail/bin/qmail-qread, and sends a report to the original sender for messages enqueued longer than X minutes/hours/days. Some failure messages inbetween would be quite helpful. That's one of sendmail's more annoying features, if you ask me. 100% agreed. Don't even consider doing what I described above. If an email is _that_ time-sensitive, follow up using a phone call. Better yet, write ``Let me know AS SOON AS you receive this!'' inside the body of the email. Len. -- I'm more worried about real security problems than theoretical reliability problems. -- Dan Bernstein
RE: Qmail behind firewall question
Dave Sill [EMAIL PROTECTED] wrote: "Len Budney" [EMAIL PROTECTED] wrote: export QMAILUID NOFILESGID Yes, but there's no need to pass QMAILUID and NOFILESGID to softlimit, tcpserver, or qmail-smtpd. They're only needed by the shell that does the exec, and it expands them before doing the exec. You're right! Thanks for not saying ``Duh!'' Why did I think he was using envuidgid? Those would still be the wrong variables... Len. -- Frugal Tip #7: Manage a multifamily housing complex in the back seat of your SUV.
Re: temporary failure warning message
Ian Lance Taylor [EMAIL PROTECTED] wrote: From: Dave Sill [EMAIL PROTECTED] Anyone who assumes that An Important Mail has been delivered intact and read by the recipient simply because they didn't receive a warning or bounce message deserves what they get. This is a real indictment of the state of the Internet. Not at all. Dave said, ``simply because they didn't receive a warning...'' In other words, you can't assume the message was received, simply because you WEREN'T told that it WASN'T received. You can only assume it was received if you HAVE been told it HAS been received. I hope that someday people will trust the Internet the way they trust the telephone system. I know you got my phone call, because I know I heard your voice. I know you got my fax, because fax machines DO acknowledge when a fax has been received. Email has no _general_ confirmation mechanism, except asking the recipient to ``hit reply so I know you got this.'' Len. -- There are two people at fault in every computer security breach: the attacker, and the programmer who let him in. -- Dan Bernstein
Re: Mailbox/Maildir pop ?
Les Higger [EMAIL PROTECTED] wrote: do i need to convert to Maildir to run pop3d. Yes. i ve got qmail working and have checkpasword working. I have only 50 users using e-mail so i didnt use tcpserver. It's good exercise anyway; you should try it. See http://www.pobox.com/~lbudney/linux/security/telnet-tcpserver.html for a worked-out example: running telnet under tcpserver. Len. -- I'm worried about the applications that should exist, not just the applications that exist today. -- Dan Bernstein
Re: rcpthosts and morercpthosts
"Greg Kopp" [EMAIL PROTECTED] wrote: 1. What is morerecpthosts and morercpthosts.cdb? Is there a limit to the number of hosts that can be in the rcpthosts file? morercpthosts is (as the name implies) a supplement to rcpthosts, which is used by qmail-smtpd to decide whether to accept mail. rcpthosts lists hosts for which qmail-smtpd is allowed to accept email. morercpthosts, if it exists, ``is effectively appended to rcpthosts'' [see qmail-smtpd(8)]. morercpthosts.cdb is created by running qmail-newmrh with morercpthosts as input. You must do this, because morercpthosts.cdb is what qmail-smtpd actually uses. The idea here is to make qmail-smtpd faster IF you handle mail for a very large number of domains. As a rule of thumb, ``large'' means more than fifty. Putting your most commonly used sites in rcpthosts means that qmail-smtpd will usually ignore morercpthosts.cdb. When the client specifies an envelope recipient whose domain is not in rcpthosts, then qmail-smtpd will check for the domain in morercpthosts.cdb as a fallback. 2. Do you think it would be safe to use NFS to mount my /var/qmail/control directory on our backup MX and then use symlinks of the nfs mounted rcpthosts file to the local file? For the number of domains I have, I want to avoid having to edit multiple files everytime we add one or delete one. Should I also link morercpthosts and morercpthosts.cdb? If you do this, then the two MX hosts will behave _identically_. In particular, qmail on the backup MX will try to do local deliveries because of the shared copy of control/locals. If that's what you want, then you _can_ do this; just be very sure its what you want. To my little brain, though, it doesn't make a lot of sense to share everything in /var/qmail/control. It would make more sense if you put both hosts IP addresses under the same name, and set your DNS server to hand out both addresses randomly for load-balancing purposes. You will also have to NFS-mount the delivery destinations (/var/spool or users' home directories) so that either host can do local deliveries. If by ``backup MX'' you really mean ``secondary MX'', then I wouldn't use this scheme. Instead, I would use ssh and rsync to share carefully selected files (such as rcpthosts and morercpthosts). Put the right commands in /var/qmail/control/Makefile on your authoritative host, and run ``make'' after updating any control files. Len. -- Frugal Tip #30: Let a large corporation pay you big bucks to tattoo their company logo on your bald spot.
Re: rcpthosts and morercpthosts
"Petr Novotny" [EMAIL PROTECTED] wrote: On 21 Apr 00, at 8:22, Greg Kopp wrote: 1. What is morerecpthosts and morercpthosts.cdb? Is there a limit to the number of hosts that can be in the rcpthosts file? No real limit; it's just that both files are parsed each time qmail-smtpd is run (ie. connection arrives). morercpthosts is not parsed at all, of course. qmail-smtpd opens the morercpthosts.cdb file, and uses it, if necessary, directly from the disk. I'm guessing that's the point: to keep large rcpthosts lists from turning qmail-smtpd into a memory hog. I've heard that 50 lines in rcpthosts makes a good rule-of-thumb. That's what the manpage says. Len. -- Frugal Tip #37: Check your old financial records and see if you might have accidentally bought some Berkshire Hathaway stock 30 years ago.
Re: Segmentation faults
Ian Shaughnessy [EMAIL PROTECTED] wrote: ...ls reports a segmentation fault. Du does as well, and rm -rf also... There you go, blaming qmail again! :) In answer, the problem you describe is (as far as I know) unheard of with qmail. And qmail does _nothing_ to directories except through the side effects of open(), link(), unlink() and rename(). You have all of the information i can give you... Not quite: What OS, what filesystem, local or NFS? That's all I can think of...now here's my speculation: Did some tool create a file with a humongous name? On my Linux box, all of the programs you mentioned catch the error "ENAMETOOLONG" and exit with an intelligible message. Are you using NFS? Are two systems disagreeing about what ``too long'' is? The number of files should not be a problem--at least not to ls, which you indicated segfaults. Len. -- Frugal Tip #17: Visit the Ford Foundation while disguised as a large, charitable organization.
Re: qmail deleting Maildir/cur directory (fwd)
Ian Shaughnessy [EMAIL PROTECTED] wrote: All I know is when I checked my mail this morning it was all there, but when I checked it this afternoon it wasnt. Quite confusing... Granted. At least, then, tell us what mail client you use, what email address your mail is delivered to, and send us a copy of the relevant .qmail file. If you use POP or IMAP, then tell us what server you get your mail from, so we can see if it's running known buggy software. Mysteries remain mysteries for lack of data. ...and like I said, the log files provided no help what so ever. They all just read like "blah blah mail message delivered successfuly" That's because qmail does not delete directories, period. Well, maybe ``doesn't'' isn't the right word; it ``can't'' delete directories, period. Just look at the qmail source, with ``grep rmdir *'' and see for yourself. The moral: qmail IS NOT deleting your Maildir/cur directory. Folks here already know that for sure, so your subject line is being ignored (and might get you flamed if you keep saying it). Folks _might_ be willing to help you figure out what's actually happening, though. Give all the helpful information you can. Len. -- Frugal Tip #27: Embezzle.
Re: mail-abuse.org
"Luis Bezerra" [EMAIL PROTECTED] wrote: It's not a good solution I prefer QMail Luis, people have answered your questions. Also, your questions are already answered in the documentation AND in the qmail archive. Are you 1) thick headed, 2) a troll, or 3) having trouble understanding English? Or are you an autoresponder? If so, are you available under the GPL? Maybe I can run you from procmail, to annoy people who annoy me. Len. -- Any _widely used_ spam-detection system is a waste of time, because the spammers can and will avoid it. It ends up doing more harm than good. -- Dan Bernstein
Re: virtual domain
fadli syarid [EMAIL PROTECTED] wrote: i make virtualdomains in /var/qmail/control and then add syarid.com:fadli. i add syarid.com to rcpthosts. and then i restart qmail With that setup, messages to ``[EMAIL PROTECTED]'' will be delivered locally to ``[EMAIL PROTECTED]''. This is explained in the manpage for qmail-send(8). If ``fadli'' is your user name, then the delivery is controlled by the file .qmail-fadli if it exists, or by .qmail-default if it doesn't. If ``fadli'' is not a valid user name, then delivery is controlled by either ~alias/.qmail-fadli-default or ~alias/.qmail-fadli-fadli. This is all explained in the manpage dot-qmail(5). i trying to send email to [EMAIL PROTECTED] and get error message like this Sorry, no mailbox here by that name. (#5.1.1) You haven't created one of .qmail-fadli or .qmail-default, so there really is no such mailbox. Create one of those files. Presumably, you want both .qmail-fadli and .qmail-fadli-default so that you can use address extensions like [EMAIL PROTECTED] Note, though, that you can't use other addresses @syarid.com, unless you create .qmail-default. If you also want to use [EMAIL PROTECTED] as an address, then you should have used a different prepend in virtualdomains, such as ``fadli-syarid''. i expect i can use [EMAIL PROTECTED] for my email adress You need one more thing to use that email address: you need an MX record. How does everyone know where to send mail for syarid.com? They don't, unless the DNS has an MX record stating that mail for syarid.com is handled by your machine. Your ISP can set up an MX record for you for a charge. Hope this helps, Len. -- The moment you run that, a local attacker can take over your machine. Isn't security fun? -- Dan Bernstein
Re: qmail relay opened
Luis Bezerra [EMAIL PROTECTED] wrote: Peter Pan... Luis Bizarre, please get it right. His name is Peter van Dijk. I not want your opinion. I want one solution Than ask the question intelligently. Don't just say ``my qmail MTA is accepting mails...'' 1. Provide a transcript of the SMTP conversation with your qmail host. 2. Provide everything in your qmail logs relating to that conversation. You will no doubt see something like the following: ...starting delivery 17: msg 4025 to local [EMAIL PROTECTED] ...delivery 17: failure: Sorry,_no_mailbox_here_by_that_name._(#5.1.1)/ As Peter said, Unless you did something wrong, it is not delivering these mails. It is therefore not a problem. He knows what he's talking about. Now apologize to the nice man for your rudeness. Len. -- Remember that most encryption in this world does not take place inside a Pentium, but on a smart card or other 8-bit processor. Key bits are VERY expensive. -- Bruce Schneier
Re: Poor documentation of anti-spam options?
"Patrick Bihan-Faou" [EMAIL PROTECTED] wrote: The problem with spam is that there is no reliable way to split spam from legitimate mail. Bingo! If you try to filter-out spam, you will always end-up filtering out proper mail as well. Bingo! The key is to try to keep track as much as possible of what is accepted and what is rejected. Why? To satisfy your curiosity? Or do you then track down all senders of legitimate email, and tell them what happened? ...the tolerable lost email / killed spam ratio is somewhat a personal decision... The tolerable ratio is zero. If you are an ISP and think differently, then your customers should abandon you. They might even have grounds to sue you. (``The computer threw your job offer away. Sorry.'') They probably won't, because they don't understand. (``Oh. Those darn computers!'') Len. -- E-mail encryption is a perfect application where cascades are reasonable. Pretty much no one cares if they have to wait 10 milliseconds or 50 milliseconds for the encryption to occur. -- Bruce Schneier
Re: Poor documentation of anti-spam options?
"Patrick Bihan-Faou" [EMAIL PROTECTED] wrote: The only thing I am pointing out is that the choice of doing spam filtering is a personal one, and one has to understand that it will kill legitimate mail as well. Okay, sorry for the warm response. If ``personal'' means the same thing to you that it does to me, then we agree perfectly. (For example, ISPs unilaterally rejecting emails for their customers, without specific authorization is not a ``personal'' decision--and it's unacceptable. Even RBL use, which makes sense, should not be done without informing customers.) Len. -- Experience has shown again and again that Microsoft regards security problems as public relations problems. Hence, I would not trust any claims that Microsoft makes about changes in PPTP that it has, or will, make. -- Bruce Schneier
Re: qmailanalog and UNIX basics
"S.P. Hoeke" [EMAIL PROTECTED] wrote: Specifically I don't know how to "feed your log through" the awk line. Same goes for "feed the matchup output through any of the" scripts You ``feed a file through'' a program when you arrange for the file to be the input of the program. Three obvious ways of doing that are: 1. Input redirection: awk 'SCRIPT' FILE 2. Pipes: cat FILE | awk 'SCRIPT' 3. Command line arguments: awk 'SCRIPT' FILE Option #3 only works for programs which take a file as an argument, but most programs do. For example, awk, perl, sed, grep, more, less, tail, head, etc., all take a file as an argument. I have a silly personal prejudice against using #3: for operating on a single file, I usually use #1 instead; for operating on many files, I usually use #2 instead. Using #2 for a single file will win you Don Libes's "Useless Use of Cat Award". It wastes a whole process over solution #1. For multiple files, however, #2 is a useful use of cat. The fundamental concept of UNIX is the "filter". Any program which reads from the standard input, does something, and writes to the standard output is a filter. They can be assembled in "pipelines", which are probably the single most powerful concept in UNIX (though probably originally a MULTICS concept). To advance out of newbie-hood, you need "The UNIX Programming Environment" by Kernighan and Pike. Buy it, read it, live it. It's $34.00 US from http://www.us.buy.com/books/product.asp?sku=30014507. Kernighan, by the way, is the "K" in AWK, one of the authors of the C language, and one of the inventors of UNIX. Len. -- The pitiful state of "secure code" is shocking. (Actually, I just wrote an essay on the topic. Get a copy for yourself at: http://www.counterpane.com/pitfalls.html. -- Bruce Schneier
Re: how do you use a deferral host in qmail?
Jeremy Hansen [EMAIL PROTECTED] wrote: You're cocky and absolutely useless. And you're a jerk. Actually, Dave is arguably one of the most useful people around when it comes to qmail. Until the long-awaited O'Reilly book comes out, his "Life with qmail" is pretty much the qmail bible. If you don't understand what he's telling you, then go ahead and ask questions--but you really ought to be respectful or at least polite. As Dave said, this isn't rocket science. Finally, Dave is correct that Dan won't add any "feature that seems to be useful" to qmail. Remember, the SMTP server is one of the primary entry routes for crackers, thanks to Eric Allman. Dan will not risk security or reliability for any old feature you dream up. As Dan said before: In general, I'm not going to blindly copy sendmail features---even useful features. I want to understand what problem they're trying to solve; then I'll provide the best solution for that problem. Len. -- On the bright side, if a local user notices the system slowing down, he can monitor the drop directory, decide that it's probably a spammer, and destroy all new messages, without bothering to wake up the sysadmin. ``It's not a security disaster; it's an anti-spam feature!'' -- Dan Bernstein, about Postfix
Re: Error 550 ?
Psabs® [EMAIL PROTECTED] wrote: Thanks for any help !! And sorry my bad english :) That's okay. However, Dan's English is extremely good. He never wrote an error message which said, ``Don't is possible deliver message for us''. It would help very much if you copied the error message exactly. the domain is test.com and host is serv1... Is this you, then? [budney@goshawk budney]$ nslookup test.com Server: duckling.swoop.local Address: 192.168.0.1 Non-authoritative answer: Name:test.com Address: 207.206.9.99 test.com does not have any mx record for serv1; nor can I find any information on serv1.test.com in DNS. Can you give more information about your setup? If your domain is not really test.com, then you should give the proper name. The people on this list can help you; they will not hack your server when you give its right name. They _will_ yell at you when you lie about its name. what is this ?? is DNS ?? this server is under of firewall with NAT !! You need to make your question clearer. Please tell 1) what you did, 2) what the computer did, and 3) what you expected the computer to do. Len. -- When a user's mail has been destroyed, do you explain to him that he was in an extremely esoteric and rare situation? Reliability means never having to say you're sorry. -- Dan Bernstein, author of qmail
Re: Closing: Running qmail on a 4x Xeon 550MHz system
Andreas Aardal Hanssen [EMAIL PROTECTED] wrote: ...I also removed some unnessecary fsync()s as they were slowing down everything very much... Be careful; if you mean that you've removed fsync()s from Dan's code, then you have definitely thrown away reliability in order to gain throughput. In your application, is it acceptable for emails to be silently lost under a power failure? Where did you get the idea that they were "unneccesary"? BTW you could get the same result--indeed, better results--without tampering with Dan's code, if you simply add memory and mount a ramdisk on /var/qmail/queue. If that revolts you, then you might want to put the fsync()s back. ..IO is obviously the problem here, not how-to-interpret-that damn-uptime-load... Correct. But Dan is not stupid; when he accepted the I/O cost, it was to gain a benefit. Before you refuse the cost, you should be sure you know what the benefit was--and that it doesn't outweigh the cost. Len. -- This has nothing to do with qmail or with trademarks. Someone could distribute patches for sendmail that relabel it as ``Dan Bernstein's mailer---yell at [EMAIL PROTECTED] when your system is broken into.'' -- Dan Bernstein, author of qmail
Re: Closing: Running qmail on a 4x Xeon 550MHz system
Andreas Aardal Hanssen [EMAIL PROTECTED] wrote: Who said I removed fsync()s from Dan's code? Please read my closing and see if I've said that. You see, you're really taking words out of my mouth. Just FYI, the correct expression is ``putting words into my mouth'', and I didn't do that. You did notice the ``if'', I trust? All the rest of my remarks were predicated on the conditional: Be careful; _IF_ you mean that you've removed fsync()s from Dan's code, then you have definitely thrown away reliability in order to gain throughput. I'm glad you solved your problem. I am somewhat surprised, though: if you call fsync() twice in a row, I would think that the second one would not do anything. The kernel knows that the file has been flushed, and wouldn't bother to do it again, would it? However, profiling doesn't lie--if you've seen performance improve, then you've improved performance. :) Len. -- This is one of many serious bugs in the Solaris ucb libraries. Do not use /usr/ucb/cc. One way to prevent mistakes is to move /usr/ucbinclude to /usr/ucbinclude-broken. -- Dan Bernstein
Re: Qmail accepting spawm
Jorge Rocha [EMAIL PROTECTED] wrote: Ok, but my server was included in abuse.net and i need to correct this problem. To remove my server from banned list, it need to be tested by an application from them... soapbox Just another example of the collateral damage from common "anti-spam" mechanisms. The test is in error, but the burden is upon you to prove that you deserve to send email. There is a fine line between such stupidity and genuine fascism. ORBS blocks mail from servers which block ORBS's scanners. In a slightly different arena, CyberPatrol blocks websites which criticize them or censorware in general. I'll save you from the bad stuff! (And anything I don't like...hehe.) /soapbox /post Len. -- When a user's mail has been destroyed, do you explain to him that he was in an extremely esoteric and rare situation? Reliability means never having to say you're sorry. -- Dan Bernstein, author of qmail
Re: Multiple To:
Christian Wiese [EMAIL PROTECTED] wrote: [our Qmail SMTP HUB] 1. Fetchmail fetch the mail from POP3 mailbox at our ISP 2. The HUB transfers the mail to our internal Qmail server. [internal Qmail server] 3. our internal Qmail server delivers the mail into the local mailbox of "mailuser", but there are still messages that the qmail server can't treat local 4. the internal qmail server transfers the outgoing messages back to HUB [HUB] 5. outgoing messages will be transferd via maildirserial to our ISP's SMTP server This is the fault of fetchmail. More specifically, you're using fetchmail wrong. It has nothing to do with using "To:" instead of "Cc:" at all. You're letting fetchmail forward popped mail through qmail, to all of the recipients in the headers. But that's exactly what the original, remote sender already did! So you're letting your mail server do something which is properly none of its business. Your only real option, if you want to use fetchmail in this setting, is to do one of the following: 1. Scan the email's headers for specific local users addresses. This is hard; in fact for mailing list emails or BCC-ed emails, it is basically impossible. (If your ISP uses qmail, then you can do it after all, since qmail writes the envelope at the top of every message.) 2. Give each local user a separate POP account at your ISP; run fetchmail separately for each user. Deliver to that specific user. This prevents you from using mailboxes with addresses like user+extension@ or user-extension@, which is a major bummer. Since most mailers discard envelopes (or record them in a hard-to-parse way), you will have big problems mixing a push-protocol (SMTP) with a pull-protocol (POP3). A better alternative is to get your ISP to set up AutoTurn for your maildrop. In that scenario, it is the ISP's problem to keep all mail envelopes straight. All you have to do is perform the local delivery. Len. -- You're deluding yourself if you think that these anti-reliability features actually affect the spammers. -- Dan Bernstein
RE: Multiple To:
"Don Wright" [EMAIL PROTECTED] wrote: From: Len Budney [mailto:[EMAIL PROTECTED]] ...qmail writes the envelope at the top of every message... I'm looking at setting up a qmail server for a midsize corporation. Are you saying that all delivery addresses that were supposed to be hidden by the BCC and mailing list functions would be exposed to all recipients? Definitely not. As you say, that would be a very bad privacy problem. Each recipient gets a copy of the message which tells _only_ the final envelope recipient--in other words, what address resulted in delivery to that recipient. (The envelope sender is also included, but that has no security implications.) In the case of large mailing lists, that could add hundreds of kilobytes to each message being sent, resulting in excessive bandwidth charges. What qmail does, specifically in order to honor BCC and mailing lists, is send out one copy of the message per recipient. That's why other MTAs have leaked BCC information, but qmail never has. In general, this does not lead to excessive bandwidth consumption over other mailers, for several reasons. Among them: 1. Other mailers waste so much bandwidth on redundant DNS queries that they completely negate savings in transferred message bytes. 2. Other mailers are not able to take advantage of multiple envelope recipients on the same host nearly as often as people imagine. Except possibly certain scenarios involving mailing lists, a tiny fraction of all deliveries consist in the same message to many recipients at one host. 3. Other forms of traffic, particularly HTTP, completely blows away the much smaller bandwidth consumption of SMTP traffic. Dan will not change this feature in qmail, despite periodic holy wars, for all of the above reasons, and more besides. Among them: 1. The pathological case of mailing lists has a much better solution. Set up a sublist nearer to the cluster of subscribers, and subscribe the sublist to the main list. Consider your corporation. If most of your employees are subscribed to the same foreign mailing list, then setting up a sublist on your internal mail server lightens the load on the main server, enhancing throughput. It also moves all of your employees to the ``front of the list'', enhancing perceived performance. Finally, it means that for each list post, exactly one email passes through your external connection. If few of your employees subscribe to a given list, then you can ignore it. Who cares about the minimal traffic that entails? For purely internal lists, LAN bandwidth is all you care about--your Internet connection is involved only minimally, if at all. LAN bandwidth is hardly touched if your mailing list server is on or near the mail server box. (Dan's ezmlm, plus the IDX patches, can even work as a sublist of non-ezmlm foreign lists. Check http://www.ezmlm.org/ for details.) 2. Another pathological case is hyper-restricted bandwidth at your Internet connection. The best solution to that is to use serialmail with QMTP to store-and-forward outgoing email, and AutoTurn at your ISP. Since your corporation is ``mid-sized'', your bandwidth concerns can't possibly be that stringent. 3. If you consider serialmail sending two copies of the same message, and wish you could shrink the bandwidth even further, then consider an experiment recommended by Dan himself: wc -c MESSAGE 7752 gzip -c MESSAGE | wc -c 3548 gzip -c MESSAGE MESSAGE | wc -c 3651 In other words, ganging messages by recipient host is a piddly attempt to conserve bandwidth which still consumes over twice the bandwidth that a real solution, i.e. compression, would consume. If bandwidth were _that_ tight for you, then it would be easy enough to use compression to achieve some _real_ savings. Hope this helps, Len. -- Do you really expect us to believe that you completely misunderstood what Henders said, don't know what ``queue'' means, and can't speak English? -- Dan Bernstein, author of qmail
Re: Qmail Relay Question
"Steve Wolfe" [EMAIL PROTECTED] wrote:
I have been watching this list for a few weeks now. And the people
on here are the most un-helpful people I have seen. Your typical
answer to a question is man this or man that.
When I first signed up to this list, I wondered why people didn't just
give answers, then I realized: ... Simply shoveling out information
does a disservice to the asker, the responder, the list member, and
the world at large ...
Amen. And very well put.
(When I first signed up, back in '96, I was completely clueless about email
and asked utterly inane questions, which were mercifully ignored. The
experience was quite embarrassing, but ultimately was very helpful.)
"I don't have the time for you because you are not as smart as me"
That attitude isn't at all typical of linux administrators, it's typical
of a few high-profile Unix programmers (who shall remain nameless).
If you mean Dan, I beg to differ. Dan ignores most stupid questions,
patiently answers a few, and usually bites hard only after explaining
something and being contradicted. In this respect he's just like any
Math professor/competent mathematician I've ever known--he reserves his
scorn for people who've had a chance to RTFM but refuse and then continue
to bother him.
Then, the "Ooh, I want to be cool like {Insert High-Profile Name}"
people try to emulate it.
I'm certainly an ``Ooh, I want to be as knowledgable and competent as Dan''
person. Many of us are. And maybe some of Dan's style rubs off, as well as
some of his knowledge. But mostly people hate to answer the same question
over and over; your previous excellent explanation nailed it.
Len.
--
Unfortunately, spammers deliberately subvert priority mechanisms,
making their ``bad'' messages indistinguishable from ``good''
messages.
-- Dan Bernstein, author of qmail
Re: Why fstat() in qmail-send.c:markdone()?
"Fred Lindberg" [EMAIL PROTECTED] wrote: It's obviously important or it wouldn't be there. Can anyone explain why? Forgive my speculation--if I'm wrong, somebody correct me! My guess is that fstat() follows open() because of system-specific open() bugs. On NFS, for example, open() will sometimes return a descriptor, but subsequent write() calls will fail with EACCESS. This condition can be detected through error slippage by calling fstat(), which will also fail with EACCESS. Len. -- The whole point of modern `standards' is to preserve the existing oligopoly. A few vendors band together to produce a `standard' that is precisely the disjoint union of their existing implementations, including all their warts. -- Henry Baker
Re: moving from mbox to maildir.
"Russell P. Sutherland" [EMAIL PROTECTED] wrote: * Eric Lalonde ([EMAIL PROTECTED]) [ 6 Mar 2000 22:09]: ...where do i copy currently unchecked email in /var/spool/mail, so that this mail will be listed under Maildir as 'unchecked' email? See for example: http://madhaus.utcs.utoronto.ca/qmail/mbox2maildir for a perl script written by Ivan Kohler. Or, if you're more anal about strict conformity to the maildir algorithm, you can try safecat: http://www.pobox.com/~lbudney/linux/software/safecat.html Use formail to split the mbox into messages, and safecat to filter each one. There's a one-liner on the one-liners page, reachable from the main safecat page. The point of safecat is that it returns success if and only if the message is delivered successfully. You should arrange to catch the exit status of safecat, and try again for any mbox for which safecat fails (which is unlikely to happen in the first place). Len. -- Use prime numbers so that the hashing works well. (``Oh, that's what /usr/games/primes is for.'') -- Dan Bernstein
Re: qmail-pop3d not conforming to RFC1939?!
iv0 [EMAIL PROTECTED] wrote: Russell Nelson wrote: Yeah, but you're still serving up the Bugtraq posting with the qmail-pop3d patch in it. Funny thing. After reading that bugtraq posting again, I don't agree with the contents. So I've taken it down. We orignally put it up to be complete. That was very honorable, since those comments tended to exhonorate your software at the expense of Dan's. I congratulate you! Len. -- Peterson's basic problem is that he wasn't aware that ``radix sort'' could refer to anything other than LSD radix sort. Now he's going on an ad hominem rampage, attacking me to try to cover up his own ignorance. -- Dan Bernstein
Re: Encryption and t-shirts
"Mark E. Drummond" [EMAIL PROTECTED] wrote: How about djb's "There are two kinds of interfaces ..." quote? You mean: I have discovered that there are two types of command interfaces in the world of computing: good interfaces and user interfaces. -- Dan Bernstein :) Len. PS I'll take one too; XL, preferably light colored but heavy weight. -- When you talk about every use of a person's name as ``ad hominem'' you simply make yourself sound illiterate. -- Dan Bernstein
O-T: Announce: safecat-1.2 is available
Safecat 1.2 is available. Changes: Complete rewrite using DJB libraries, including buffered I/O. Speedup of about 1.4 for actual email messages. Now writes "Delivered-To:" and "Return-Path:" headers when DTLINE and RPLINE environment variables are set. Of interest: http://localhost/~lbudney/linux/software/safecat/performance.html A summary of the recent performance discussion on qmail. http://localhost/~lbudney/linux/software/safecat/COPYING.txt My own solution to the problems of Dan's unclear licensing. It boils down to, ``If you don't bother Dan, he probably doesn't care.'' Len. -- I'm criticizing one program. That program is disgustingly insecure. It shouldn't just be ridiculed---it should be taken out and shot. -- Dan Bernstein, author of qmail
Re: O-T: Announce: safecat-1.2 is available
Oops, "Len Budney" [EMAIL PROTECTED] wrote: http://localhost/~lbudney/linux/software/safecat/performance.html http://localhost/~lbudney/linux/software/safecat/COPYING.txt "localhost" should be "www.pobox.com", of course. Sorry for any inconvenience. Len. -- Methinks you're exaggerating; 100,000 messages per minute would be 144,000,000 messages per day. AOL isn't _that_ big. -- Dan Bernstein
Re: Maildir and procmail and safecat
Sam [EMAIL PROTECTED] wrote: On Fri, 25 Feb 2000, Paul Jarc wrote: Sorry, no. You're not looking at *the* putc macro; you're looking at *a* putc macro. One implementation need not resemble another at all However, since I'm using *MY* implementation, I'm going to look at *MY* macros, thankyouverymuch. [various stupidity snipped] Out of thine own mouth will I judge thee. Benchmarking *YOUR* macros is pointless, when you're talking about the performance of *MY* program. Why don't you benchmark my program, stupid? ``I do not need to benchmark obviously inefficient code just to prove that it's inefficient.'' Who needs to profile, when Sam can calculate runtime profiles without even glancing at the code? Just tell Sam an anecdote about your program, and he'll give you a thumbs up or down. Jackass. I wonder how many times I have to report the same results (twice apparently isn't enough) before everyone finds something else to do, besides splitting hairs. Okay, consider your results. One program writes a byte repeatedly, and the other immediately segfaults. What was that supposed to tell us about safecat? Considering your utterly inept approach to profiling, it certainly appears you don't do it that often. I'll repeat, for the last time: safecat, on my system at least, runs within a factor of two of /bin/cat. Len. -- You're repeating the same old ``forks are bad and execs are disastrous'' litany without _profiling_ where your time is actually going. -- Dan Bernstein
Re: Safecat challenge
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? Sam [EMAIL PROTECTED] wrote: Considering your utterly inept approach to profiling, it certainly appears you don't do it that often. Correct, professor. I prefer to write efficient code right from the start. What a novel concept! The prosecution rests, your honor. We've heard from Dijkstra, Knuth, and other expert witnesses. The defendent has confessed to the crime of total boobery. I'll repeat, for the last time: safecat, on my system at least, runs within a factor of two of /bin/cat. And on other systems, it benchmarks at 1/50th the speed of efficiently-written code. 1. You benchmarked safecat? You saw somebody else's benchmarks? No. So shut up. 2. I said ``/bin/cat''. You said, ``efficiently written code'', by which you meant ``something I'm imagining right now in my head, which isn't safecat, which I've never profiled. There's a profiler in my head!'' Beep! Thanks for playing; take your booby prize at the door. (I'm done abusing the list with this off-topic thread.) Len. PS A speedup of 2 is nothing to sneeze at. It's closer to 3 on an unloaded system; again nothing to sneeze at. I'll be rewriting safecat Real Soon Now.
Re: Maildir and procmail and safecat
Russ Allbery [EMAIL PROTECTED] wrote: Len Budney [EMAIL PROTECTED] writes: Yes, but 5-6 orders of magnitude less expensive than physical writes. If I had incurred, but discounted, physical latencies, I would be a jackass. Instead I simply made a decision you don't care for, which I would reverse in the face of actual performance data. W. Richard Stevens did that benchmark in _Advanced Unix Programming_ quite a while back; as I recall, the difference between single-character writes and buffered writes in his data was an order of magnitude or two. Sounds believable. I benchmarked safecat using write(,,1) and putc(), and got a factor of at worst 2 (in wall-clock time). My benchmarks weren't terribly exhaustive, since they didn't cover a range of filesystems, and no control was exercised over system load/application mix. I'll probably rewrite safecat on general principles anyway, but so far nobody has reported that it was their bottleneck. Mr. Sam's ``I can't even emulate putc correctly, and I'm too stupid to simply _use_ putc'' benchmark was pretty underwhelming. Len. -- Finally, anti-spam rules are vulnerable to the anti-fax effect: they are useful only if they aren't very widely used. -- Dan Bernstein
Re: Maildir and procmail and safecat
You've been worked over pretty thoroughly already, but anyway... Sam [EMAIL PROTECTED] wrote: On Thu, 24 Feb 2000, Len Budney wrote: However, they have about the similar wall-clock runtime as each other and as /bin/cat. The best expectable speedup would be a factor of about 2, not 1,000,000. [Completely bogus straw-man code snipped] Both of these have "similar wall-clock runtime" too. 1. In my benchmark, I ganged 1,390 runs using actual, distinct email messages as input. Thus I didn't see 00.00elapsed, and didn't think to myself, ``Gee, buffered writes take no time at all!'' 2. I benchmarked _safecat_, not some sort of bogus loop which doesn't do anything. Why didn't you, since we were talking about safecat? 3. If you're making claims for putc(), why didn't your non-safecat program _use_ putc? Why did you need to ``emulate putc()'s implementation as closely as possible''? If you really did need to, why were you so dismally incapable of it? Still, one version doesn't even register -- executes in less than a clock tick. Amazing! You've discovered how to do useful work in zero time! Now, multiply that by hundreds of thousands of messages per second. True; writing 100,000 messages in 0 seconds is mighty fast! You _are_ a guru! HP/UX, for example, they are (were) written so poorly that returns from a signal handler dropped back inside the macro. Anyone who has two brain cells to rub together knows enough not to mix stdio and signal handling together. stdio is not guaranteed to work at all in conjunction with signal handling. Thanks for the tip! That might have something to do with why I didn't use stdio. (``grep sigaction *.c'') How do I know why putc() fails when it fails? Check errno. Always works for me. This is guaranteed on which platforms? Broken on which? Which standard requires the use of errno? Why don't the manpages say so? Finally, how did you verify that it ``always works'' for you? I recall that the original excuse for this absurd logic was that it's too gosh darn difficult to properly check the return value from a multicharacter write() call. Wrong again. It's true I don't see the point in implementing something whose need is not established. ``Profile, don't speculate.'' By the way, try ``man 2 write''. Suggesting I can't handle return codes, when you can't even supply correct arguments, is hilarious. Thanks anyway. Len. -- There is no dispute that the proposed code fails in exactly the situations that I said. There are simply religious claims that I shouldn't care about that type of breakage. -- Dan Bernstein
Re: Maildir and procmail
Tracy R Reed [EMAIL PROTECTED] wrote: :0 * ^[EMAIL PROTECTED] * ^Subject: test test.`/bin/date +%m%y`/new Mail to me with a subject of test goes to the specified maildir. Is it really necessary to append /new to the name of the Maildir? Yes, unless you 1) use a patched procmail, or 2) use an external delivery program. Ideally, you should use one with similar reliability guarantees to qmail itself. Trusting procmail to deliver reliably seems a little dangerous, in my opinion. I recommend safecat, which you can find at http://www.pobox.com/~lbudney/linux/software/safecat.html. Using the embedded script `maildir', your rule would be rewritten as: :0w -- Needed for reliability * ^[EMAIL PROTECTED] * ^Subject: test |maildir test.`/bin/date +%m%y` -- Absolute path is better Before procmail would create the new mbox files for me automatically. It won't automatically create Maildirs for me. Anyone have a solution? Two points for the modular approach! Wrap `maildir' in the following script: #!/bin/sh # Create a Maildir, if it doesn't already exist if test ! -d "$1" then maildirmake "$1" || exit 1 else if test ! -d "$1"/tmp -o ! -d "$1"/new then echo "$1" exists, but is not a maildir. 12 exit 1 fi fi exec maildir "$1" Note that `maildirmake' must be on the PATH given to procmail, and you should be conscious of the path to your maildir. safecat doesn't care whether paths are relative or absolute; I recommend absolute. Just prepend "$HOME/Mail/" to the maildir in the recipe above. Len. -- Exim seems to exhibit all the security design mistakes Sendmail has made, only Exim handles them even more poorly than Mr. Allman does... -- Dan Bernstein, author of qmail
Re: Managing the Queue
"Peter Samuel" [EMAIL PROTECTED] wrote: On 24 Feb 2000, D. J. Bernstein wrote: Peter Samuel writes: Under certain conditions it can leave the queue in a corrupt state. No, it can't. See INTERNALS in the qmail package for the complete story. I _know_ what INTERNALS says Dan, but try this test and you'll see that it does leave the queue in a corrupt state...qmail-queue exits with a 91 and does NOT unlink the mess or intd file. That doesn't mean that the queue is ``corrupted''. If todo/INODE exists, the message is queued. If not, the message is not queued. Period. Qmail returns success to the caller only if the message is queued. Lots of failures can leave various files in the queue tree--INTERNALS discusses that at great length (for Dan). If qmail-queue is killed in state S3, both mess/INODE and intd/INODE will exist--but the message is not queued. That's what qmail-clean is for. It's called by qmail-send to clean up any lint in the queue tree. Note, though, that this takes at least 36 hours. qmail-send doesn't delete younger files, because they might represent a message presently being queued. It's all documented in INTERNALS. Len. -- Shared libraries work wonders with hulking monoliths of code. Most programs today are hulking monoliths of code. A kluge whose value rests on the popularity of poor programming practice is a valuable kluge indeed. -- Dan Bernstein
Re: Maildir and procmail and safecat
Curtis Generous [EMAIL PROTECTED] wrote: I'm trying to use safecat on a very busy email server, and noticed while looking at the output of truss(1) that all writes to the file are being done a single character at the time... That may be excessively draconian on my part! Back when I wrote safecat, I used 1-byte writes when possible, because it eliminated the need for logic handling the case that 0write(n)n, in which it's necessary to back up and rewrite the missing characters. When n=1, the result of write() must be one of error (-1), temporary failure (0), and success (1). I've assumed that most filesystems are block-buffered anyway, and safecat doesn't call sync() until it's finished writing the entire file. Has this caused a measurable performance problem in your setting? I haven't revisited that in some time; if anyone has a comment or insight please let me know. Otherwise, I'll look into updating safecat Real Soon Now. It needs one or two minor things anyway. Thanks, Len. PS One of the things safecat needs is to write the "Delivered-To:" and "Return-Path:" lines when DTLINE and RPLINE are set. If you're using qmail-pop3d or serialmail, that's a more serious problem for you--which I plan to fix RSN. PPS Switching to substdio/stralloc would also eliminate that problem. I might do that, now that I've decided to stop worrying about Dan's view of people reusing his code in their projects. As long as I handle any maintenance costs, I'm assuming Dan doesn't care one way or the other. -- Security is completely separate from functionality, and no amount of beta testing can ever uncover a security flaw. -- Bruce Schneier
Re: Maildir and procmail and safecat
Sam [EMAIL PROTECTED] wrote: On Thu, 24 Feb 2000, Len Budney wrote: I've assumed that most filesystems are block-buffered anyway, and safecat They are, however switching to/from kernel mode is extremely expensive. Yes, but 5-6 orders of magnitude less expensive than physical writes. If I had incurred, but discounted, physical latencies, I would be a jackass. Instead I simply made a decision you don't care for, which I would reverse in the face of actual performance data. Under my own benchmarks, safecat with buffering is more CPU intensive than without. However, they have about the similar wall-clock runtime as each other and as /bin/cat. The best expectable speedup would be a factor of about 2, not 1,000,000. In particular, it is extremely unlikely that safecat is the source of Mr. Generous's performance problems. If actual performance metrics indicate otherwise, I will happily rewrite the program to accomodate his needs. The reason getc/putc buffer single characters into big chunks, before calling read/write, is not because some programmer had some free time one afternoon, and decided to write all those convoluted macros and functions. The reason for my idiom, and the reason I don't use those convoluted macros and functions, is not because I got religion at an anti-libc tent revival. The getc/putc macros are, in general, a portability nightmare. Under HP/UX, for example, they are (were) written so poorly that returns from a signal handler dropped back inside the macro. Result: your friends the ``convoluted macros'' degenerated to infinite loops upon receipt of non-terminal signals. Question: why didn't the fellow you admire so, who wrote these convoluted macros, see fit to give proper error information? Why didn't he use errno? How do I know why putc() fails when it fails? Len. -- It's not an opinion. It's a statement of fact. And it's wrong. -- Dan Bernstein
RFC: Command-line MUA for Maildirs?
Magnus Bodin [EMAIL PROTECTED] wrote: Mutt is _the_ client for Maildir. There is patches for Pine too. I haven't hear of a command line mail reader for Maildir boxes. ^^ Speaking of which, is anyone interested in building such a thing? Or, would anyone use such a thing if it existed? I still use MH, with all its drawbacks, because it offers the most flexibility. Emacs/Mew for awesome MIME handling, GNUs for...well...reading GNUsly, command-line MH for quick handling of individual messages. Does anybody wish for a command-line interface to maildirs, on the idea of MH? If it were architected right, the result would be some simple tools which would facilitate other MUAs jumping on the maildir bandwagon... Len. -- There's a fine opportunity here, but the IETF is institutionally incapable of taking advantage of it. I think it's safe to say that the DRUMS specs will be even more widely violated than RFC 822. -- Dan Bernstein
Re: qmail on FFS with softupdates
Anand Buddhdev [EMAIL PROTECTED] wrote: Dan does not recommend the use of a softupdates file system for the queue. If FFS+softupdates = standard FFS+faster, then there should be no harm in using it. This is something I _can_ comment on. In fact, I already did, in message 42203 on this list: "Len Budney" [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Using softupdates under *BSD gives you the reliability of sync (somewhat more, actually), with nearly the speed of async. In October of 1999, that wasn't quite true... ``In particular, if you put a mail queue on a softupdates filesystem, you can lose mail when the power goes out, just as if you were using Linux.'' -- Dan Bernstein, http://x38.deja.com/getdoc.xp?AN=539496358 From Dan's other comments in that thread, it appears that the rename() call returns success before the rename was committed to disk. Dan said ``mail programs'' rely on rename() to tell the truth. A look at the source code suggests that qmail is not one of them--qmail-queue doesn't use the rename() call. If link() is subject to the same complaint as rename(), then qmail probably _does_ have the same reliability problem on a softupdates filesystem as on an async filesystem. Len. -- Some people are suffering from the delusion that program modularity is incompatible with good performance. -- Dan Bernstein
Re: egg on MY face
Andre Oppermann [EMAIL PROTECTED] wrote: Appearantly you mixed something up here. FFS never did journaling and neither does softupdates. Indeed. :( Apparently, I misread the following about two years ago, and never looked back: qmail's queue (except for bounce message contents) is crashproof if the filesystem guarantees that single-byte writes are atomic and that directory operations are synchronous. These guarantees are provided by the BSD FFS and its derivatives, and by typical journaling filesystems. I'll call you back when I learn to read, Len. -- When the OS already provides a simple, widely used, thoroughly tested mechanism, it makes no sense to give every program a half-assed imitation of the same mechanism. -- Dan Bernstein
Re: qmail on FFS with softupdates
(This post is still on-topic, but hanging by a thread.) Magnus Bodin [EMAIL PROTECTED] wrote: On Thu, Feb 10, 2000 at 11:21:08PM -0500, Len Budney wrote: ...the reliability impact of soft updates on FFS--giving us a good example of both a reliable journalled filesystem, and an unreliable journalled filesystem. Thanks. Yes. Let's make the clarification. FFS with soft updates is NOT a journaling file system. Thanks for the correction. Do you have a reference for that? I couldn't find one. It is possible to use soft update technology while still maintaining a journal of metadata. I assumed, apparently incorrectly, that FFS did this. (If the metadata journal has been discarded, I would have thought that the filesystem would be different enough to warrant a new name.) It DOES NOT MEAN that rename() is no longer an atomic operation in respect to other applications, but if you get a crash between the rename() and the fsync() you cannot be sure that the rename has been done when you come up again. The impact of qmail is however dim to me. qmail-queue never calls rename; only link. If I'm wrong in assuming that your remarks transfer to link, please let me know. With that disclaimer, here's how qmail-queue enqueues a message: 1. Create a file in a temporary directory (queue/pid). It's inode becomes the message number (say 457). 3. Link the tempfile to queue/mess/457. 4. Write the message to queue/mess/457 (via the open file descriptor in queue/pid). fsync(). 5. Create queue/intd/457, and write the envelope to the file. fsync(). 6. link queue/intd/457 to queue/todo/457. If the link in #6 succeeds, qmail-queue will return success. If the link in queue/todo later vanishes, then so does the mail message. Do we have to add extra fsyncs here? I'm not sure. In your other post (subject: ``fsync semantics''), you didn't supply the arguments to fsync. Is it necessary to open each of queue/mess, queue/intd and queue/todo and fsync them? In that case we need three more fsyncs (under FFS with softupdates, at least). Does fsyncing an open file descriptor sync not only metadata but hard links as well? In that case fsyncing queue/intd/messnum again after #6 suffices. Len. -- In general, I'm not going to blindly copy sendmail features---even useful features. I want to understand what problem they're trying to solve; then I'll provide the best solution for that problem. -- Dan Bernstein, author of qmail
Re: qmail on FFS with softupdates
Andre Oppermann [EMAIL PROTECTED] wrote: Len Budney wrote: 1. Create a file in a temporary directory (queue/pid). It's inode becomes the message number (say 457). 3. Link the tempfile to queue/mess/457. 4. Write the message to queue/mess/457 (via the open file descriptor in queue/pid). fsync(). 5. Create queue/intd/457, and write the envelope to the file. fsync(). 6. link queue/intd/457 to queue/todo/457. If the link in #6 succeeds, qmail-queue will return success. If the link in queue/todo later vanishes, then so does the mail message. And should be resent later by the sending MTA because qmail did not say "250 ok". Transaction not completed, roll-back. I'm not sure if we're communicating. Does FFS offer the guarantee that when link() succeeds, the hard link exists on the physical disk? If not, then you are incorrect. When the link in #6 above succeeds, qmail-queue returns success. qmail-smtp interprets that as success, and returns "250 ok". The client interpets that as success, and discards the message. All of this occurs if link() returns success. If link() can return success, yet the link itself vanish after a reboot, then mail can be lost. Where does that leave us? Len.
Re: Egg on my face
Sam [EMAIL PROTECTED] wrote: On Thu, 10 Feb 2000, Russell Nelson wrote: Well, hell, you'll probably lose mail even if you're running a journaling filesystem, like that. Contrary to popular belief, a journaling fs does not guarantee that all of your data is intact, just that the integrity of the fs itself will not require a refsck after a crash. False. Mail will not be lost if if rename() or link() (depending on the software) offers the correct semantics: they should return only after the operation has completed _on hardware_. That's true even with soft updates (in which writes are ganged based on physical proximity on disk). Your point applies specifically to journalling filesystems with soft updates which don't honor the traditional semantics. Len. -- Today's processors are not 1000 times bigger, they're 1000 times smaller. The processors on your desktop are an abnormality. Look at the ones in your car. -- Bruce Schneier
Re: Journalling and email loss
Sam [EMAIL PROTECTED] wrote: On Thu, 10 Feb 2000, Len Budney wrote: Sam [EMAIL PROTECTED] wrote: On Thu, 10 Feb 2000, Russell Nelson wrote: Well, hell, you'll probably lose mail even if you're running a journaling filesystem... False. Mail will not be lost if if rename() or link() (depending on Who said anything about the message already being on the filesystem? Then your comment was utterly inane. Any MTA which returns success before writing a message to the filesystem, and syncing it, should be thrown away. Any MUA which doesn't check exit status of the MTA should be thrown away. Authors of such junk should be flogged. (My remark applies to qmail 2, as well. Zeroseek will build compressed journals, but the journal entry had better be on disk before success is returned.) Len. -- Cryptographic systems are broken constantly, but the attacks are almost never against the algorithms. The really difficult problems in security systems are key distribution, management, reliability, robustness, etc. -- Bruce Schneier
Re: Journalling and email loss
(Sam) Well, hell, you'll probably lose mail even if you're running a journaling filesystem... (me) False. Mail will not be lost if if rename() or link() (depending on (Sam) Who said anything about the message already being on the filesystem? (me) Then your comment was utterly inane. Any MTA which returns success before writing a message to the filesystem, and syncing it... (Sam) Which only syncs the data. close() then updates the metadata, which may remain buffered for some time before getting flushed out. Which brings us back to link() or rename(), of course. Writing data directly to the target queue/file is a mistake, unless you want queued, incomplete messages after a failure. Is it late at night where you are? I'm certain you know all this; you must be tired. Len. -- Look at it this way: sendmail is a whale, and qmail is a shark. Perhaps you're impressed by the size of the whale; perhaps, if you grew up surrounded by whales, you find it hard to imagine a big sea creature without tons of blubber. -- Dan Bernstein
Re: maildir access
Marek Narkiewicz [EMAIL PROTECTED] wrote: How do i go about reading from a maildir without ncroaching on the security of the maildir? Depends what you mean by ``security''. If you really mean ``security'', then the answer is: only do it if they're your emails (or you're authorized). If you mean ``reliability'', then there's no issue: go ahead and read any file in maildir/new or maildir/cur. Don't touch any files you see in maildir/tmp--unless they're older than 36 hours, in which case you should delete them. Also where can i find the spec for maildirs like an rfc or similar. The best spec is the manpage maildir(5), included with qmail. It tells you everything you need. It also refers you to a page on Dan's website with a little more information for MUA implementers. ie what is the procedure for reading emails If you mean, ``What MUA uses Maildirs as folders?'' then as far as I know the only one is mutt. For spot use, ``more'' or ``less'' should be good enough. Len. -- The moment you run that, a local attacker can take over your machine. Isn't security fun? -- Dan Bernstein
Re: Journalling and email loss
Sam [EMAIL PROTECTED] wrote: On Thu, 10 Feb 2000, Len Budney wrote: Which brings us back to link() or rename()... And, if close() does not update the metadata, there's no reason why link or rename should either. What this REALLY brings us back to is the fact that the only thing that journaling guarantees you is that you won't have to refsck everything after a reboot... Journalling is absolutely orthogonal to the reliability issue. The reliability issue is: What are the semantics of fsync(), link() and rename()? If they return after the requested operation completes to disk, we can guarantee reliability. If not, we can't. Which brings us back to your mistake; you make a claim about ``journalling filesystems'' which is true for some, and false for others. FFS had those semantics, for example, but happened to break them when soft updates were added. Len. -- 256-bit keys will forever be immune from brute-force attacks until computers are made up of something other than matter and occupy something other than space. -- Bruce Schneier
Re: maildir access
Marek Narkiewicz [EMAIL PROTECTED] wrote: Now in order for the java server to update the client when new mail is available it needs some way of knowing which mails have already been read by the web client. The easiest way, if your maildir clients all play nice, is that files in maildir/new are new, and files in maildir/cur have been seen (which isn't the same as read, exactly, but I'm just nitpicking). So just inform your Java client when there are files in maildir/new. Does qmail-pop3d currently offer anything outside rfc 1460 that can mark messages as read? When a message has been popped, qmail-pop3d _does_ move it to maildir/cur, which effectively marks it as read. So you're all set. If not can anyone think of the most logical way to utilise that info field? I would like to then improve on the functionality to offer imap style folders but virtually based on a code in the info. I can't help you there; I don't know much about IMAP. The main concern is that scanning a directory can be slow if the folders are too full (where too full has been estimated at 25K emails). I don't know if the concern is reasonable, since I don't know if anybody ever has folders so full. Len. -- How about the B1H problem, when your body temperature goes above 100 degrees? Or the L1m problem, when the lira dips below one millicent? Casinos worry about the D52C problem, when there are more than 52 cards in a deck. This could be the start of something big. -- Bruce Schneier
Re: school filtering of student e-mail
"Barry Smoke" [EMAIL PROTECTED] wrote: I work for Bryant Public Schools, Bryant AR... 1. how do we filter [email] content, and what do we filter?(is there a programare there rules for words, catch phrases, content, url's, attachments...) It's not clear what you're after here. Are you worried about incoming mail (e.g., spam)? Or outgoing mail (e.g. mail abuse by students)? If you're worried about spam, you should (at bare minimum) set up rblsmtpd, and use the Realtime Blackhole List http://maps.vix.com/rbl/. You might also want to subscribe to the Open Relay Blocking System http://www.orbs.org/. If you're worried about abuse _by students_, then the most important measure is to be highly responsive to messages to abuse@ reporting misbehavior. Actually interfering with student mail may have legal implications, especially 1st amendment and 4th amendment issues. For example, any filter which watches for pornographic text will probably flag some fraction of emails between a boyfriend and a girlfriend within the same school. Acting on those emails may raise legal problems (censorship); failing to act may also raise legal problems (contributing to the delinquency of a minor). The bottom line: before interfering with outgoing email, you should probably check with a lawyer (which I am not). This appears to be a legal issue, not a techinical one. Hastily implementing a technical solution would be ill-advised. Len. PS Consider my remarks retracted if the school system has already formulated a legal policy here. It doesn't sound like it, though, or your question would not have been so vague. In particular, ``the bad stuff'' needs to be defined before it can be filtered, and ``bad'' here must necessarily be defined by law and policy. -- In 1995 Matt and I presented a cipher called MacGuffin at FSE 2 (an algorithms workshop). It was broken even before we presented it, by the hosts of the conference. This is the way the science works. -- Bruce Schneier
Re: school filtering of student e-mail
"Barry Smoke" [EMAIL PROTECTED] wrote: We will need to allow students to use this only to do research, recieve valid attachments (ie...research pictures, zip files containing valid material, etc.). We do not have the staff to police the proper use of this though, and any porn links, dirty pictures, etcwill not be tolerated. Please concider this a technical question, and not an ethical/legal one. Ahh--that's easier. You can't do what you've just described. If students can receive legitimate pictures, but not illegitimate ones, then you need a way to distinguish the two. There may be AI which can, for example, identify photos of naked women, but there is nothing out there of practical use which can do it. If there were, then you would still have a problem; if your students are researching classical art, then they will not be able to view (presumably legitimate) paintings of nudes. So you can forget about spotting ``bad'' photos, video, audio, and the like. The only way to catch these is to forbid all attachments of that class. As for zip files--you can't examine the contents without unzipping them. That alone will significantly impair mail performance. However, you can do it. Once you do, the above objection applies to photos, video, etc. That leaves text. By ``text'', I mean pdf, postscript, plain text, html, Word documents, and possibly more. Each of these can be converted to plain text, at fairly significant performance cost. If you're not daunted yet, we can just call them ``text''. Then yup, you can scan text for a list of forbidden words and phrases. As Steve Wolfe said, you can log the matches, forward them to admins, whatever you want. Of course, scanning on racial epithets will flag children reading Mark Twain. Ordinary cuss-word scanning will flag most literature. Bottom line: your goal still needs some clarification. Len. -- Gee. What if the spammer keeps trying to send more messages---forever? What if you get billions of connections from faked IP addresses? ...Please don't waste my time on nonexistent efficiency problems. -- Dan Bernstein
ORBS not recommended
[EMAIL PROTECTED] wrote: I would strongly recommend *against* using ORBS, because it blocks a lot of legitimate mail. Agreed. (I cut a similar caution for space reasons; should've just omitted mention of ORBS.) Fascism is seductive to techies--in particular, the ORBS fellow does seem to have a bit of a god complex. http://www.orbs.org/bugtraq.html gives a good example. Len. -- Unfortunately, spammers make their ``bad'' messages indistinguishable from ``good'' messages. Whatever you try, they will avoid it. -- Dan Bernstein, author of qmail
Re: Linux kernel turning for mail performance?
[EMAIL PROTECTED] wrote: I strongly _dis_recommend mounting ext2fs filesystems sync. The system I described earlier had _terrible_ performance at first, it turned out this was because I followed the FAQ and mounted it sync. Agreed; that's a serious issue. I would recommend switching to a better synchronous filesystem, though, rather than using ext2 async. Unfortunately, Linux offers few choices there. The BSD fs would be great if it wasn't so immature under Linux; raiserfs might be just as good (I don't know). It's rumored that ext3 will be journalled, synchronous and real real fast--we'll see. Yes, mounting it async is bad for reliability, so decide for yourself. The question underlying my recommendation to mount sync was: Would a speed test be completely valid if reliability corners were cut? Since a Linux box seldom goes down, you could 1) buy a 2-hour UPS, and 2) mount a ramdisk on /var/qmail/queue (untested). Still ``pretty'' reliable, but I bet that queue performance goes sky-high. Len. PS Then again, ``Profile--don't speculate.'' Mounting ext2 async might approximate the performance of a ramdisk, since that's roughly what ``async'' means. -- There's an engineering term for systems like that: ``garbage.'' -- Dan Bernstein
Re: Linux kernel turning for mail performance?
[EMAIL PROTECTED] wrote: On Thu, 03 Feb 2000 09:05:35 -0500 , "Len Budney" writes: Unfortunately, Linux offers few choices there. The BSD fs would be great if it wasn't so immature under Linux; Using softupdates under *BSD gives you the reliability of sync (somewhat more, actually), with nearly the speed of async. In October of 1999, that wasn't quite true. Softupdates is less likely than async to produce an inconsistent filesystem, but is still vulnerable to data loss. ``In particular, if you put a mail queue on a softupdates filesystem, you can lose mail when the power goes out, just as if you were using Linux.'' -- Dan Bernstein, http://x38.deja.com/getdoc.xp?AN=539496358 From Dan's other comments in that thread, it appears that the rename() call returns success before the rename was committed to disk. Dan said ``mail programs'' rely on rename() to tell the truth. A look at the source code suggests that qmail is not one of them--qmail-queue doesn't use the rename() call. If link() is subject to the same complaint as rename(), then qmail probably _does_ have the same reliability problem on a softupdates filesystem as on an async filesystem. Len. -- Translate the patents into English and you will see that there is nothing new in the Sperry patent. The only way that Unisys can make money off this patent is by convincing gullible people to pay them. -- Dan Bernstein
Re: Linux kernel turning for mail performance?
[EMAIL PROTECTED] wrote: In my past 7 years of using Linux I have never seen an ext2 filesystem that fsck could not fix. In my 7+- years, I haven't either. My worst experience was the time I had to use the -b option (fsck told me to, so I did, and it worked). I've lost about 3 files in that time to ext2 inconsistency--not too bad. Getting back on topic, I use an ext2 async filesystem for qmail. I use ext2 sync for /var/qmail/queue. But I handle so little mail, that the fs doesn't visibly impact latency. The chances of my machines going down at the exact moment that email could be lost seems pretty small. For high volume sites with reliability requirements a journalling filesystem like ext3 should probably be used. Sounds exactly right to me. (For 'reliability requirements' I'm reading, 'handles other peoples email'.) Len. -- Early to bed and early to rise makes a man tired and grumpy. -- Dan Bernstein
Re: Linux kernel turning for mail performance?
Jeremy Hansen [EMAIL PROTECTED] wrote: Is there any kernel sysctl or otherwise parameters suggested for performance using qmail on Linux? Open file handle limits, share memory, whatever? I have a goal to send at least 1 million emails in a 24 hour period from a single machine. The main suggestion has already been made: raise concurrencyremote to 255 and buy lots of memory. If money is not an object, you can also install several SCSI drives and stripe /var/qmail/queue across those disks. (Mount the filesystems with the "sync" option, for reliability.) Disk I/O is a potential queue bottleneck, especially on one-disk Linux boxen. Also, you might want to look for faster filesystems than ext2--but what, I'm not sure. If money _is_ an object, then save memory every way you can. That includes, * Never running X on the qmail server. * Deactivating inetd. Turn on _critical_ services using tcpserver and supervise, with _very_ low connection limits (e.g., 2 simultaneous telnet connections). * Turn off all unused daemons. This probably includes lpd, nfsd, mountd, the portmapper and RPC daemons, Apache, ftpd, and most services run from /etc/inetd.conf. (For security's sake, you might turn on sshd and throw away telnetd entirely. Throw away sshd if remote admin is not an issue--not!) * Throw away or reconfigure ``locate''. The locate database is rebuilt daily, causing a several-minute spike in disk usage. I'd be surprised if _kernel_ tuning were an issue. The reason qmail smokes is that it is extremely thrifty of system resources. You might tinker with priorities, though. Re-nice-ing one or more of the qmail daemons may keep qmail running strong during times of system load. After all, that's what priority means! Good luck! Len. -- Huh? There are lots of packages with compiled-in pathnames. Ever tried moving X? -- Dan Bernstein
Re: open relay problem
Jeff Mayes [EMAIL PROTECTED] wrote: 192.168.1.:allow,RELAYCLIENT="" 127.:allow,RELAYCLIENT="" According to what I've read, this should allow only users with 192.168.1.* to use my server as a relay. That's correct. But when I test remotely, the test messages are allowed through. Any input would be much appriciated. Were the test messages addressed to local users on your qmail server? If so, qmail wasn't _relaying_ mail; it was just accepting _incoming_ mail. With the above tcprules, connecting from a remote host, mail addressed to _other remote_ servers should be refused. (You did tell qmail-smtpd to use those rules, right? You need to invoke it with the options "-x /etc/tcp.smtp".) Len. -- ``It's the delivery speed, stupid.'' -- Dan Bernstein, author of qmail
Re: Restrict Times
Mark Delany [EMAIL PROTECTED] wrote: What made you think you had to use a qmail specific feature to achieve this result rather than something general to Unix? Exactly right. As someone well-known once said, ``This is UNIX. Stop acting so helpless.'' However, killing the POP listener was just an example--I wouldn't recommend it. If you happen to use qmail-pop3d, you could write a replacement for checkpassword which, instead of checking the password, prints out "-ERR pop server offline between 2pm and 4pm daily" and exits. Using cron, you could change a symlink to point to it, instead of checkpassword, at the right times. (Disclaimer: if you write this, make sure it plays nicely with qmail-popup! It will run as root; make it bug free. Check qmail-popup for proper exit codes, whether you _must_ read stdin, etc.) Len.
RE: Negatives in grammar
Dave Sill [EMAIL PROTECTED] wrote: For example, if you boast, ``I can build a Linux mail server in under an hour,'' I might reply, ``So can't my mother.'' Which most of the English speaking world would interpret as "My mother can't do that", Perhaps. But who cares about ``most of the English speaking world'' when I am speaking with fellow New Englanders? This type of idiom leads to ambiguity, and is a barrier to communication--its only purpose is to be cute. Not. It's correct usage of the local dialect, and perfectly clear to its native speakers. In many contexts, standard American English is the correct dialect for clear communication. But that hardly makes it the best choice in every context. I've met speakers of many dialects who do not understand standard English. You're free to call them slack-jawed morons if you wish, and ignore them--but the best way to communicate with them is in their native dialect. As for ``That is true, isn't it?'' you are still wrong. The idiom is in fact good standard American English. So despite your logicians quibble, it causes no ambiguity--except for people who don't understand standard English. Len. PS My last post on this thread. We've abused the list charter enough.
RE: Negatives in grammar
Dave Sill [EMAIL PROTECTED] wrote:
UTC is GMT, right?
Since the assertion is false, the answer is clearly negative ("no" or
"wrong"). Throwing the "not" before the assertion reverses it:
UTC is GMT, not right?
You are being pedantic, are you not? Yes--and you're mistaken. This
particular use of 'not' is purely idiomatic. (Indeed, many languages
have an identical idiom. There is something linguistically significant
going on here.)
In English, ``Is that true?'' and ``Isn't that true?'' and ``Is that
not true?'' all mean exactly the same thing: the opposite of ``Is that
untrue?'' The 'not' in the latter two sentences is a particle of emphasis,
not a negation.
In other words, ``Is that true?'' carries no connotation concerning
whether you think it is or is not true. But ``Isn't that true?''
carries the connotation that, though you are asking, you already believe
it to be true. You are asking for confirmation, rather than information.
A look at the original post will confirm that this exactly how Mr. Yelich
was using the idiom.
Len.
PS We New Englanders use negatives in other contexts as particles of
emphasis. For example, if you boast, ``I can build a Linux mail server
in under an hour,'' I might reply, ``So can't my mother.''
(For non-New Englanders, the reply means, ``My mother also can, so
what's the big deal?'' The idiom is most often used in the sentence,
``So can't anybody!'' The usage is sarcastic, and for that reason
adults generally don't use it.)
Re: store and forward? - firewall - not final destination
Jennifer Tippens [EMAIL PROTECTED] wrote: So mail comes to our firewall, no problem. Big problem, if you were running sendmail. You don't want anyone owning your firewall! A better idea, if you have the resources, is to create a DMZ, put your mail server in it (running qmail), and pass packets for firewall:25 through to mailserver:25 with your filtering/forwarding rules. Since your outside firewall should consider the DMZ untrusted, losing your mail server to crackers doesn't directly endanger your entire network. What we would like to do is have all mail forwarded through the firewall to an internal machine. I understand that I could do this with .forward or fastforward... A better way is my suggestion above: don't forward messages; forward at the connection level. but I thought that if I did that and the internal mail server went down for any weird reason that the mail would bounce. Only if it goes down and stays down for several days. MTA's know about temporary failure, and they try again. What I would like is for the mail to spool up on the firewall if the internal server is down. It already spools up on the MTA machines; why bring the resource cost upon yourself? Hopefully, your internal mail server is approximately as reliable as your firewall, of course. It's not in a public cluster, being used to play freecell, right? What is the best way to handle this? We have a lot of users. Best or not, my suggestion dramatically saves resources. It likely enhances security, as well. Your firewall shouldn't even have normal users (except one for you). Qmail is invulnerable, but moving your mail queue inside reduces exposure and avoids duplication of queues, and the need for a big disk on your firewall box. HTH, Len. -- Are they aware that the Internet doesn't _have_ a reliable receipt mechanism? Netscape is advertising a feature that it can't deliver. -- Dan Bernstein
Re: MUA's, Maildir and folder formats
Kristina [EMAIL PROTECTED] wrote: Which MUA's are not compatible with the Maildir format? Stephen Mills mentioned pine, elm, mutt and mew. He missed pgnus, and maybe other MUAs. But "MUA support of Maildir" can mean two things. It can mean that the mailer allows _folders_ to be maildirs, or it can mean that the mailer allows _spools_ to be maildirs. AFAICT all mailers (except possibly mutt) take the latter approach. They receive mail _from_ maildirs _into_ their native folders. FWIW, Dan once argued that maildirs are good as spools, but not great as folders. He suggested that a folder be a single file, with each message compressed separately, plus an index file locating the start of each message. It's a pretty good suggestion. Does any mailer support anything like this? On the other hand, I have thought maildir a _good_ folder format; it tolerates asynchronous updates very well. In the past my practice involved 1) mail incorporated asynchronously, 2) me using an emacs MUA, and 3) me using a CLI from home, possibly with emacs still running at work. The only format flexible and resilient enough for all that is mh-mail. Does anyone know something better? Len. -- This thread is cross-posted to comp.security.unix, where we take a dim view of ignorant programmers writing security-critical software. -- Dan Bernstein
Re: Maildir format
Kristina [EMAIL PROTECTED] wrote: Do I need a .qmail file to configure the maildir format. No. If you make "./Maildir/" the default delivery instruction, then it will work even if nobody has a .qmail file. BUT! qmail can _deliver to_ a maildir. It can't _create_ a maildir. For existing users, you must do the following (as root): su - ~USER /var/qmail/bin/maildirmake Maildir You can arrange for new users to get a maildir automatically. Just create a maildir in /etc/skel (or wherever your system keeps its home-directory template). Len. -- I'm not going to spend code space blindly duplicating sendmail features. -- Dan Bernstein, author of qmail
Re: PGP Server authentication and DUL list
"Subba Rao" [EMAIL PROTECTED] wrote: ...to avoid the wrath of being rejected by the Dialup Users List (DUL)? Has DUL rejection been a problem for you personally? In my own experience, it hasn't. (My home machines do use a smarthost. My laptop does direct SMTP, because changing smarthosts as I travel is a pain. Yes, that distorts the statistics somewhat.) If you are afraid of DUL, but have not actually seen it cause many bounces, then you can try the following: 1. Set your machine for direct SMTP delivery. 2. When an email bounces, decide whether you care. * If no, do nothing. Perhaps tell the person why you won't write to them anymore. * If yes, add an smtproute for that domain through your smarthost. Perhaps tell them why their mail will experience delays (in my case, up to a week if I'm on the road). 3. Using qmailanalog, estimate how much of _your_ mail is actually affected by this heavy-handed "spam fighting technique". Laugh to yourself. Len. -- I don't care what Keith does to messages that really _are_ spam. But I am not willing to accept collateral damage from his anti-spam software. -- Dan Bernstein
Re: spam filters
Tonino Greco [EMAIL PROTECTED] wrote:
I would like to know how to get spam filters set up?
RBL blocks mail from domains which either 1) have been reported for
relaying spam, or 2) are willing to relay _any_ mail, which of course
includes spam. Using RBL blocks some spam, and some legitimate mail. The
point is to put social pressure on bad Internet citizens.
I have installed rblsmtp and it is running - but it does not seem to
be blocking??
How do you know? Do you mean that mail from a blacklisted domain is
getting through? Or do you mean that you are still receiving spam?
Understand: you will not prevent all spam from reaching you. Spammers
try to make their mail look exactly like "good" email: _you_ can tell
the difference, but often your _computer_ can't.
Ad hoc filters, can trap some spam. Stricter filters, more spam. BUT
strict filters will throw away legitimate email. Some examples:
1. Messages whose headers violate RFC 822 (can discard good mail)
2. Blind carbon copies (_will_ discard mailing list postings)
3. Messages with all-caps subjects (might discard good mail)
4. Messages with exclamation marks in subjects ("You're an uncle!")
5. Messages with "unsubscription information" inside (probably OK)
6. Mail with "money" or "$" in the subject ("We got the deal! Big money!")
7. Mail from anyone not on your "approved" list
8. Mail which doesn't contain the day's password in the subject
9. Mail containing any word in a dictionary of bad words
...
Only you can decide whether to shoot in self-defense; it's only your
problem if in so doing you shoot your daughter.
Len.
--
You seem to think that spam is a pattern-recognition problem. It isn't.
You're ignoring the anti-fax effect: anti-spam rules become useless when
enough people start using them. Spammers adapt.
-- Dan Bernstein
Re: MUA's, Maildir and folder formats
[EMAIL PROTECTED] wrote: On Wed, Jan 12, 2000 at 12:38:55PM -, Lorens Kockum wrote: On the qmail list [EMAIL PROTECTED] wrote: On the other hand, I have thought maildir a _good_ folder format; it It is deathly slow on big folders. True. Then again, many mbox clients are also deathly slow--around 1,000 messages, VM under emacs becomes intolerable (it's part of why I switched to MH; bad or not, it scaled better). I think a seperate index file would be a good idea, shouldn't be too hard to do correctly. That would require locking, which goes against the Maildir-philosophy. It would not require locking unless messages are archived asynchronously, which they need not be. The maildir philosophy is for _safe spooling_. Lorens is replying to my post about _efficient archival_. Len. -- Security through obscurity, without the obscurity. -- Dan Bernstein
Re: MUA's, Maildir and folder formats
Russell Nelson [EMAIL PROTECTED] wrote: Len Budney writes: FWIW, Dan once argued that maildirs are good as spools, but not great as folders. Misquote alert! My fault! Dan didn't say that maildirs are "not great as folders". I don't have the exact quote, but what he said was that maildir was never intended as a format for message archival. I don't think Dan defined "archival", but I believe he meant long-term storage, with maildir as the folder structure for recent messages. Pardon me for conflating "recent messages" with "spooling"; I badly overstated what Dan actually said. What if you want mail to be deliverable into folders, using extensions? Maildir is of course the way to go. As I remember it, Dan was suggesting that an archival format should save space [and inodes], and allow faster mailbox scanning. The format he alluded to accomplishes this. For asynchrony, maildir rules the world. But uses space and inodes, and scans slowly. A hybrid solution, involving both, would be highly desirable. Len. -- There are two people at fault in every computer security breach: the attacker, and the programmer who let him in. -- Dan Bernstein
Re: off-topic: Dan's engineering methods
Sam [EMAIL PROTECTED] wrote: There are already existing tools out there Read what I wrote, including references. Reading the archives, I already learned your opinion. You argued at length that autoconf and automake are better. That wasn't my question. the necessary resources to build a module hierarchy http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html. Peter Miller argues cogently why recursive make subverts dependency checks. His solution is GNU-make dependent, which subverts portability. Probably on purpose, Dan's method solves the same problem yet is portable. It's quite convenient to package standalone modules as individual subdirectory I already know that. I also know how common it is to link against the wrong version of a library. "rm config.cache" (your suggestion) and/or "make distclean" (Russ Allbery's) are not the right way to ensure correct dependencies. Make, a triumph of AI, was designed for that purpose already. Len.
Re: off-topic: Dan's engineering methods
Sam [EMAIL PROTECTED] wrote: You question was how to create and use reusable code modules. I told you how. I'm sorry to see that you can't read. Has Dan has revealed enough about his engineering methods for others to duplicate them? Does anybody want to, possibly producing sharable tools? Given the quality of his results, his methods might be worth imitating. ^^ ^^ I already know that. I also know how common it is to link against the wrong version of a library. Really? Has that happened to you, or are you just theorizing again? It is indeed a major source of support calls from IT departments [1], yes. "Did you try 'make distclean;make'?" When I have enough influence on a project, I make sure that Makefiles have an 'over' target, which depends on 'distclean' and 'all'. Customers quickly adopt the convention of trying 'make over'. If make could check dependencies accurately, this would not be necessary. Make was designed to save time [2]; it should do the right thing. Rebuilding _everything_ (or just the libraries), every time, because make can't see all dependencies, is asinine. For that a trivial shell script would suffice. Len. PS Unless you learn to read, I will not reply to you again. I don't want to waste everyone's time--this stuff has been explained to you before. -- [1] I generally work for systems integrators. Our customers, steel mills and such, still have IT departments. They demand source code with deliverables, and have for over 20 years. They handle maintenance in-house, using the integrators for support. [2] Dan's configuration trick works an order of magnitude faster than autoconf. Screwing with dependencies means another iteration of 'rm config.cache;./configure;make' which incurs the cost all over again; Dan's way, the right dependencies are rechecked. Build time is dramatically faster Dan's way than yours. Which is what make was built for.
Re: 7 bit ascii qmail
Sam [EMAIL PROTECTED] wrote: ..."dropped"..."bounced"...slandering AOL. Sue me. Are you worth it? Seriously, my point was 1) clarify what you meant before, and 2) say what you mean in the future. If you don't, the cost/benefit ratio in talking to you drops way low. Len.
Re: 7 bit ascii qmail
Sam [EMAIL PROTECTED] wrote: the cost/benefit ratio in talking to you drops way low. Boo-hoo. Fine; build your own MTA which conforms to your own vague requirements and doesn't do the *something* that you don't like (drop messages? bounce messages? burn messages?). And make sure it interoperates with a _majority_ of _existing_ clients and servers. Len. -- I don't have a killfile; I'm just ignoring you.
