From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/5433 Path: main.gmane.org!not-for-mail From: eichin@cygnus.com Newsgroups: gmane.emacs.gnus.general Subject: Re: Request for "maildir" support Date: Mon, 4 Mar 1996 11:56:33 -0500 Message-ID: <199603041657.RAA10457@ifi.uio.no> References: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035146037 300 80.91.224.250 (20 Oct 2002 20:33:57 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:33:57 +0000 (UTC) Cc: ding@ifi.uio.no Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by deanna.miranova.com (8.7.3/8.6.9) with SMTP id JAA17456 for ; Mon, 4 Mar 1996 09:40:05 -0800 Original-Received: from scuba.cygnus.com (scuba.cygnus.com [192.80.44.19]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 4 Mar 1996 17:57:10 +0100 Original-Received: by scuba.cygnus.com (1.39.111.2/16.2) id AA101928593; Mon, 4 Mar 1996 11:56:33 -0500 Original-To: ratinox@ccs.neu.edu In-Reply-To: (message from Stainless Steel Rat on 04 Mar 1996 10:21:20 -0500) Xref: main.gmane.org gmane.emacs.gnus.general:5433 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:5433 -----BEGIN PGP SIGNED MESSAGE----- Date: 4 Mar 1996 There are *so* many misconceptions (not just disagreements of opinion, which I could easily abide, but factual errors) that I feel compelled to respond, as a qmail beta tester, and a security professional. (I'd actually like to see maildir support in ding, even though I'll most likely continue to only use movemail-based POP support -- it would be nice to have at least one *reliable* non-pop delivery mechanism, regardless of what mailer implements it.) > So much for standards :). When standards are broken, it's long past time to develop new ones :-) >I would suggest someone inform this person about Eric Allman's v8 >sendmail, 8.7, which is about as secure and reliable as you can get Yep. Unfortunately, "secure as you can get", with sendmail, is "not at all." Did you see last weeks "dns spoofing" vulnerability problem? It's yet another in a long running series of the kind of problem you have when you *design* a program to have back doors (yes, I mean that. The sendmail "DEBUG" mode exploited by the Morris Internet worm, back in 1988, was a *deliberate* inclusion, because Allman couldn't get root access to the machine he was maintaining sendmail on originally... and the feature didn't get completely rooted out until years later...) > Ahem. This is bullshit. NFS is infamous for it's inability to do > exactly this, and no matter what you do to get around it you will still Turns out that creating multics-style timestamp-based names which are unique in and of themselves works fine - you don't have collisions because you're *never* working on the same file. It *is* possible; you just have to be more clever than people have in the past... > a modicum of clues running large mailing lists uses a caching MTA like > v8 sendmail with bulk_mailer, which I have found to work exceptionally Well, no. vger.rutgers.edu is running zmailer, because sendmail just couldn't handle the linux-* mailing lists, even with a multi-cpu machine with 256M of RAM... David Miller has to work quite closely with the author of zmailer to get even that to work, but sendmail isn't even in the running. > Users handle their own mailing lists != "simple", from my experience > both as a Majordomo list and server administrator. Perhaps that's because exsisting techniques are primitive? He really has come up with some quite clever things -- we may need some more practice with them, but what he's got does work. > v8 sendmail does it internally. All you need to do is configure a > couple of options in sendmail.cf That *alone* is a condemnation :-) But it also means that you're stuck with sendmail's precise scheduling techniques; you don't have nearly the control that you get with a modern inetd and qmail. > And then there's simple fact that in a "unified" system if one little > thing breaks the whole thing goes down, whereas in an "modular" system You mean the way that if you make a single typo in your sendmail.cf everything goes down? :-) qmail *is* quite modular. From your comments, I think you'd be surprised with what you'd find by looking at it. > This whole thing reminds me a lot of SMail and how it absolutely failed > in many ways to "fix" perceived "problems" in sendmail. Not that I am Smail didn't even handle *obvious* things like MX records, at least at first. qmail is written by someone who reads and has written RFC's... > with an MTA that is written and maintained by someone I know knows to > write and support a reliable, secure MTA. I wonder who that could be. Sure isn't Eric Allman :-> If you'd like to know more, you could join the qmail beta test; the release actually includes a number of detailed explanations of the issues involved. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4beta, an Emacs/PGP interface iQCVAwUBMTsgl1y/7Dlmzom3AQHi6gP7BNtPsxZEN9Gw4j90VC/LChBDcg/dJrXF H6kUl8wbfrgFAGQQixyd9YZpNDTiLZ9M9DP+NceO56kcFnxqeLj1LCbi3v7+5Chf cyqdRo+M6BI3DcNecGHSt/2U7MhAxME6o89XHcHaxmgU89Bc2xiy5l30iM9akDP5 jGXMwm6ix3w= =fpfr -----END PGP SIGNATURE-----