On Mon, 2006-02-20 at 07:45, Peter J. Holzer wrote: > > I guess a better example would have been a user whose account > > needs to remain active for a while but should no longer > > receive mail. > > Funny, that's one of the cases which I couldn't figure out how to do > with sendmail. Putting to: lines into the access database for a few > hundred email addresses somehow didn't cross my mind (and I still think > it is ugly). All the other ays I tried either didn't work or had some > side-effects.
One database is as good as another as far as I'm concerned. I think the trick to configuring sendmail is to pretend that sendmail.cf is not meant to be modified directly and stay away from the volumes of documentation about doing that. The access db allows you to specify what you want to accept/relay/reject based on several criteria: http://www.sendmail.org/m4/anti_spam.html#access_db > In contrast, writing a complete plugin which did lookups for > mail-addresses, noted per-recipient options for perusal by other > plugins, and recursively expanded aliases was almost trivial - it > certainly took less time than I had previously spent reading sendmail > docs and experimenting with various sendmail options. (And - most > importantly - it was a lot more fun) Well, yes, there are people who will rewrite a complicated program in python rather than learning the one line of perl they needed to configure an existing program. There's no accounting for taste. > BTW, I knew about MIMEDefang since at least 2001. But I only thought of > it as a tool to manipulate the content of mails, and I didn't have any > need for that, so I never took a closer look. It also appears to have had a lot of work put into solving the performance problems of running a lot of big, slow, memory-sucking perl processes. Qpsmptd will have to deal with these too. > > Anyway the point was just that while you can do that kind > > of stuff in the mimedefang/milter code you also have the > > option to use the stock sendmail features if it is > > more convenient. > > Yes, but if you want that, you must run sendmail. I don't think anybody > will implement a sendmail.cf-interpreter for qpsmtpd. That depends on your reasons for not running sendmail itself. I don't have any problem with it and the price is right. But again, there is no accounting for taste, Qmail has caused me enough pain in the past that I'd never run it by choice again although qpsmtpd solves one of it's problems. > Getting MIMEDefang with qpsmtpd may be worthwhile (although it seems to > duplicate a lot of the stuff qpsmtpd does already), but if you want > sendmail, you know where to find it. > > (I find arguments of the sort "developers of free software A are wasting > their time - they should instead help improving software B" extremely > pointless. AFAIK nobody ever criticised a company for competing with > another company) Yes, it's probably as pointless as complaining about the fragmentation of unix into sysv, bsd, solaris, aix, hpux with their arbitrary differences back in the day, but with free software it at least makes sense to be aware of the prior art and use as much as you can from it. But, I'm not saying that the project shouldn't exist, just that sendmail has a lot of functionality to duplicate, and that if your reason for not using sendmail was that it did not let you control it in perl, that's not true any more. -- Les Mikesell [EMAIL PROTECTED]
