Re: MTA Suggestion
On Sun, 16 Nov 1997, Joey Hess wrote: no it's not difficult. the PITA factor comes in because it has to be done for every account. As i said, i use procmail as the local delivery agent - which means that i need a global setting for it, not a per- user setting. Take a look at qmail 1.01-2 (actually, look at qmail-src, which creates that package). thanks for the suggestion (and the script) but i've already decided that qmail is not for me. it doesn't do anything i need which can not be done using tools which are compatible with my current setup. craig -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: MTA Suggestion
Craig Sanders wrote: | preline procmail isn't all that difficult. no it's not difficult. the PITA factor comes in because it has to be done for every account. As i said, i use procmail as the local delivery agent - which means that i need a global setting for it, not a per- user setting. Take a look at qmail 1.01-2 (actually, look at qmail-src, which creates that package). Using this version, you can edit the /etc/init.d/qmail file to something like: alias_empty=|/usr/local/bin/qmail-procmail I couldhave just put |preline procmail there, but my qmail-procmail script does a few things to return codes that are useful. Here it is: #!/bin/sh # # This script is used to get qmail to run procmail for every delivery. # Script by: Philip Hands [EMAIL PROTECTED] /usr/bin/preline /usr/bin/procmail exit 0 # check if procmail returned EX_TEMPFAIL (75) [ $? = 75 ] exit 111 # otherwise return a permanent error exit 100 -- see shy jo -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: MTA Suggestion
Actually it CAN do uucp transport, it does not do !path addressing. As long as the UUCP site that it is sending to can understand internet style addressing (which just about all do), there is no problem. On 10-Nov-97 Peter Mutsaers wrote: On Sat, 08 Nov 1997 00:30:22 -0800 (PST), George Bonser [EMAIL PROTECTED] said: GB I would like to request that exim replace smail as the default GB MTA for Debian. Bad idea. It doesn't do UUCP, which is still widely used. smail (and sendmail) do. -- /\_/\ ( o.o ) Peter Mutsaers | Abcoude (Utrecht), | Trust me, I know ) ^ ( [EMAIL PROTECTED] | the Netherlands| what I'm doing. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] . -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: MTA Suggestion
For anyone planning to write new code using /var/spool/mail or /tmp: http://www.netspace.org/lsv-archive/bugtraq.html contains many examples of insecure code produced by programmers who thought, incorrectly, that they understood how to use world-writable directories. it is not at all difficult to set the permissions on /var/spool/mail correctly, and it is trivial to make adduser (or whatever other user creation procedure you use) run touch /var/spool/mail/USER ; chown USER.mail /var/spool/mail/user Sorry, but the real world doesn't work that way. Most MUAs---including, for example, every MUA that does dot-locking---need mailboxes in a writable directory. That means either * a world-writable directory, which has historically been a disaster, and which continues to cause security problems in new MUAs; or * a group-mail-writable directory, with MUAs all setgid mail, which has historically been a disaster, and which continues to cause security problems in new MUAs; or * a user-owned directory, which is trivial to handle safely. Notably absent from your commentary has been any explanation of the _disadvantages_ of putting mail in a user-owned directory. Yes, of course there are transition costs, which is why people can continue to use /var/spool/mail with qmail until they're comfortable switching. your NFS-based arguments against /var/spool/mail Once again: My discussion of /var/spool/mail has nothing to do with NFS. (Big ISPs have another problem with /var/spool/mail: on most systems, reading a large directory takes a long time.) which is an argument against maildir, is it not? No. The scaling problems with /var/spool/mail are both quantitatively and qualitatively much more severe. (Note that maildir is designed only for reliable handling of incoming messages, not for long-term storage.) maildir may have some advantages in an NFS environment, As I already explained, maildir has advantages in any environment. what's the point of having your mail in this great new format if you cant find a mail reader which can use it? It is an _option_. Right now it's supported by qmail-pop3d and mutt and a patched version of pine; as more readers support it, more users will be able to switch to it. That's called ``progress,'' not ``problem.'' Change ./Mailbox to '|preline procmail' in the qmail-start invocation. why isn't this in the FAQ? It's discussed in the INSTALL files for 1.02. See, some users _ask questions_ and _suggest improvements_ rather than spewing misinformation all over the net. what about relaying TO particular host/domain names? Add the domain names to rcpthosts. ---Dan Put an end to fake mailing list subscriptions. http://pobox.com/~djb/ezmlm.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
[side question] Re: MTA Suggestion
My /etc/procmailrc rules catch nearly all of the spam which makes it through the spamm address, domain and IP blocking rules. Are you willing to share your procmail rules? It would be quite nice to have these for myself to get rid of the spam which is arriving in ever increasing droves to my mailbox... Thanks, Adam. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: MTA Suggestion
C'mon guys, leave it alone. This flamefest is getting us nowhere. Whether or not maildir or mbox is the way to go, the point is that qmail cannot be Debian's preferred MTA because Debian does not consider qmail to be DFSG free. This renders any fight over whether qmail is better than other MTA's moot. As far as Debian is concerned it is a non-free package and cannot be distributed with the main distribution. (Although it will be distributed from the Debian non-free directory by ftp) This is not my decision, nor necessarily my opinion. This is just the way it is according to current Debian policy vis'a'vis the current qmail license. Please take the advocacy and religious wars somewhere else. Thanks, Behan -- Behan Webster mailto:[EMAIL PROTECTED] +1-613-224-7547 http://www.verisim.com/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: [side question] Re: MTA Suggestion
On Wed, 12 Nov 1997, Adam Shand wrote: My /etc/procmailrc rules catch nearly all of the spam which makes it through the spamm address, domain and IP blocking rules. Are you willing to share your procmail rules? It would be quite nice to have these for myself to get rid of the spam which is arriving in ever increasing droves to my mailbox... certainly, here it is. btw, if you don't want to keep spam in a spam folder then you can make procmail bounce it with an error code. however, bouncing spam once it has arrived on your system is usually a waste of time and just clogs up your mail queue because most spammers won't receive mail...better to just file it in /dev/null. VERBOSE=OFF PATH=$HOME/bin:/usr/bin:/bin:/usr/local/bin:. LOGFILE=/root/Mail/from-all LOCKFILE=$HOME/.lockmail :0 * ^TO([EMAIL PROTECTED])|(free4u2.com) /root/Mail/SPAM :0 E * ^FROM([0-9]+@)|(@widexs.com)|([EMAIL PROTECTED]) /root/Mail/SPAM :0 E * (^X-Advertisement:)|(^X-[0-9]: ) /root/Mail/SPAM :0 E * ^received:.*(cyber\-bomber|CLOAKED|from unverified source) /root/Mail/SPAM # impossible ip address in Received: line - one of cyberpromo's tricks. :0 E * ^Received.*\[[0-9\.]*([03-9][0-9][0-9]|2[6-9][0-9]|25[6-9]) /root/Mail/SPAM I also have these lines in there, but commented out. I subscribe to the SPAM-L digest and checking the message body is likely to catch mail from that list. when i get some spare time i'll fix these rules so that they don't interfere with SPAM-L: # now check the body of the message for spam #:0 BE #* (EVALUATING MULTI-LEVEL SALES PLANS|SOURCES FOR THE BEST MAILING LISTS|MAJOR CORPORATIONS AND MULTI-LEVEL SALES|HOW TO MAKE $250,000 THROUGH MULTI-LEVEL SALES) #/root/Mail/SPAM # #:0 BE #* (CREDIT CARDS ACCEPTED|GROUND[ -]*FLOOR OPPORTUNITY|Removal instructions|Internet Market(ing|er)|apologize for any inconvenience|Bulk Email|using Extractor Pro) #/root/Mail/SPAM -- craig sanders networking consultant Available for casual or contract temporary autonomous zone system administration tasks. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: MTA Suggestion
On Sat, 08 Nov 1997 00:30:22 -0800 (PST), George Bonser [EMAIL PROTECTED] said: GB I would like to request that exim replace smail as the default GB MTA for Debian. Bad idea. It doesn't do UUCP, which is still widely used. smail (and sendmail) do. -- /\_/\ ( o.o ) Peter Mutsaers | Abcoude (Utrecht), | Trust me, I know ) ^ ( [EMAIL PROTECTED] | the Netherlands| what I'm doing. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: MTA Suggestion
i couldn't even get it to use procmail as the local delivery agent instead of qmail-local Change ./Mailbox to '|preline procmail' in the qmail-start invocation. qmail might be excellent at what it does but it's incompatible with /var/spool/mail. qmail can run binmail as the delivery agent the same way sendmail does. Of course, I don't recommend this, since many systems have insecure versions of binmail. See, for example, CERT advisory 95:02. it's anti spam features don't seem as good as Claus Assman's check_* rules for sendmail 8.8.x By default, qmail refuses SMTP mail not addressed to the local host. You can selectively allow relaying from particular IP blocks; see FAQ 5.4. debian has managed to produce an NFS safe locking library, That is incorrect. Debian mailbox locking will fail under high loads. libfilelock_0.1-2, like every other dot-locking library with stale lock removal, requires that clients actively refresh locks within a specified period of real time. Unfortunately, UNIX is not a real-time system. Example: The delivery agent is about to write the last block of a message to a mailbox that it has ``safely'' locked. The write takes ten minutes to get through to the server. Meanwhile, an MUA on the server sees the ``stale'' lock file, removes it, and reads the mailbox---with a truncated message. Oops. Reliability means never having to say you're sorry. there's also the 'minor' problem that only a few MUAs (i don't know of one except for qmail-popper) will work with qmail's new maildir format. maildir is an _option_ in qmail and mutt and exim. It is not the default; if you don't want it, don't use it. I find it very strange that you refer to this as a ``problem.'' and any site running an automounter daemon for user home directories would be overloaded by qmail insisting on delivering mail to ~ By default, sendmail looks for .forward in the user's home directory. Either you suffer through automounting or you have unreliable .forward handling. Of course, you can move .forward somewhere else---but the same is true of .qmail and Mailbox. in summary, i think that his reasons for doing things the way he does are, for the most part, ill-informed opinion and bigotry. Security and reliability are not matters of opinion. ---Dan Put an end to fake mailing list subscriptions. http://pobox.com/~djb/ezmlm.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: MTA Suggestion
the point was that his NFS argument against /var/spool/mail was irrelevant because home directories are often NFS mounted too There is no ``NFS argument against /var/spool/mail.'' The fundamental problem with /var/spool/mail is security. It's not easy to handle a world-writable directory safely. (Big ISPs have another problem with /var/spool/mail: on most systems, reading a large directory takes a long time.) As a separate issue, mbox format is unreliable when the system crashes. It doesn't matter whether mailboxes are stored in home directories or in a central directory. The relevance of NFS is that it makes mbox format even more unreliable; you can lose mail even if the systems never crash. ---Dan Put an end to fake mailing list subscriptions. http://pobox.com/~djb/ezmlm.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: MTA Suggestion
On 11 Nov 1997, D. J. Bernstein wrote: the point was that his NFS argument against /var/spool/mail was irrelevant because home directories are often NFS mounted too There is no ``NFS argument against /var/spool/mail.'' except for your argument that /var/spool/mail is unsafe in an NFS environment. The fundamental problem with /var/spool/mail is security. It's not easy to handle a world-writable directory safely. it is not at all difficult to set the permissions on /var/spool/mail correctly, and it is trivial to make adduser (or whatever other user creation procedure you use) run touch /var/spool/mail/USER ; chown USER.mail /var/spool/mail/user (Big ISPs have another problem with /var/spool/mail: on most systems, reading a large directory takes a long time.) which is an argument against maildir, is it not? craig -- craig sanders networking consultant Available for casual or contract temporary autonomous zone system administration tasks. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: MTA Suggestion
On 11 Nov 1997, D. J. Bernstein wrote: i couldn't even get it to use procmail as the local delivery agent instead of qmail-local Change ./Mailbox to '|preline procmail' in the qmail-start invocation. why isn't this in the FAQ? qmail might be excellent at what it does but it's incompatible with /var/spool/mail. qmail can run binmail as the delivery agent the same way sendmail does. Of course, I don't recommend this, since many systems have insecure versions of binmail. See, for example, CERT advisory 95:02. on the other hand, NOT all systems have insecure versions. Some of your concerns, especially re: security are quite validothers, however, like your insistence that ~/Mailbox is somehow superior to /var/spool/mail, are too context-dependant. For those that are insecure, there are other (less drastic) ways of fixing the problem. e.g. 'login' is insecure on some systems...does that mean that unix should throw away the entire method, or should it just fix the problem? too many other things break when you arbitrarily make such radical changes to the system. The fact is that, for most people, the few improvements offered by qmail are not worth the price of changing the way the rest of their systems are organised. it's anti spam features don't seem as good as Claus Assman's check_* rules for sendmail 8.8.x By default, qmail refuses SMTP mail not addressed to the local host. You can selectively allow relaying from particular IP blocks; see FAQ 5.4. what about relaying TO particular host/domain names? debian has managed to produce an NFS safe locking library, That is incorrect. Debian mailbox locking will fail under high loads. libfilelock_0.1-2, like every other dot-locking library with stale lock removal, requires that clients actively refresh locks within a specified period of real time. Unfortunately, UNIX is not a real-time system. i haven't tested this under high load conditions so i'll have to take your word on it. there's also the 'minor' problem that only a few MUAs (i don't know of one except for qmail-popper) will work with qmail's new maildir format. maildir is an _option_ in qmail and mutt and exim. It is not the default; if you don't want it, don't use it. I find it very strange that you refer to this as a ``problem.'' what's the point of having your mail in this great new format if you cant find a mail reader which can use it? i happen to dislike the way mutt works, so i do see that as a problem. There are many MUAs which work with /var/spool/mail mailboxes, there are several which can trivially be modified to use ~/Mailbox. There is 1 which works with maildir. and any site running an automounter daemon for user home directories would be overloaded by qmail insisting on delivering mail to ~ By default, sendmail looks for .forward in the user's home directory. Either you suffer through automounting or you have unreliable .forward handling. Of course, you can move .forward somewhere else---but the same is true of .qmail and Mailbox. which illustrates the point i was making, which was that your NFS-based arguments against /var/spool/mail are equally as valid against qmail's ~/Mailbox. maildir may have some advantages in an NFS environment, but it reminds me too much of the *.MSG format of fidonet - one file per message - which gets obscenely slow when there are many files in a directory. in summary, i think that his reasons for doing things the way he does are, for the most part, ill-informed opinion and bigotry. Security and reliability are not matters of opinion. there's more than one way to skin a cat. craig -- craig sanders networking consultant Available for casual or contract temporary autonomous zone system administration tasks. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: MTA Suggestion
On Mon, 10 Nov 1997, Remco van de Meent wrote: On Mon, 10 Nov 1997, Craig Sanders wrote: : I still don't know of any MUAs which will read mail from either maildir : or ~/Mailbox. admittedly, configuring pine or elm to read ~/Mailbox : rather than the usual spool dir is pretty simplebut that requires : every user on the system to reconfigure their mail client. Nope. Use /etc/pine.conf.fixed, to have ALL people's pine looking into the same place ($HOME/Mailbox). yep, good point. i forgot about that. craig -- craig sanders networking consultant Available for casual or contract temporary autonomous zone system administration tasks. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: MTA Suggestion
On Mon, 10 Nov 1997, Jason Costomiris wrote: On Mon, Nov 10, 1997 at 08:40:35PM +1100, Craig Sanders wrote: : Yeah, and? It allows you to streamline your quota setup. It also : allows you to have a smaller /var. : : what does the qmail way allow you to do with quotas which you : can't do with the standard /var/spool/mail? i can think of one thing : which the standard way allows which the qmail way doesn't: having : separate quotas for /home and /var/spool/mail Why should I have to manage quotas for three filesystems instead of two? I already quota /home and /tmp, why on earth would I want to have to manage it for /var too? because it's trivial to do? because you don't have to do it unless you need it? because it's less work than completely changing the way mail is handled on your system? but the bottom line is that it's YOUR system. run it however you like. My system is MINE, however, and i'll run them how *I* like. : Why do you need to do this? If your users need to sort their mail, : it's quite easy to use procmail in conjunction with a stock qmail : setup. You just need to read the FAQ. : : The FAQ told me how to use it from a ~/.qmail file. i didn't want to : know how to do that (it's damned obvious), I wanted procmail as the MDA. I agree with you, for machines with sendmail as the MTA. Procmail has less overhead than deliver or mail.local. However, it adds overhead on qmail systems, and isn't really used except for guys like us who read a bunch of mailing lists using shell accounts, instead of pop3 mailers that have their own filters. For the 5 - 10% of users that actually use procmail, I think making that ~/.qmail file that says: what this means is that (since procmail is such an important part of my systems' mail handling capabilities) qmail is not useful for me. | preline procmail isn't all that difficult. no it's not difficult. the PITA factor comes in because it has to be done for every account. As i said, i use procmail as the local delivery agent - which means that i need a global setting for it, not a per- user setting. : there are several reasons why i need to do this: : : 1. i don't have to have a |procmail ... .forward or .qmail file in :every user's home dir. Does every user on your box use its features, or does it just deposit mail in /var/spool/mail/$USER ? yes, as i said in my last message, it is part of my system's spam blocking setup. every user on my system enjoys the benefits of that. :i see procmail as an INTEGRAL part of my systems' mail :capabilities, not as a tacked on piece of cruft. Again, for YOU. Not for all of your users. As a system admin, you should be willing to have to take 30 seconds to setup your own environment, and have a nice, stable, secure, fast environment for the rest of your userbase. it's MY system. I really don't care if users wish to have their own ~/.procmailrc or not - that is entirely up to them. I, however, make great use of it to block spam. switching to qmail would involve a hell of a lot more time than 30 seconds. It would take days to duplicate the functionality of my current setup, and at the end of that time i would have a setup no better than what i already have. after that, i would have to enjoy the dubious pleasures of reproducing the setup on all of the mail systems that i am responsible for. : 2. procmail is part of my 4 tier spam filtering system. Why??? It's too late then. By that time, you've already accepted the mail. shit happens. i deal with it. no spam-blocking system can be 100% effective - there are new spammers and new spamming domains all the time. they have to spam at least once before they can get in any blocking list. My /etc/procmailrc rules catch nearly all of the spam which makes it through the spamm address, domain and IP blocking rules. If you want a more serious spam solution, contact Paul Vixie. He'll offer you BGP peering sessions that blackhole routes for spammers. i could make use of that if they also distributed plain text lists of spamming network/netmasks, however a lot of spam is relayed through other systems which are NOT blocked. blocking spam requires a multi-tier approach. : - sendmail check_* blocks incoming spam from known spam domains : and spam users, and also prevents spammers from hijacking my : systems You mean the way control/badmailfrom and tcpcontrol do? i suppose so. it seems like they are comparable features. : - procmail as local delivery agent catches a large percentage of the : spam which makes it through tiers 1 2 with a handful of simple : rules in the system-wide /etc/procmailrc file Too late again. You've already lost the battle by accepting the mail. Now you're on the run trying to get rid of it so you don't have to read it instead of concentrating on not accepting it to start with. no, the battle is lost if the spam gets
Re: MTA Suggestion
On 11 Nov 1997, D. J. Bernstein wrote: the point was that his NFS argument against /var/spool/mail was irrelevant because home directories are often NFS mounted too There is no ``NFS argument against /var/spool/mail.'' The fundamental problem with /var/spool/mail is security. It's not easy to handle a world-writable directory safely. (Big ISPs have another problem with /var/spool/mail: on most systems, reading a large directory takes a long time.) As a separate issue, mbox format is unreliable when the system crashes. It doesn't matter whether mailboxes are stored in home directories or in a central directory. The relevance of NFS is that it makes mbox format even more unreliable; you can lose mail even if the systems never crash. How about the argument you have problems, if the host exporting /var/spool/mail is a linux box, because linux's lockd ...well... needs some serious improvements in functionality ? Ciao, Martin -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: MTA Suggestion
On Mon, Nov 10, 1997 at 09:16:01AM +1100, Craig Sanders wrote: : qmail might be excellent at what it does but it's incompatible with : /var/spool/mail. Yeah, and? It allows you to streamline your quota setup. It also allows you to have a smaller /var. : the one time i installed it, i couldn't even get it : to use procmail as the local delivery agent instead of qmail-local Why do you need to do this? If your users need to sort their mail, it's quite easy to use procmail in conjunction with a stock qmail setup. You just need to read the FAQ. : there's also the 'minor' problem that only a few MUAs (i don't know of : one except for qmail-popper) will work with qmail's new maildir format. Uh, there's maildir2mbox, which you can use for that task. In addition, qmail comes with wrappers for pine and elm. : it's anti spam features don't seem as good as Claus Assman's check_* : rules for sendmail 8.8.x (which have been included with the latest : debian sendmail packages in unstable). they certainly don't seem : anywhere near as flexible. Uh, I've done a good deal of work constructing a set of check_* rules that I use to restrict relaying and drop spam. qmail was a snap by comparison. : but the biggest problem with qmail is the author's attitude. it would : be fine if he said here's the way i like things to run, so that's the : default...but if you prefer the old standard ways then make this change : and that change and everything will run sweetly. but he doesn't do : that, he says the old ways suck so you can't have them. you have to do : it my way even if my way sucks for your particular setup. tough luck. Yes, Dan Bernstein is called the Psycho Programmer from Hell by many. However, qmail rigidly implements the RFCs governing SMTP mail, which is a Good Thing, IMHO. : he goes on about nfs locking problems with NFS, ignoring the fact that : most NFS locking problems are related to sloppy programming. debian has : managed to produce an NFS safe locking library, so it's obviously not : impossible. and any site running an automounter daemon for user home : directories would be overloaded by qmail insisting on delivering mail to ~ : (and would still suffer from the NFS locking problem he is so worried : about) As opposed to the machine becoming overwhelmed from delivering to a /var partition that's mounted accross several machines, as you suggested with home dirs? : in summary, i think that his reasons for doing things the way he does : are, for the most part, ill-informed opinion and bigotry. there is some : substance to what he says but it's nowhere near as black and white as : the way he says it. : : finally, qmail is non-free. debian CAN'T use it as the default MTA. Hmmm.. It can be freely distributed, once the author approves of it. See ftp://koobera.math.uic.edu/www/qmail/dist.html for more info. -- Jason Costomiris | VMS is about as secure as a poodle [EMAIL PROTECTED] | encased in a block of lucite http://www.jasons.org/~jcostom/ | about as useful, too. #include disclaimer.h | --some guy I read on Usenet -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: MTA Suggestion
Hi, Jason == Jason Costomiris [EMAIL PROTECTED] writes: Jason On Mon, Nov 10, 1997 at 09:16:01AM +1100, Craig Sanders wrote: Craig finally, qmail is non-free. debian CAN'T use it as the default Craig MTA. Jason Hmmm.. It can be freely distributed, once the author approves Jason of it. See ftp://koobera.math.uic.edu/www/qmail/dist.html for Jason more info. That is not free, as Debian defines free ;-). Please see URL:http://www.debian.org/social_contract.html#guidelines manoj -- Life is better than death, I believe, if only because it is less boring, and because it has fresh peaches in it. Alice Walker Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: MTA Suggestion
On Sun, 9 Nov 1997, Tim Ferrell wrote: there's also the 'minor' problem that only a few MUAs (i don't know of one except for qmail-popper) will work with qmail's new maildir format. Actually this is not entirely true... You can set up qmail to use mbox files - but as you point out, the author strongly discourages this. NFS issues aside, I do not care much for maildir. yes, the debian qmail package in experimental/ even uses them by default. only problem is that a user's main mailbox file is in the WRONG place, in ~/Mailbox rather than /var/spool/mail/username where it belongs. I still don't know of any MUAs which will read mail from either maildir or ~/Mailbox. admittedly, configuring pine or elm to read ~/Mailbox rather than the usual spool dir is pretty simplebut that requires every user on the system to reconfigure their mail client. but the biggest problem with qmail is the author's attitude. The sad thing is that it is often difficult for most people to separate genuine issues from personal crusades... i see the author's attitude as being a genuine issue - his arrogance prevents him from being able to produce software which can be used by people with conflicting (and equally valid) ideas about how the mail system should work. I prefer to use software written by authors who are responsive to user's needs. finally, qmail is non-free. debian CAN'T use it as the default MTA. Why is it non-free? because you can't distribute modified source, modified binaries, or even pre-compiled binaries without special approval from the author. price is probably the least important factor in what makes a program free - the freedom is in freedom to modify and distribute, not in zero cost. Anyhow, I will stick with sendmail, despite its complexity - it is a known quantity and does what *I* like... ;-) me too. i look at other MTAs from time to time, just to keep up with alternative ways of doing things, but i haven't yet found a compelling reason to switch away from sendmail. vmail sounds like it will be good when it's released, but that was still in the design stage last time i looked at the vmail web pages (a few months ago...i'll dig up the url if you're interested). personally, i think that sendmail is actually simpler to configure than smail or eximor more precisely, debian's sendmailconfig script can configure a system which will meet the needs of wild guess 99% /wild guess users. run sendmailconfig, answer a few questions, and you end up with a sendmail.cf file which works. if you need something more complex, you can either edit /etc/mail/sendmail.mc or /etc/sendmail.cf directly. i know that debian's smail has a similar config script - i used to run smail a few years ago, before i switched to sendmail - and it's very useful too. I just find the million-and-one directories and files a lot more confusing than a single .mc or .cf file. sendmail also happens to be the best documented MTA around - there's at least 2 or 3 good books devoted to sendmail. this was one of the reason i finally gave up on smail - i couldn't find any books on smail anywhere (the bat book isn't what i'd consider light reading but at least it exists). craig -- craig sanders networking consultant Available for casual or contract temporary autonomous zone system administration tasks. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: MTA Suggestion
On Sun, 9 Nov 1997, Jason Costomiris wrote: On Mon, Nov 10, 1997 at 09:16:01AM +1100, Craig Sanders wrote: : qmail might be excellent at what it does but it's incompatible with : /var/spool/mail. Yeah, and? It allows you to streamline your quota setup. It also allows you to have a smaller /var. so? why is having a smaller /var so important? if you're storing enough mail that it becomes an issue then /var/spool/mail should be a separate partition or disk. what does the qmail way allow you to do with quotas which you can't do with the standard /var/spool/mail? i can think of one thing which the standard way allows which the qmail way doesn't: having separate quotas for /home and /var/spool/mail : the one time i installed it, i couldn't even get it to use procmail : as the local delivery agent instead of qmail-local Why do you need to do this? If your users need to sort their mail, it's quite easy to use procmail in conjunction with a stock qmail setup. You just need to read the FAQ. The FAQ told me how to use it from a ~/.qmail file. i didn't want to know how to do that (it's damned obvious), I wanted procmail as the MDA. there are several reasons why i need to do this: 1. i don't have to have a |procmail ... .forward or .qmail file in every user's home dir. i see procmail as an INTEGRAL part of my systems' mail capabilities, not as a tacked on piece of cruft. 2. procmail is part of my 4 tier spam filtering system. - ipfwadm blocks connections from known spam-only networks like cyberpromo and the nancynet scum. - sendmail check_* blocks incoming spam from known spam domains and spam users, and also prevents spammers from hijacking my systems - procmail as local delivery agent catches a large percentage of the spam which makes it through tiers 1 2 with a handful of simple rules in the system-wide /etc/procmailrc file all spam caught at this stage is saved in /root/mail/probable-junkmail, and i read through it every so often. so far, it hasn't caught anything which it shouldn't catch...if it ever does, i'll just bounce it to the intended recipient. This probably-junkmail folder is also used as food for the check_* rules. When I have time, i go through it and extract all the addresses and add them to either /etc/mail/Spammers or /etc/mail/SpamDomains. - anything which makes it through that can be caught by personal ~/.procmailrc files yes, i could do all this another way. i don't want to. i've spent a lot of time developing my anti-spam system and it works well. it takes me only a few minutes to implement on every new system i build. I have a cron job which uses make and ssh and scp to transfer the various anti-spam rules files (e.g. /etc/mail/Spammers, /etc/mail/SpamDomains, /etc/mail/SpamNets, /etc/procmailrc) to the systems which i am responsible for. Any new rules on my anti-spam master system (my workstation siva) gets propagated to all of my systems and to several of my client's systems. i suppose i should write up how i do all this as a howto one-of-these-daystm - it's fairly simple to do and makes use of commonly available tools. : there's also the 'minor' problem that only a few MUAs (i don't know of : one except for qmail-popper) will work with qmail's new maildir format. Uh, there's maildir2mbox, which you can use for that task. In addition, qmail comes with wrappers for pine and elm. great. so i have to quit pine every so often and restart it so that the wrapper script can move my mail to where it should have been in the first place. : it's anti spam features don't seem as good as Claus Assman's check_* : rules for sendmail 8.8.x (which have been included with the latest : debian sendmail packages in unstable). they certainly don't seem : anywhere near as flexible. Uh, I've done a good deal of work constructing a set of check_* rules that I use to restrict relaying and drop spam. qmail was a snap by comparison. what's so difficult about adding the following lines to /etc/mail/sendmail.mc? # to block incoming junk HACK(use_spammers)dnl HACK(use_spamdoms)dnl HACK(check_mail)dnl # to prevent relaying HACK(use_ip)dnl HACK(use_relayto)dnl HACK(check_rcpt4)dnl : but the biggest problem with qmail is the author's attitude. it would : be fine if he said here's the way i like things to run, so that's the : default...but if you prefer the old standard ways then make this change : and that change and everything will run sweetly. but he doesn't do : that, he says the old ways suck so you can't have them. you have to do : it my way even if my way sucks for your particular setup. tough luck. Yes, Dan Bernstein is called the Psycho Programmer from Hell by many. However, qmail rigidly implements the RFCs governing SMTP mail, which is a Good Thing, IMHO. yes, sendmail could be improved.
Re: MTA Suggestion
On Mon, Nov 10, 1997 at 08:40:35PM +1100, Craig Sanders wrote: : Yeah, and? It allows you to streamline your quota setup. It also allows : you to have a smaller /var. : : what does the qmail way allow you to do with quotas which you can't : do with the standard /var/spool/mail? i can think of one thing which : the standard way allows which the qmail way doesn't: having separate : quotas for /home and /var/spool/mail Why should I have to manage quotas for three filesystems instead of two? I already quota /home and /tmp, why on earth would I want to have to manage it for /var too? : Why do you need to do this? If your users need to sort their mail, : it's quite easy to use procmail in conjunction with a stock qmail : setup. You just need to read the FAQ. : : The FAQ told me how to use it from a ~/.qmail file. i didn't want to : know how to do that (it's damned obvious), I wanted procmail as the MDA. I agree with you, for machines with sendmail as the MTA. Procmail has less overhead than deliver or mail.local. However, it adds overhead on qmail systems, and isn't really used except for guys like us who read a bunch of mailing lists using shell accounts, instead of pop3 mailers that have their own filters. For the 5 - 10% of users that actually use procmail, I think making that ~/.qmail file that says: | preline procmail isn't all that difficult. : there are several reasons why i need to do this: : : 1. i don't have to have a |procmail ... .forward or .qmail file in :every user's home dir. Does every user on your box use its features, or does it just deposit mail in /var/spool/mail/$USER ? :i see procmail as an INTEGRAL part of my systems' mail capabilities, :not as a tacked on piece of cruft. Again, for YOU. Not for all of your users. As a system admin, you should be willing to have to take 30 seconds to setup your own environment, and have a nice, stable, secure, fast environment for the rest of your userbase. : 2. procmail is part of my 4 tier spam filtering system. Why??? It's too late then. By that time, you've already accepted the mail. If you want a more serious spam solution, contact Paul Vixie. He'll offer you BGP peering sessions that blackhole routes for spammers. : - sendmail check_* blocks incoming spam from known spam domains : and spam users, and also prevents spammers from hijacking my : systems You mean the way control/badmailfrom and tcpcontrol do? : - procmail as local delivery agent catches a large percentage of the : spam which makes it through tiers 1 2 with a handful of simple : rules in the system-wide /etc/procmailrc file Too late again. You've already lost the battle by accepting the mail. Now you're on the run trying to get rid of it so you don't have to read it instead of concentrating on not accepting it to start with. : all spam caught at this stage is saved in : /root/mail/probable-junkmail, and i read through it every so : often. so far, it hasn't caught anything which it shouldn't : catch...if it ever does, i'll just bounce it to the intended : recipient. Yep, nothing like making extra work for yourself. Love it. : great. so i have to quit pine every so often and restart it so that the : wrapper script can move my mail to where it should have been in the : first place. q, y, pinq. Wow. That's hard. Actually, I believe that pine 3.96 and higher support maildir. At least it does on a box I have an account on that runs OpenBSD and qmail. Mutt supports maildir too. Mutt is *much* better than pine, IMHO (this from someone who used pine for about 4.5 years). : Uh, I've done a good deal of work constructing a set of check_* rules : that I use to restrict relaying and drop spam. qmail was a snap by : comparison. : : what's so difficult about adding the following lines to : /etc/mail/sendmail.mc? : : # to block incoming junk : HACK(use_spammers)dnl : HACK(use_spamdoms)dnl : HACK(check_mail)dnl : : # to prevent relaying : HACK(use_ip)dnl : HACK(use_relayto)dnl : HACK(check_rcpt4)dnl They're not ready for prime time yet. Notice it's not FEATURE(), and it is HACK()? : qmail might have some good features, and it might conform to the RFCs : a bit more closely than sendmail does, but i still don't see any : compelling reason to use qmail rather than sendmail. Maybe if i needed : to run huge mailing lists i might consider a dedicated server running : qmail. The main reason is the default behavior for qmail is much more secure than sendmail. To make sendmail more secure, I need to change the DefaultUser entry, I need to rip out Mprog, and I need to add all kinds of custom rulesets. : As opposed to the machine becoming overwhelmed from delivering to : a /var partition that's mounted accross several machines, as you : suggested with home dirs? : : the point was that his NFS argument against /var/spool/mail was :
Re: MTA Suggestion
On 10 Nov, Craig Sanders let loose with: On Sun, 9 Nov 1997, Tim Ferrell wrote: there's also the 'minor' problem that only a few MUAs (i don't know of one except for qmail-popper) will work with qmail's new maildir format. Actually this is not entirely true... You can set up qmail to use mbox files - but as you point out, the author strongly discourages this. NFS issues aside, I do not care much for maildir. yes, the debian qmail package in experimental/ even uses them by default. only problem is that a user's main mailbox file is in the WRONG place, in ~/Mailbox rather than /var/spool/mail/username where it belongs. I still don't know of any MUAs which will read mail from either maildir or ~/Mailbox. admittedly, configuring pine or elm to read ~/Mailbox rather than the usual spool dir is pretty simplebut that requires every user on the system to reconfigure their mail client. For the record, xfmail uses maildir format which I found terribly kludgy... it too could import and export, but I found having a file per message overkill. I have mail set up on this system to be forwarded to procmail which sorts and delivers to several mbox files in ~/mail. I sort my mail into logically-named files by content and use tkrat as my MUA. I keep all my mail (except the real junk) so a simple script can save current mail to my archive. I have been *very* pleased with this arrangement... I prefer to use software written by authors who are responsive to user's needs. I am a consultant so I know the necessity of this... I am developing an app for a company currently that is to integrate several steps in their design process and have the difficulty of trying to integrate an app by a company whose support is pitiful... and , of course, they are less than helpful when they do respond. sigh finally, qmail is non-free. debian CAN'T use it as the default MTA. Why is it non-free? because you can't distribute modified source, modified binaries, or even pre-compiled binaries without special approval from the author. price is probably the least important factor in what makes a program free - the freedom is in freedom to modify and distribute, not in zero cost. Anyhow, I will stick with sendmail, despite its complexity - it is a known quantity and does what *I* like... ;-) me too. i look at other MTAs from time to time, just to keep up with alternative ways of doing things, but i haven't yet found a compelling reason to switch away from sendmail. vmail sounds like it will be good when it's released, but that was still in the design stage last time i looked at the vmail web pages (a few months ago...i'll dig up the url if you're interested). personally, i think that sendmail is actually simpler to configure than smail or eximor more precisely, debian's sendmailconfig script can configure a system which will meet the needs of wild guess 99% /wild guess users. run sendmailconfig, answer a few questions, and you end up with a sendmail.cf file which works. if you need something more complex, you can either edit /etc/mail/sendmail.mc or /etc/sendmail.cf directly. yeah, this is true... when I switched from Red Hat to Debian not to long ago I was quite pleased with this script. In RH you are faced with the task of setting sendmail up yourself if your needs vary from the default install (and whose don't!) but I was able to get most of the way there with that script. Very nice... sendmail also happens to be the best documented MTA around - there's at least 2 or 3 good books devoted to sendmail. this was one of the reason i finally gave up on smail - i couldn't find any books on smail anywhere (the bat book isn't what i'd consider light reading but at least it exists). Documentation, especially *printed* documentation is a critical issue as well. Sendmail documentation, though vast, seems clearer to me than others. I spent a good week or so pouring over qmail's documentation with very little success... -- craig sanders networking consultant Available for casual or contract temporary autonomous zone system administration tasks. -- Debian GNU Linux Power to the people... E-Mail: Tim Ferrell [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: MTA Suggestion
On Mon, 10 Nov 1997, Craig Sanders wrote: : I still don't know of any MUAs which will read mail from either maildir : or ~/Mailbox. admittedly, configuring pine or elm to read ~/Mailbox : rather than the usual spool dir is pretty simplebut that requires : every user on the system to reconfigure their mail client. Nope. Use /etc/pine.conf.fixed, to have ALL people's pine looking into the same place ($HOME/Mailbox). Remco -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: MTA Suggestion
Alex Y. writes: Not that simple. Exim doesn't work with fetchmail somehow. *IF* we fix fetchmail or exim to work with each other, *then* we may think of changing default MTA. Just my opinion. I asked Eric about this: here is his response. It's not true. I have several exim users on my beta list, and the FAQ file describes how to make fetchmail work with exim in detail (it's not hard). -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: MTA Suggestion
George Bonser wrote: I would like to request that exim replace smail as the default MTA for Debian. Good idea! Exim is easy as they come. Hi. Not that simple. Exim doesn't work with fetchmail somehow. *IF* we fix fetchmail or exim to work with each other, *then* we may think of changing default MTA. Just my opinion. Not working? In what way? It works fine here, exept when I screw around with the setups. --j Alex Y. -- _ _( )_ ( (o___ +---+ | _ 7 |Alexander Yukhimets| \()| http://pages.nyu.edu/~aqy6633/ | / \ \ +---+ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] . -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: MTA Suggestion
George Bonser wrote: I would like to request that exim replace smail as the default MTA for Debian. Good idea! Exim is easy as they come. Hi. Not that simple. Exim doesn't work with fetchmail somehow. *IF* we fix fetchmail or exim to work with each other, *then* we may think of changing default MTA. Just my opinion. Not working? In what way? It works fine here, exept when I screw around with the setups. Hi. Yes, indeed. Following the insructions in the fetchmail FAQ didn't make my fetchmail work (neither rewrite option, nor changing exim configuration file). But since I do agree that exim is seemingly faster than sendmail and after hearing several success stries I poked around and find out that mda option in .fetchmailrc should also be chanded. But what is the command? fetchmail man page does not give example for exim. Well, as usual, Dejanews knew the answer :) Anyway, it *works*. But my point still holds: while smail is mostly drop-in replacement for sendmail, exim is *not*. Who knows which other programs count on the standard behavior of sendmail and need to be reconfigured (in the best case) or recompiled to work. Yes, exim is much nicer, but it is available as a debian pakage already. Everyone interested can install it. Thanks. Alex Y. -- _ _( )_ ( (o___ +---+ | _ 7 |Alexander Yukhimets| \()| http://pages.nyu.edu/~aqy6633/ | / \ \ +---+ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: MTA Suggestion
On Sat, 8 Nov 1997, Jason Costomiris wrote: I nominate qmail + tcpserver/tcpcontrol. I'm in the process of converting all of my boxes to it. Very nice, easy to control relaying/spam, and FAST. no way! qmail might be excellent at what it does but it's incompatible with /var/spool/mail. the one time i installed it, i couldn't even get it to use procmail as the local delivery agent instead of qmail-local (putting a .qmail file in every home directory is NOT a viable option, i want procmail as THE local delivery agent). i didn't spend much time on it though - reading the docs and faqs etc just made me angry at the author's arrogant attitude. there's also the 'minor' problem that only a few MUAs (i don't know of one except for qmail-popper) will work with qmail's new maildir format. it's anti spam features don't seem as good as Claus Assman's check_* rules for sendmail 8.8.x (which have been included with the latest debian sendmail packages in unstable). they certainly don't seem anywhere near as flexible. but the biggest problem with qmail is the author's attitude. it would be fine if he said here's the way i like things to run, so that's the default...but if you prefer the old standard ways then make this change and that change and everything will run sweetly. but he doesn't do that, he says the old ways suck so you can't have them. you have to do it my way even if my way sucks for your particular setup. tough luck. that doesn't cut it with me. software installed on MY system has to conform to MY way of doing things or provide good reasons for me to learn a new and better way. *None* of the stated reasons for the superiority of the qmail way were good enough for me to be willing to make such a drastic change to the way mail works on my systems. he goes on about nfs locking problems with NFS, ignoring the fact that most NFS locking problems are related to sloppy programming. debian has managed to produce an NFS safe locking library, so it's obviously not impossible. and any site running an automounter daemon for user home directories would be overloaded by qmail insisting on delivering mail to ~ (and would still suffer from the NFS locking problem he is so worried about) in summary, i think that his reasons for doing things the way he does are, for the most part, ill-informed opinion and bigotry. there is some substance to what he says but it's nowhere near as black and white as the way he says it. finally, qmail is non-free. debian CAN'T use it as the default MTA. craig -- craig sanders networking consultant Available for casual or contract temporary autonomous zone system administration tasks. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: MTA Suggestion
On 09-Nov-97 Craig Sanders wrote: but the biggest problem with qmail is the author's attitude. it would be fine if he said here's the way i like things to run, so that's the default...but if you prefer the old standard ways then make this change and that change and everything will run sweetly. but he doesn't do that, he says the old ways suck so you can't have them. you have to do it my way even if my way sucks for your particular setup. tough luck. I agree with this. qmail seems to be oriented toward efficient transmission of mail out to the internet, fine, but that is only HALF of the picture. In today's environment you need to do more. My users hate spam. Dealing with spam complaints is the majority of mail system administration for me. Exim has some very interesting methods of sender rejection, system-wide message filtering and finally user-specific message filtering built into it. Exim provides the user with a more comfortable email environment with minimum administrative headache for me. Philip Hazel, author of Exim, has promised a release of Exim that works with Paul Vixie's MDL before Christmas and stated that this is already in use in testing. This, combined with the already extensive array of relay policy and sender rejection criteria possible plus the filtering make Exim my choice for a total mail administration solution. All I need to do now is make a web-based front-end for users to create their own filters, auto-responders, and forwarding and I am free from a large amount of mail admin. Qmail might be my choice for a stand-alone mailing list server but that would be about it. It is very efficient at bulk sending of email but that is only a small part of the total email picture. Some of us have to deal with users. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: MTA Suggestion
On 10 Nov, Craig Sanders let loose with: On Sat, 8 Nov 1997, Jason Costomiris wrote: I nominate qmail + tcpserver/tcpcontrol. I'm in the process of converting all of my boxes to it. Very nice, easy to control relaying/spam, and FAST. no way! qmail might be excellent at what it does but it's incompatible with /var/spool/mail. the one time i installed it, i couldn't even get it to use procmail as the local delivery agent instead of qmail-local (putting a .qmail file in every home directory is NOT a viable option, i want procmail as THE local delivery agent). i didn't spend much time on it though - reading the docs and faqs etc just made me angry at the author's arrogant attitude. there's also the 'minor' problem that only a few MUAs (i don't know of one except for qmail-popper) will work with qmail's new maildir format. Actually this is not entirely true... You can set up qmail to use mbox files - but as you point out, the author strongly discourages this. NFS issues aside, I do not care much for maildir. but the biggest problem with qmail is the author's attitude. The sad thing is that it is often difficult for most people to separate genuine issues from personal crusades... finally, qmail is non-free. debian CAN'T use it as the default MTA. Why is it non-free? Anyhow, I will stick with sendmail, despite its complexity - it is a known quantity and does what *I* like... ;-) - Tim -- Debian GNU Linux Power to the people... E-Mail: Tim Ferrell [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
MTA Suggestion
I would like to request that exim replace smail as the default MTA for Debian. --- George Bonser Debian/GNU Linux See http://www.debian.org Linux ... It isn't just for breakfast anymore! -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: MTA Suggestion
George Bonser wrote: I would like to request that exim replace smail as the default MTA for Debian. Good idea! Exim is easy as they come. Later, David -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: MTA Suggestion
George Bonser wrote: I would like to request that exim replace smail as the default MTA for Debian. Good idea! Exim is easy as they come. Hi. Not that simple. Exim doesn't work with fetchmail somehow. *IF* we fix fetchmail or exim to work with each other, *then* we may think of changing default MTA. Just my opinion. Alex Y. -- _ _( )_ ( (o___ +---+ | _ 7 |Alexander Yukhimets| \()| http://pages.nyu.edu/~aqy6633/ | / \ \ +---+ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: MTA Suggestion
On Sat, Nov 08, 1997 at 12:30:22AM -0800, George Bonser wrote: : I would like to request that exim replace smail as the default MTA for Debian. It doesn't make good sense to do this. exim runs out of inetd. For mailers, this is bad, unless you're a very low volume site. I nominate qmail + tcpserver/tcpcontrol. I'm in the process of converting all of my boxes to it. Very nice, easy to control relaying/spam, and FAST. -- Jason Costomiris | VMS is about as secure as a poodle [EMAIL PROTECTED] | encased in a block of lucite http://www.jasons.org/~jcostom/ | about as useful, too. #include disclaimer.h | --some guy I read on Usenet -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: MTA Suggestion
Jason Costomiris wrote: exim runs out of inetd. This information is wrong. Exim can run out of inetd, but it most definitely runs as a standalone daemon too. We use exim as a daemon here just fine. We have an entire site using exim here, and it's very easy to use, fast, configurable, solid, and DFSG free. It also has support for all the latest relaying/spam controls. IMO, it's main developper is also both civil and approachable, and gladly gives advice and accepts patches. The only problem with exim is that it doesn't really support UUCP mail spools. You can get it to handle simple ones, but nothing very complex. This isn't really a problem if you don't serve any UUCP domains however. The biggest problem with qmail, as far as I can tell, is that it isn't DFSG free, and as a result cannot be Debian's prefered MTA. As far as I can tell, the only real candidates for the Debian prefered MTA (because they are DFSG free) are: sendmail, smail, and exim. This may not be an exhaustive list however. I've used all 3 and personally, as you can probably tell, I prefer exim. Later, Behan -- Behan Webster mailto:[EMAIL PROTECTED] +1-613-224-7547 http://www.verisim.com/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: MTA Suggestion
-BEGIN PGP SIGNED MESSAGE- On Sat, 8 Nov 1997, Jason Costomiris wrote: exim runs out of inetd. For mailers, this is bad, unless you're a very low volume site. Exim is very easy to configure to run standalone if you want. In fact if you look in the /etc/init.d there is a file called exim that you only have to change one line to make it run standalone. -BEGIN PGP SIGNATURE- Version: 2.6.3a Charset: noconv iQCVAwUBNGS0Lr9jATYvfm1dAQHuywP9FM9c1OZ1A9g24+o5tffsRirDjmyc+g0W kC6dIrCve3XcnOkS0QXUIa8QVCmHaOF5a1Ir5ycKfBQNIusc0KjK7LQKAaeooXUF Vn9JuqK5BDghvKEx/fXUYXfUHHUTcrJTYxUtgRIM2UGPlEVtXvvvSowOxDWq3aVu z5u7msVeRi4= =KwJT -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: MTA Suggestion
On 08-Nov-97 Jason Costomiris wrote: On Sat, Nov 08, 1997 at 12:30:22AM -0800, George Bonser wrote: It doesn't make good sense to do this. exim runs out of inetd. For mailers, this is bad, unless you're a very low volume site. I only run exim out of inetd on one system, all the others run as a daemon (invoked as /usr/lib/sendmail -bd -q15m) I nominate qmail + tcpserver/tcpcontrol. I'm in the process of converting all of my boxes to it. Very nice, easy to control relaying/spam, and FAST. Exim is as fast or faster and BETTER at controlling relaying of spam. It even has user-level filters in addition to system-wide filtering. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
