Re: Questions regarding lsb-invalid-mta
On 06/23/2013 03:03 PM, Aaron Sowry wrote:
Okay. So, Debian considers an MTA to consist of both a server and client
component. This seems like a sensible enough definition.
Sort of. Strictly speaking, a "mail transport agent" is an agent which
transports mail. So as long as mail coming into the system gets
transported, whether the MTA is a full-featured system like Sendmail or
something a lot simpler.
At least, that's the Debian perspective (and one which I agree with).
I'm not saying that these "not-full-featured" MTAs are as limp as
lsb-invalid-mta, either; ssmtp, for example, just takes mail submitted
via /usr/sbin/sendmail and forwards it to a relay that accepts mail on
port 25. I think that's a very valid MTA implementation, and
appropriate for a number of circumstances. I use it on most of my home
machines, with one server as the central relay running Postfix.
If we want to
provide /usr/sbin/sendmail without installing an entire MTA then, I
guess we have two options:
1) Install the entire MTA, but leave the server component unconfigured
(assuming this is even possible). Enabling the server component later
could be done using dpkg-reconfigure.
This is possible. The exim4-daemon-light package, for example, takes
heroic steps to do the right thing in as many situations as possible
without any end-user configuration, which is why it's the default.
2) Make a new package available which provides only /usr/sbin/sendmail,
but not "mail-transport-agent" (i.e. installs no server). In this case,
I guess all packages providing mail-transport-agent would need to
replace this package.
I think every package that provides /usr/sbin/sendmail on Debian also
provides "mail-transport-agent", even the aforementioned options like
ssmtp which are little more than relays to another host.
Some of the packages that look stripped down are actually just the MTA
component of bigger things; Citadel, for example, is a complete
groupware suite, including mail, calendaring, contacts, forums/bulletin
boards, etc.
Reply to: