Andreas Metzler <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
