Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Can a user \"prod\" a remote host?

0 views
Skip to first unread message

Rob Austein

unread,
Sep 26, 1986, 6:22:48 AM9/26/86
to
In theory SMTP provides a facility that could be used the way you
describe, the TURN command. To use it you'd call up the host you
wanted to prod, negotiate a TURN (at which point you turn into an SMTP
"server" instead of an SMTP "user"), then get instant gratification as
the foreign machine dumped all its mail out to you.

In practice I am not aware of any SMTP server that implements TURN
except to negotiate a close correctly after a foreign site has
inflicted a TURN on you. Too much hair, particularly for mailsystems
where the smtp-server (mail listener) and smtp-user (mailer daemon)
are two different program.

There's also a potential for misuse by pinheads if something like TURN
were implemented. For the case you mention it is pretty clearly
justified, but what do you do about the bozo who calls you up as a
regular habit because he thinks your retransmission queue scan time is
too slow? Stop answering the phone, I guess....

--Rob Austein <S...@XX.LCS.MIT.EDU>

Jordan M. Hayes

unread,
Sep 26, 1986, 12:39:12 PM9/26/86
to

From: Rob Austein <S...@XX.LCS.MIT.EDU>

In theory SMTP provides a facility that could be used the way
you describe, the TURN command. To use it you'd call up the
host you wanted to prod, negotiate a TURN (at which point you
turn into an SMTP "server" instead of an SMTP "user"), then get
instant gratification as the foreign machine dumped all its
mail out to you.

Yes, but I think the main reason this has never been implemented is for
security reasons ... I could find a machine that does a lot of queueing
on a regular basis (ucbvax for one queues a lot, since the load is
usually above the "safe" threshold for sendmail to run to completion)
and telnet to port 25 on your machine and issue a TURN and I steal all
the mail headed for that machine ... not _too_ cool ...

/jordan

Rob Austein

unread,
Sep 26, 1986, 4:10:18 PM9/26/86
to

Date: Friday, 26 September 1986 11:19-EDT
From: jor...@ucbarpa.Berkeley.EDU (Jordan M. Hayes)

Yes, but I think the main reason this has never been implemented is for
security reasons ... I could find a machine that does a lot of queueing
on a regular basis (ucbvax for one queues a lot, since the load is
usually above the "safe" threshold for sendmail to run to completion)
and telnet to port 25 on your machine and issue a TURN and I steal all
the mail headed for that machine ... not _too_ cool ...

Um, yeah. So you'd want to look up the name from the HELO and check
that the foreign address you were talking to corresponded. Except
that here in the future somebody could get their domain server to lie
for them. Mumble. So you'd have to do a reverse (IN-ADDR) lookup too
to verify the address (assuming that you aren't dealing with somebody
smart enough to forge IP addresses or corrupt your resolver, but if
they can do that you might as well give up, you lose anyway).

That does limit the usefulness some, since traditionally SMTP
listeners will accept almost anything in the HELO. On the other hand,
it doesn't bite you until you use TURN, and it'd give people a motive
to set up the IN-ADDR data correctly (a pet peeve).

--Rob

Jordan M. Hayes

unread,
Sep 26, 1986, 9:04:00 PM9/26/86
to
A lot of places and mailers _do_ check the inbound address for
correctness, but there's nothing stopping me from being on the machine
I claim I am, but asking for mail that the other end hasn't gotten
around to delivering yet -- if the load is high enough on ucbvax, and
mail comes in that needs to go to xx.lcs.mit.edu, it will get queued
... in the interim, i go to xx.lcs.mit.edu and telnet to port 25 on
ucbvax and give a turn ... sendmail on ucbvax says "oh, ok -- here's
your bloody mail" and I get it all ... I repeat -- not _too_ cool.

/jordan

Rob Austein

unread,
Sep 26, 1986, 9:04:09 PM9/26/86
to
You're right. And this just a few days after I was caught
pontificating in public on why one should never trust the guy at the
other end of the network. Foo. Sorry for the noise, folks.
0 new messages