wmartin@ALMSA-1.ARPA (Will Martin -- AMXAL-RI) (09/25/86)
Is there any way that an ordinary user can "prod" or signal a remote host across the ARPA/MILNET to cause that remote host to check for and start the sending process for mail that may be queued up for delivery to the user's host? An example: my host has had problems for some days, such as the network connection being down, or the machine being down -- something that has prevented it from receiving mail from the network. It comes back up, and some incoming mail is delivered. I, as a user on that machine, look at the mail and can tell that there is still some missing (such as some mailing-list digests, where issues are numbered and I can see that I have not received certain numbers). Is there something I can do using the "telnet" or "ftp" capability to reach across the network to the host that sends out these messages and tell it that it should now search its out-bound queues for any mail to my host and start the regular mail delivery process? This could be especially valuable if I knew, for example, that my host will be up for a short time and will then go down again, and that the remote machine normally delivers mail to us at night when I know that my computer will be down again. So if I could trigger an unscheduled, right-now mail delivery, the traffic would get through -- if I do nothing, and let the scheduled processes run things, there would be another unsucessful delivery attempt and perhaps the mailer would time out and reject the mail back to the sender. I recall that there were some methods for a person to simulate an automatic net-mail-type host-to-host connection; that led me to wonder if such a method could be used to trigger a remote machine to start up such a process. Regards, Will Martin
SRA@mit-xx.ARPA (Rob Austein) (09/26/86)
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 <SRA@XX.LCS.MIT.EDU>
jordan@ucb-arpa.ARPA (Jordan M. Hayes) (09/26/86)
From: Rob Austein <SRA@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
SRA@mit-xx.ARPA (Rob Austein) (09/26/86)
Date: Friday, 26 September 1986 11:19-EDT
From: jordan@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).
--Robjordan@ucb-arpa.ARPA (Jordan M. Hayes) (09/27/86)
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
SRA@mit-xx.ARPA (Rob Austein) (09/27/86)
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.