[comp.mail.sendmail] mail delivery over intermittent Internet link

jnford@handlebar.weeg.uiowa.edu (Jay Ford) (03/13/91)

There is a remote site connected to my site via an intermittent dial-up link
for which I will be forwarding mail.  We're running sendmail on each end, and
are probably not inclined to switch mailers, but....

I'd like to avoid the doomed retries which would occur with every queue run
while the dial-up link is down.  It seems necessary to do some kind of queuing
on my system separate from the normal sendmail queue.  I seem to recall some
discussion a while ago about using multiple queues with sendmail, but I can't
remember the details.  Can someone who remembers the discussion fill me in?

The SMTP "turn" command seems like a perfect way for the remote site to request
their queued mail.  They would bring up the link, connect to my mailer, and
turn the connection around to receive their mail.  Has anyone added support for
the SMTP "turn" command to sendmail?

Any information about this stuff would be appreciated, including completely
different approaches.  I'm fairly open to any solution which will work, but I
don't want to stray too far from the mainstream UNIX-SMTP-Internet model.

------------------------------------------------------------------------
Jay Ford, Weeg Computing Center, University of Iowa, Iowa City, IA 52242
jnford@handlebar.weeg.uiowa.edu, 319-335-5555

huntting@csn.org (Brad Huntting) (03/16/91)

In article <4859@ns-mx.uiowa.edu> jnford@handlebar.weeg.uiowa.edu (Jay Ford) writes:

>There is a remote site connected to my site via an intermittent dial-up link
>for which I will be forwarding mail.  We're running sendmail on each end, and
>are probably not inclined to switch mailers, but....

[ etc ]

>The SMTP "turn" command seems like a perfect way for the remote site to request
>their queued mail.  They would bring up the link, connect to my mailer, and
>turn the connection around to receive their mail.  Has anyone added support for
>the SMTP "turn" command to sendmail?

[ etc ]

I've thought about this too...  sendmail (5.61+ida) used to support a
flag (-R string ???) which would supposedly run the queue for all
messages which `matched' `string'...  My solution was going to allow
SLIP connections to rlogin and do a /usr/lib/sendmail -R slip.host.name
to get their mail.  The turn command sounds like a much cleaner
solution...

With more and more sites doing dialup slip this is a problem which
needs a good solution.  Our CS department is thinking of offering slip
connections to students and professors who run unix at home.  It's
generally thought that this will be cheaper in human resources than
trying to maintain uucp connections, and I agree...  As it stands now,
the only real option for delivering mail over such connections is to
have the machines dialup and stay connected for a long (~1hr) time...
This means an extra phone line at the remote site, and lots of phones,
modems, and annex ports here at school...  Cheap ISDN would sure be
nice...


brad

paul@caen.engin.umich.edu (Paul Killey) (03/25/91)

some time ago, i worked on mods to sendmail so that it would sign on to
a mainframe (a.k.a lameframe or mailframe) do a TURN, and then pick up
the mail the mainframe had to send out.  it ran over an x.29 line and a
serial line.

it needed a password to sign on with, so it was felt that the TURN was
OK.  to send its mail out, it would log in to the sendmail machine, and
its login shell was basically sendmail.

instead of being a giant with feet of clay, this thing was an amdahl (now a
3090) with feet of a Vax 750.

Many changes in daemon.c, but it worked.  undergrads would entertain
themselves by sending messages composed of some combination of control
S, interrupt characters and end-of-file characters which the mainframe
would interpret as such and stop or croak the mail process.


it was a "short term" solution that was supposed to tide the mainframe
crew over until they got something modern, like tcp working.

five short years later, they are still using it.

nothing is temporary, and nothing is permanent.  just like where you
work, right? -:)

anyway, it was a production setup that did many messages.  and is still
doing them.

my partner (hi emv) and i had to get different jobs to get away from
that monster.

--paul