Re: Status of inetd for etch
Andreas Metzler <ametzler@downhill.at.eu.org> writes:
> This seems to be totally overengineered.
<troll>
What, moreso than the exim4 configuration? :D
</troll>
(Ok, I've grown used to it, even like it. But at first, it seemed
overengineered)
> Having MTA a provide sendmail which uses MTA b for remote deliveries
> is no common usage scenario on which any effort should be spent in
> the Debian packaging infrastructure.
Several antispam programs and daemons, available in Debian, use this
technique explicitly to filter spam. They are just not seen as an
MTA. Today, you often need to add a lot of configuration by hand to
send mail off to tcp/10024 and accept from it at tcp/10025.
> Actually the only sane explanation for wanting to install two MTAs I
> ever heard of was "I am running X now and want to switch to Y. - I'd
> like to test Y in the real system before going live."
If you have only one box, and don't want to run vservers on it, it's
one reason to have several MTAs installed.
Your needs also depends on the number of servers (and sites) you have.
Here are two scenarios off the top of my head.
Service provider
================
Mail is used extensively for reporting and perhaps even as an
application data transport when running a large number of servers.
Using one homogenous mail setup for all servers makes sense, perhaps
less so if you just have a few servers, but when you have a couple of
hundred, you have a _great_ need to keep things similar and
predictable across all servers.
You might need or want annoyance filters for the service provider
mail, but you don't want anything to interfere with the system mail
service.
If one also provides mail service to a large number of customers and
domains, you have another, different, type of mail server. If you
have a homogenous system mail service, you could treat the provider
mail service as just another application runing on this set of
servers, listening on tcp/25 and friends.
Special applications
====================
One may like running a mailing list manager like ezmlm, but don't want
to expose qmail to the big, bad internet. (accept-then-bounce is not
a good thing combined with brute force spam attempts).
Then again, qmail might be too politically incorrect to care about,
and there might not be enough mail service providers using Debian in
order for this to be worthwile.
--
Stig Sandbeck Mathisen
Reply to: