It isn't really the possible delay as much as it is the interaction with
SMTP. I realize that SMTP could probably be modified to allow for a
specific type of message to be aimed directly at a pager (maybe?). But
if the message originated from a UUCP site, while perfectly legal to
deliver it, the real time advantages that I seek would not be possible.
SNPP, as I have said time and time again, is a simple protocol designed
for immediate interaction with the paging terminal, replacing a phone
line. It is not intended to be a two-way path for electronic mail.
On the other hand, the UUCP site has no chance at all at using the
SNPP over a TCP connection, so a few minutes delay vs. infinity
perhaps isn't so bad.
I do want to provide support for email connections, but want to do
it right. Right now, I just want to get something up and running--
something that I've already developed, and that works. How long
do you think it would take to get a full mail gateway into place
and make modifications to SMTP to allow for immediate status reporting
of failed or delivered pages?
We've already developed and use in production an EMAIL to IXO paging
gateway, and it works just fine. Our network management software
doesn't use it, as it just generates pages directly, but other folks
do use it. It simply pages the Subject: line of the email message as
well as sending the message via email to the recipient. I don't know
why I'd want to throw this away and use SNPP since it doesn't seem to
buy me anything.
Case in point: you have to provide the beeper "PIN" and the
message body itself to present to the IXO/TAP terminal in
order to even get the terminal to tell you if the PIN was
valid. In other words, the entire message (header and all)
must be completely delivered before message validation can
occur. It is my understanding that you cannot immediately
reject a message on the DATA portion of the message--only
on information contained in the header (RCPT TO in this case).
Since you can't validate the page until after the DATA, you
can't immediately reject it. Is this not the case?
Given a typical SMTP dialog like:
220 ni.umd.edu 5.65c/IDA-1.4.4 Sendmail is ready at Mon, 6 Sep 1993 14:28:16
250 Hello sayshell.umd.edu, pleased to meet you
250 <louie(_at_)sayshell(_dot_)umd(_dot_)edu>... Sender ok
250 <louie(_at_)ni(_dot_)umd(_dot_)edu>... Recipient ok
354 Enter mail, end with "." on a line by itself
221 ni.umd.edu closing connection
There's no reason why the response to the CR LF '.' CR LF terminating
the data can't be something othe rthan '250 Ok'. According to RFC-821
(that documents SMTP), the valid responses to the second phase of the
data command are
552 Requested mail action aborted; exceeded storage allocation
554 Transaction failed
451 Requested action aborted; local error in processing
452 Requested action not taken: unsufficient system storage
You could certain return something other than "Transaction failed" as
descriptive text if the PIN number (which no IXO system I've seen ever
uses) was wrong.
Therefore, if the IXO/TAP gateway did not like the pager "PIN"
number, the only way to be notified of failure is via email.
Don't you think that this would make a simple UA rather
cumbersome to create? Consider one sitting on a PC running
a Clarkson packet driver. It would have to sit there with an SMTP
server active for a period of time after a page had been sent
waiting for a bounce message that may or may not come.
Don't have the client wait around; return an error at the end of the
DATA command. Of course, he still will never know that the page was
delivered or not, due to lack of coverage, pager being turned off,
Actually not competing arguments. I want to be able to tell people
how they can send messages to their beepers via the Internet starting
"next Tuesday," and "this" is how they can do it. I also want to
provide a spec so that software providers can create simple UA's to
eventually do the job--perhaps integrating support for them into
The way that we tell people is to send mail to
username(_dot_)beep(_at_)foo(_dot_)dom(_dot_)ain, which will page the
Nothing different than they've been doing for years, other than the
addition of the ".beep" suffix on the user name.
You have to be careful not to build too high a level of expection that
devliver of the message will actually occur. As Marshall Rose pointed
out, delays of 10 or 15 minutes are not unusual here in the
Washington, DC area either. And given the open-loop nature of the
page, you don't know that you missed a page because you were in an
area of bad coverage.
Frankly, I'd rather just have an RPC to the paging system rather than
anything that has to go via an IXO gateway. Those paging system are
just plain ugly. In any case, doing IXO is not that difficult; we do
it in an expect script (checksums and all).
Louis A. Mamakos
University of Maryland, College Park