Re: [Exim] Exim on a single-user system

Matthew Byng-Maddick wrote:

> On Wed, Jan 02, 2002 at 09:18:54AM -0500, Derek Broughton wrote:
>
>>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.


Of course, but my entire point is not that MUAs shouldn't implement SMTP
- they shouldn't - but dman said they shouldn't have anything to do with
SMTP, and I believe that talking to an SMTP server is a perfectly
acceptable way to pass on a message.


>>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


No I'm not. A Windows MUA MUST provide a way to deliver via SMTP. They
don't need to properly support the full function, but they have no other
means to deliver their mail.


> not sure how many windows MUAs deal correctly with, for example,
> >>> 421 Too busy, try again later
> as an opening banner.


What's the problem. Either they try to have a conversation and time
out, or they return as undeliverable immediately. Either way, they hang
on to your mail until you tell it what to do.


> 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


So 'properly' would be to implement a Windows MTA ??? Ack!


>>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.


You're wrong. From an MUA's point it IS just a set of commands and
responses. As I keep saying, an MUA _shouldn't_ implement SMTP, it
should just be able to talk to an SMTP server to send its mail.


>>>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.


If it's a pipe, it isn't an SMTP daemon...

> 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.


Which doesn't appear to speak to the topic. What's your point?



>>>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.


But the point has been made, and not disputed, that there are a huge number of systems out there without an MTA.

>>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.


Excuse me, but _I_ didn't raise the issue of other protocols.

>
> 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.


No, I'm not missing that at all. You're missing that there are millions
of systems that don't have cron or anything else that needs to automate
mailing. If you have an MTA, it's not a problem to pipe to it - though
there is the problem that there is no _standard_ for doing that, only a
consensus on most (maybe all) *nixes that we'll use sendmail. There is,
though a standard for SMTP.


> 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.


I think it's important too. I have said from the beginning that I agree
it isn't correct for an MUA to implement SMTP, but that it should be
able to talk to an SMTP server.


>>(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.


I wouldn't dream of doing things in a wrong way :-) Fortunately,
there's nothing in what you've said to suggest that this is wrong.


And later, Matthew said:

>>>>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


I did, and your examples notwithstanding, I think it's still fair to say
that the SMTP daemon (if present) is _usually_ connected to your MTA.

>
> 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".


But that's about implementing SMTP. And I'm not suggesting that - I'm
saying it's fair to have an MUA deliver the mail to SMTP, and to do that
it needs to understand a subset of commands and responses.


> So, in fact, your SMTP on localhost is inetd. But I'm just being
silly now,


Yeah :-) It works ...

> OK. And your daemon has never crashed?


OK. My claims might have been a trifle optimistic - considering the
trouble I'm having right now. :-)

>
>> to an available SMTP
>> host anywhere else on the network.

> Which will, of course, allow you to relay.


That's implicit in 'available'.


>>>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.

Exactly. A small confusion over the use of 'that'. What OE does,
correctly, is to 'leave the job of queuing and accepting responsibility'
to the SMTP server to which it is talking.

derek