> Yes, if you want to do something that no one else has needed > to do in sendmail's 3-decade history, you'll probably have > to read the bat book first. But that seems unlikely to me > and with MimeDefang in the picture you can control many operations > in your perl filter instead of modifying sendmail macros. hmm...i wonder why there are sendmail + mysql patches floating around then. Being able to something natively is obviously desired over passing it out to perl. > >> I guess that is the whole point. Ordinary users will probably have no >> clue how sendmail works and when problems arise, good luck trying to fix >> or get around them. So unless they know how to build other stuff and use >> procmail or maildrop, they are pretty much stuck to system mailboxes. > > As shipped in Centos, procmail is used for local delivery. Ah, i forgot the part about procmail don't support virtual mailboxes and therefore wasn't really what I want to put in there. postfix, qmail and maybe exim all do that out of the box without having to resort to using maildrop. > >>> Then when you add MimeDefang, you also get the ability to >>> add in any other operations you want to happen in parallel >>> with the smtp chat and control it all with a bit of perl. >> Which makes it no different from your dissing of qmail. qmail provides >> very little that you can do before DATA in the smtp chat and mimedefang >> does not kick in until after SMTP DATA in sendmail and they are >> therefore the same. > > I think you've been misinformed. My MimeDefang checks the inbound > recipients via smtp to the final delivery server before DATA is > ever mentioned. If there are no valid recipients (which the > outside relay wouldn't know directly) the message is rejected > before DATA. right, sorry, i have not actually used milter myself so I was not aware that it was not limited to content filtering. In any case, this shows one shortcoming of sendmail. sendmail processes each the helo, sender, recipient and client ip/rdns in separate rulesets and you cannot create (at least I have not managed it yet) any rulesets that can make decisions based on two or more of these and so you need to run a perl program via milter to deal with these or perhaps in your case, you need it to lookup a mysql table for the recipient. You call this efficient? > >>>> As for mimedefang, qmail lets you do anything that can be described in >>>> perl, shell, C, python, whatever you fancy in fact and reject at the >>>> smtp level too since you can replace qmail-queue or put a filter before >>>> qmail-queue. >>> Another way of saying that is that qmail is so bad you have to >>> completely replace components to make it usable at all. >> Which is no different from sendmail + mimedefang. You have no idea how >> qmail works so I shall ignore your ignorance on this. > > I've experienced the pain of using qmail. I know more than I want > to know about how it accepts everything, then generates millions > of bounces for the things it can't deliver then lets the bounce > delivery attempts throttle your real deliverable outbound mail. Right, so because qmail does not do recipient checking at the smtp level you write it off although there are options in qmail that you can take to get the same effect and which, in fact, is what you are also doing with sendmail + mimedefang from what you posted. It appears to me you are being unfair in your treatment then of qmail nevermind the rest. > >> sendmail gave you >> milter so that you can get at the headers and message body. DJB's >> multiple program approach to separate the different functions > > But he separates the functions so you can't do the thing you > need at the time you need to do it... Yes, you are right that unless you get into the qmail-smtpd code, you cannot do any before SMTP DATA checking which is what qmail-ldap and qmail-sql have done and what various patches have done too...hence why I say qmail alone is not suitable as an mx mta in today's Internet. > >> automatically provides you the ability to get at what you want by either >> modifying that particular qmail program > > Wait - you think modifying a program is easier than configuring > one that works in the first place? Normally no. qmail is an exception because it is the code is so simple it is plain to see where you can add extra checking stuff. Of course, that is the case if writing your own mysql lookup code and what not is possible for you :D. Otherwise, yes, qmail is not suitable as an mx mta. > >> or by replacing like qpsmtpd or >> by adding another program like qmail-qfilter. For this same reason, >> people don't get any trouble from postfix and qmail with regard to >> security issues and sendmail X following the same design principles says >> a lot. > > The milter interface is a more extreme solution, since it gives > you separation of permissions for the parts on the other end > of the socket but you get its response when you need it. sendmail runs as root in its entirety (others like qmail and postfix only have one or two running as root and the rest run with other uids) so the separation of permissions is necessary for sendmail. I don't see anything extreme about this....this is standard elsewhere. > >> Well integrated and designed for efficiency eh? I'd like to see >> benchmarks between sendmail + mimedefang versus postfix + amavisd. In >> fact, I'd like to see sendmail + mimedefang integrated with a mysql >> backend versus postfix + amavisd integrated with a mysql backend. But >> the whole thing would be unfair since postfix does connection pooling to >> its backends while sendmail will probably beat the crap out of its >> backend if it supported any sql database at all. > > If you run spamassassin, all of the other operations are pretty > much meaningless time-wise. The piece you need to keep things > going is a multiplexer that allows some maximum number of > backend scanners and some larger number of other MTA operations > to run concurrently. That is, you don't want to serialize > everything around a few scanners, and you also don't want to > be allowed to spawn off enough instances of them to kill > the machine. I don't think any of the other systems understand > this concept - but I'd be happy to hear that I'm wrong about > that. Okay, since you are talking about mimedefang being in action before SMTP DATA mode, qmail is already out unless you patch it. I have not used exim so I cannot say anything for it. postfix, however, can already do a fair amount of checks on the helo, recipient, sender, client ip/rdns separately and/or in combination out of the box. You can apply lookup checks against sql databases, flat file databases, regex, pcre (a perl regex C library) and for the helo and client ip/rdns you now get some interesting dns checks available too. If rejecting, you can also give custom responses too. I don't know what checks you are doing with mimedefang but I think the chances are high they can be done within the postfix provided framework without ever hitting an external filter. postfix will handle far more traffic that sendmail + mimedefang could have hope to in regard to before SMTP DATA checks unless of course you do something in mimedefang that cannot be done with the postfix framework. What do you do in mimedefang anyway? > >> You can diss all other mtas + their addons all you like Les, but >> sendmail X is following the design principles of qmail and postfix which >> says something. > > The only one I'll really diss is qmail, and I'll concede that > qpsmtpd will solve a few of it's problems as the project slowly > re-invents the things that MimeDefang has been doing for years. > My point is just that sendmail does a good job and has some > unique advantages when used with MimeDefang. > I will concede that sendmail does a good job for what it is designed to do (read no virtual mailboxes and only supporting system account mbox format mailboxes) which is suitable for small sites but I highly doubt that it has any unique advantages in combination with mimedefang versus postfix or exim out of the box or against qmail + patches + external (qpsmtpd don't cut it).