On Thu, 2006-08-24 at 22:49, Feizhou wrote:
> > As
> > shipped in Centos you can do pretty much anything you would
> > want a mailer to do by changing a few lines in sendmail.mc.
>
> Actually, what I want to get at is if you need anything beyond the
> rulesets that are provided, you cannot do anything unless you understand
> sendmail rulesets and that is the same if you need to change something
> too.
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.
> 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.
> > 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.
> >> 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.
> 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...
> 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?
> 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.
> 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.
> 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.
--
Les Mikesell
lesmikesell@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
