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).
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
