Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
On Monday 11 October 2004 19:18, Henning Makholm wrote:
> Scripsit George Danchev <danchev@spnet.net>
>
> > IMHO a MTA must be capable acts as a client and as a server to transfer
> > messages between machines and is responsible for properly routing
> > messages to their destination, e.g. RFC 974. msmtp does not do all
> > of these, therefor it is not a MTA, and might have nothing to do
> > with /usr/sbin/sendmail.
>
> You are wrong. See nullmailer.
>
> The definition of mail-transport-agent is that it provides a
> /usr/sbin/sendmail that local software can use to submit emails for
> delivery to arbitrary addresses with some reasonable expectation that
> it will actually be delivered.
MTA is a software talking at least one Mail Transfer Protocol (like SMTP,
UUCP, X.400 ...) These Mail Transfer Agents are responsible for properly
routing messages to their destination. See RFC 974 for routing messages.
Obviously MTA provides /usr/sbin/sendmail, as required by the policy.
> It is *not* required that the package that provides
> mail-transport-agent must itself do any particular part of the
> delivery process, as long as its /usr/sbin/sendmail will *somehow*
> arrange for delivery.
Are you talking about MDA here ;-). Delivery agents are used to place a
message into a user's mail-box. When the message arrives at its destination,
the final transfer agent will give the message to the appropriate delivery
agent, who will add the message to the user's mail-box.
OK, most MTA comes with MDA apps.
> It would be perfectly good to have a package airgap-mailer whose
> /usr/sbin/sendmail will just *print* hardcopies of its input on a
> configured printer, with instructions to the human operator to type
> the email into the machine at the Internet-connected side of the air
> gap. This package would provide mail-transport-agent because it
> implements the policy-defined API for shipping email for delivery.
Such a package must talk at least one Mail Trasfer Protocol to be called MTA.
Providing /usr/sbin/sendmail is required but not enough to call it MTA.
In the case of msmtp you can create a configuration file with your mail
account(s) and tell your MUA to call msmtp instead of /usr/sbin/sendmail.
msmtp has not the features of a MTA, and does not need
providing /usr/sbin/sendmail. ;-)
But you want it provides /usr/sbin/sendmail, to call it MTA, which is seriosly
broken logic Care to explain that to its authors ?
> > Note that telnet does know nothing about smtp protocol.
>
> Neither does airgap-mailer.
>
> > > Note that a MTA isn't required to know ANYTHING about smtp. Suppose a
> > > package provides an sendmail that is an alias for 'ssh mailhub
> > > /usr/sbin/sendmail', then that package is a MTA.
> >
> > Such a package will require a dependency of ssh (at least) on the remote
> > machine and you will be in a little trouble hacking your control file to
> > satisfy things like that ;-)
>
> That is up to the system administrator to arrange. If it provides a
Satifying package's Depends: is in the domain of packaging system handlers.
Ever seen a debian/control file & friends ? You have dependencies to resolv
on a remote machine...
> /usr/sbin/sendmail, then it is an MTA. It does not make it any less an
Providing /usr/sbin/sendmail is required, but not enough to call it MTA.
> MTA that it requires some manual configuration before its
> /usr/sbin/sendmail can do anything useful with its input. Most MTA's
> do, actually.
Satifying package's Depends: is in the domain of packaging system handlers.
Ever seen any debian/control ? You have dependencies to resolv on a remote
machine... do not talk me about configurations ...
> > I think ssmtp is incorretly described as a MTA
>
> That must be because you don't understand what an MTA is.
beats me ;-)
p.s. s/an MTA/a MTA
--
pub 4096R/0E4BD0AB 2003-03-18 <keyserver.bu.edu ; pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Reply to: