🚀 go-pugleaf

In article <1726@ubvax.UUCP> vix@ubvax.UUCP (Paul Vixie) writes:
>
>Therefore he decided to just call up the Vax sendmail and say 'TURN' to get
>his mail.  He was surprised to see sendmail reply, 'command not recognized.'
>I was surprised, when subsequently examining srvrsmtp.c, to see that there is
>no mention of TURN in the list of known SMTP commands.
>
>So, two questions:
>	(1) does sendmail really not support TURN?
>	(2) has anyone hacked this in?
>
>Hacking it in doesn't seem to difficult -- if it hasn't been done, and I do it,
>is anyone else interested in having the patches?
>-- 

1. Sendmail really does NOT support TURN (one in a LONG list of gripes I have 
with sendmail, after just finishing an implementation of SMTP for a computer
that talks to our VAX).
 The minimum implementation of SMTP includes the following commands only:
        HELO
	MAIL
	RCPT
	DATA
	RSET
	NOOP
	QUIT
 
2. I doubt that you'll find anyone who has actually hacked it in... it's
really a bigger deal than it seems. You have to teach sendmail how to read mail
out of a mailbox, dig the appropriate information out of the headers, and
send it along. You might be better off implementing uucp instead. (actually,
I believe that's been done for the PC...)
 
-Kevin

> 2. I doubt that you'll find anyone who has actually hacked it in... it's
> really a bigger deal than it seems. You have to teach sendmail how to read mail
> out of a mailbox, dig the appropriate information out of the headers, and
> send it along. You might be better off implementing uucp instead. (actually,
> I believe that's been done for the PC...)
>  
> -Kevin

Sendmail wouldn't have to do all that!  It would simply have to go through its
queuefiles, looking at the envelope of each letter and determine which ones go
to the host on the other end of the SMTP connection.  The routines to do this
are, of course, already part of sendmail.  You just have to be familiar enough
with sendmail internals to tie SMTP-receiver and the SMTP-sender code
together.

In article <1701@xanth.UUCP> kyle@xanth.UUCP (Kyle Jones) writes:
>> 2. I doubt that you'll find anyone who has actually hacked it in... it's
>> really a bigger deal than it seems.
>Sendmail wouldn't have to do all that!  It would simply have to go through its
>queuefiles, looking at the envelope of each letter and determine which ones go
>to the host on the other end of the SMTP connection.

The reason there is no TURN command is much more fundamental.  How do you
verify the identity of the "calling" entity reliably enough to believe you
are giving the mail to the right entity?

True, the security is marginally better when you are doing the "calling"
to deliver, but it is better.

-- 
James M Galvin

>>queuefiles, looking at the envelope of each letter and determine which ones go
>>to the host on the other end of the SMTP connection.
>
>The reason there is no TURN command is much more fundamental.  How do you
>verify the identity of the "calling" entity reliably enough to believe you
>are giving the mail to the right entity?
>
>True, the security is marginally better when you are doing the "calling"
Now wait a minute. If we're using SMTP in the first place, aren't we assuming
that there is some form of controlled access to the SMTP server? Like an
ethernet where all the hosts are known? If we can't guarantee that, we have
even bigger security problems than reading someone else's mail. We've got
people sending all sorts of unverified messages.
 
Yeah yeah, I know, SMTP isn't secure. After all, anyone can invoke sendmail
with the -bs flag, and voila! have their own smtp server.  Or even better,
open up a stream socket and connect to the SMTP server on any host. But
getting back to the TURN command, if we're disallowing TURN's because SMTP
isn't secure, we should disallow SMTP in general because it isn't secure.

I guess this all boils down to the fact that SMTP's biggest problem is its
lack of security.

Cheers,
       -Kevin

In article <6794@dartvax.UUCP>, kevins@dartvax.UUCP (Kevin M. Schofield) writes:
> Now wait a minute. If we're using SMTP in the first place, aren't we assuming
> that there is some form of controlled access to the SMTP server? Like an
> ethernet where all the hosts are known? If we can't guarantee that, we have
> even bigger security problems than reading someone else's mail. We've got
> people sending all sorts of unverified messages.

No, that's a much smaller problem, as the problem with TURN isn't reading
someone else's mail, its purloining it .. when the imposter gets his copy
the real recipient loses it forever.

The same situation applies with paper mail (snail mail).  I can mail a
letter and sign it Ronald Reagan if I feel like it (it might be against
the law, or it might not, but that's immaterial here).  But the post
office won't hand over mail to be if I role up and say "Hi, I'm from
the White House, give me all you've got"...

kre