On Wed, Jan 02, 2002 at 09:18:54AM -0500, Derek Broughton wrote:
> dman wrote:
> > On Mon, Dec 31, 2001 at 05:50:22PM -0500, Derek Broughton wrote:
> > | dman wrote:
> > | > Here's the problem. A MUA should not be dealing with SMTP -- an MTA
> > | > should. mutt (and, AFAIK, elm and pine) do not do SMTP at all.
> > | > Instead they pipe the message to the system's MTA and let it take
> > | > responsibility for delivering it.
> > | That hair needs an electron microscope to split. :-)
> > :-).
> > | I can't imagine any good reason why an MUA shouldn't deal with SMTP.
See below.
> > Do you consider exim to be a trivial program? Proper mail delivery is
> But we're not talking about exim, and what an MTA has to do. We're
[... talking about]
B
> SMTP. It just needs to pass the message in accordance with the rules of
> SMTP.
Which include accepting the message, queuing said message if a connection
can't be established etc. SMTP is a protocol. It's more than just the
commands and the standard port, it defines how you deal with the data you
get as well. MUAs that "implement SMTP" do not actually implement SMTP.
They implement the limited subset that involves the connection and the
command-response set talked over that connection. This, IMHO, is quite
quite different from what an MTA does, which *is* implement SMTP.
> > not simple on the internet because it is such a large network. It
> > also adds complexity to the MUA, reimplementing the same thing the MTA
> > already implements.
> Perhaps, but no matter what you'd like to be the state of the world, the
> majority of MUAs are running on Windows and MUST deliver via SMTP.
Erm, no. You're misusing "MUST", which when put like that I read in an
RFC way. An MTA SHOULD support SMTP/ESMTP. An MUA MAY support SMTP. I'm
not sure how many windows MUAs deal correctly with, for example,
>>> 421 Too busy, try again later
as an opening banner.
Just because they run under windows doesn't mean that they shouldn't do
things properly. I appreciate that currently they don't, but OTOH them
not doing things properly now is not a reason to suggest that this is
in fact the right way of doing things. It can be widespread and wrong.
> THough I'd argue that it could _decrease_ complexity.
I think you don't understand the full implications of the SMTP *protocol*,
as I say above, it's more than just a set of commands and the responses.
> > problems). For incoming SMTP connections, exim must verify the
> > legitimacy of the message however from a pipe, the message is
> > obviously legit since it originates from a user on the system.
> But the SMTP daemon always needs to verify the legitimacy of a
> connection anyway, there's no reason that it has to do any more work
Not if it's a pipe it doesn't.
> when the other end is an MUA than when it's another MTA (though I could
> buy an argument that it could be adding an intolerable amount of
> overhead to a busy system).
But a remote MTA may well do batching or suchlike of the messages, which
enables you to keep answers. For a pipe, you don't need to do any of
these checks. Plus, in general, if you're running a smarthost and
incoming MX on the same box, then you'll probably see more mail connections
going out than coming in.
> > I've seen (or heard
> > of) many MUAs that try to implement everything for themself (POP,
> > IMAP, SMTP, etc) and are often buggy.
> I've never tried using an MUA that 'implements' any of them. They just
> talk to programs that implement the protocol. I can't really see how
like, for example, MTAs, by using a /usr/lib/sendmail type interface.
> you would have an MUA that runs on Windows that couldn't talk either POP
> or IMAP, and as long as I'm going to have to use Windows for my clients
POP / IMAP are completely different to SMTP.
> (which will be the rest of my career...), I plan to use an MUA that
> talks IMAP and SMTP - and runs on both Windows and Linux (currently I'm
> using Mozilla).
Talking IMAP is a good thing for an MUA to do, there is no problem with
this. IMAP is designed for this. SMTP, OTOH is not.
> Consider your argument that letting the MUA talk SMTP, etc, increases
> complexity. I know of a number of Unix mailers that provide specific
> support for mbox and MH mail formats (not Maildir, more's the pity, in
> any GUI mailers I've tried). If instead, you use a POP or IMAP daemon,
> the mailer only needs to talk the one protocol, forget supporting
> multiple mailbox formats.
IMAP and SMTP are completely different, you're comparing kangaroos with
kookaburras. (They're related in that they're both found in Australasia,
but apart from that...). One is for reading mail interactively from a
remote system, and the other is for delivering mail with a transfer of
responsibility, and ability to report errors.
It is perfectly reasonable for an MUA to only support IMAP, or support
IMAP amongst a number of things, and indeed this is exactly the design
criterion of IMAP. This does not make it reasonable for an MUA to attempt
to implement SMTP.
POP is more of an interesting one, because most implementations require
you to have an MTA locally anyway, so that the POP client delivers to
the MTA, which delivers to the mailbox, as configured. You are also
missing, as someone else pointed out upthread, that you want an MTA for
messages from, eg. cron. Just using the MUA, however, is potentially a
valid POP implementation.
But in this discussion, and I'll say it again because I think it's so
important, implementing SMTP commands and responses is not the same as
implementing SMTP.
> (btw, it's a darn good thing mozilla talks SMTP - so that I can skip
> straight through to my smarthost - because I'm having a hard time
> getting exim to accept my outbound messages right now. I wish I could
> figure out what I've screwed up :-) ).
That is not a reason for doing things in the wrong way.
MBM
--
Matthew Byng-Maddick <mbm@???> http://colondot.net/
