On Wed, Jan 02, 2002 at 09:34:01AM -0500, Derek Broughton wrote:
> Matthew Byng-Maddick wrote:
> > On Mon, Dec 31, 2001 at 05:50:22PM -0500, Derek Broughton 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. :-)
> > Not at all. There is a huge difference. Do you, for example, always have
> > an X/Window display available. The reasoning is very similar.
> I fail to follow. NO I don't always have a X Window display. YES I
Why do you use command-line tools? Is it because they tend to be less
complicated, and hence tend to work better? They are certainly a lot less
complicated to write, and there are fewer places to introduce bugs.
> always have an SMTP port available - if not on this machine always on my
> ISP.
if not on this machine and in the case of a network outage? doesn't sound
like that's "always" to me.
> >>I can't imagine any good reason why an MUA shouldn't deal with SMTP. In
> > How many MUAs do you know which are able to spool messages if the
> > receiver SMTP doesn't want to accept them just yet?
> In which case, every one of them asks you what to do with it and usually
> saves it in some 'drafts' folder. That's not ideal from one point of
Yuck!
> view, but certainly is from someone who wants to be able to use the same
> software on multiple machines which won't all support piping to an MTA.
Well, I guess, if you remember to send it when the network comes back up,
and of course, it won't send you a bounce if you do forget to send it.
> >>fact, as configured, SMTP on localhost is usually your MTA. It makes
> > No it's not.
I think I misunderstood what you meant. You mean that the daemon listening
on port 25 will be the same software and configuration as invoking
/usr/sbin/sendmail
> Of course it is. If you have SMTP on localhost, are you trying to tell
> me it WON'T be your MTA? You're running an MTA and a separate SMTP
> server? Isn't that rather redundant?
No. Suppose my SMTP port is bound to some kind of socket forwarder, say
on a firewall, for example. I want different things to happen with mail
generated on the firewall than with mail coming from somewhere external.
This is just an example, I don't do this. However, I have an MTA and an
SMTPd which are separate on my machine, the SMTPd does invoke the MTA,
but isn't it. I also have a different configuration on a different IP
address's port 25.
> > Please read up on /usr/{lib,sbin}/sendmail -bs which should
> > be the canonical submission form for an MUA.
> Says WHO? Please point me to the RFC for that. That is A valid
I don't think there's an RFC for it. But if you read up on RFC2821 then
you may notice all the responsibility transfer stuff, which doesn't,
last time I looked, include anything about a "drafts folder".
> submission form. In fact that's exactly what my SMTP process is running
> (well, exim -bs really).
So, in fact, your SMTP on localhost is inetd. But I'm just being silly now,
the point is that you have to have either inetd or sendmail -bd actually
running. (where "sendmail" is a link to whatever mailer you actually use).
If it's not running, that doesn't stop you fork()ing and exec()ing
sendmail, which will, if necessary insert it into the queue, and do
whatever other processing is necessary. If you can guarantee that all the
time your system is up, you can have something listening on localhost
port 25, then fine.
> >>much more sense for every MUA to assume it has access to an SMTP port on
> >>_some_ host than to assume that it will have access to an MTA program.
> > Huh? have you never had a network outage?
> Of course, but on my system you can deliver to SMTP on localhost (hey,
> I've never lost _that_ one on a network outage) or to an available SMTP
OK. And your daemon has never crashed?
> host anywhere else on the network.
Which will, of course, allow you to relay.
> > The reason that one should use the program and deliver stuff via a pipe
> > on the local machine is that SMTP requires ability to cope with network
> > outages and the transfer of responsibility. These are both complicated
> > to deal with, because you need to have a spool of messages, thus it is
> > the MTA's job.
> But that's totally unchanged by having the MUA deliver the mail to SMTP
> on your localhost. In fact, it's quite simple to set exim up to only
Why? If the SMTP on localhost isn't there for some reason, then you can't
do that you have to put it in your aforementioned "drafts folder", where
you can happily forget about it.
> permit SMTP connections from it's own host, so it should be as secure as
> the pipe.
I can't find any good reference to it, only things referring to it, but
most IP networking layers are what is known as "weak-endpoint". They now
have some anti-spoofing protections, but beware, binding to localhost is
not always as secure as you might think it is. Mostly the reason is not
about security it's about being able to guarantee that the message will
be accepted.
> > Leave the job of queuing and accepting responsibility to the system which
> > can deal with it.
> Every mailer I've used _does_ that - even the infamous Microsoft Outlook
You just told me that it couldn't. You said it put it in a "drafts folder"
which is not even closely the same.
> Express. It does however refuse to hand it off if the receiving SMTP
> host refuses to accept responsibility.
Correctly, if indeed that is what it does.
If it implements queuing, retrying, and proper responsibility transfer,
then it implements SMTP (as well as, obviously, being able to speak the
commands and responses involved as part of the protocol). In which case,
it's an MUA and MTA combined. However, one of the things we're arguing
against is complexity. Complexity is generally a *bad* thing.
MBM
--
Matthew Byng-Maddick <mbm@???> http://colondot.net/
