Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
On Sunday 10 October 2004 14:58, Jeroen van Wolffelaar wrote:
> On Sun, Oct 10, 2004 at 01:21:44PM +0200, Christian Surchi wrote:
> > Il sab, 2004-10-09 alle 17:48, martin f krafft ha scritto:
> > > > I think it's not a right comparison, nullmail is an MTA. and
> > > > AFAIK, msmtp is not an MTA:
> > >
> > > it transports mail to the next relay, right?
> > > nullmailer is a "simple relay-only mail transport agent."
> > >
> > > what's the difference?
> >
> > Deep difference. Our mail-transport-agents are able to behave as daemon,
> > listening on 25 port.
>
> This is not true, since not required by policy. Policy says:
The policy does not define what a MTA is, but requires that all MTA packages
have newalises command although it might do nothing.
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.
> 11.6. Mail transport, delivery and user agents
>
> | (...) the interface to send a mail message is `/usr/sbin/sendmail' (as
> | per the FHS).
Right, and that is mandated when you have a MTA with features like described
above. This does not mean that telnet is a MTA when invoked like:
/usr/bin/telnet mail.host.dom 25
ehlo blabla
mail from: _sender_
rcpt to: _recipient_
data
write some bits mail-a
.
quit
Note that telnet does know nothing about smtp protocol.
So you do not want postfix to conflict with telnet package, and
having /usr/sbin/sendmail, /usr/bin/telnet and /usr/bin/msmtp is policy
compliant.
> /usr/sbin/sendmail is guaranteed to work if you have
> mail-transport-agent, but port 25 to localhost isn't.
>
> So, any package providing /usr/sbin/sendmail, and, when correctly
> configured, gets mail on that interface off to the recipient, _is_ a
> mail-transport-agent, MTA. ssmtp is one, nullmailer is also one.
>
> 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 ;-) Policy does not mention anything about remote
machine depends/conflicts/whatever found in the control file of the package.
> > msmtp doesn't, and it's the same for nail. Do you think that nail
> > could be an MTA? Do you think that any evolution of mail(1) could be
> > seen as an MTA, only because is able to "speak" smtp?
> >
> > :o
>
> mail currently is a MUA, it will communicate with sendmail, i.e.,
> require a MTA to get its mail off.
>
> > > > I think that msmtp simply will take the place of sendmail binary
> > > > called by mutt.
>
> Then msmtp is just like any MTA, but accepts mail on a different binary
> (the msmtp binary in stead of sendmail), so it won't be used by any
> program unless specificially configured. IMHO, it'd be better if mstmp
> were packaged as a real MTA, providing /usr/sbin/sendmail, so that ALL
> programs (and not only mutt) can take advantage of it, and don't need
> special configuration. Then msmtp is an alternative to ssmtp and
> nullmailer, with a different featureset.
I think ssmtp is incorretly described as a MTA, that why its description
provides bits like:
WARNING: the above is all it does; it does not receive mail, expand aliases
or manage a queue. That belongs on a mail hub with a system administrator.
Did not look at nullmailer yet...
--
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: