[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Q: Setting retries on the half-hour?




Some thoughts/suggestions interspersed below:

> 
> > On Sat, 23 Mar 1996, Dario Alcocer wrote:
> > > I'm trying to do this so that I can synchronise the scheduler to
> > > deliver mail when my PPP connection (brought up every half-hour using
> > > a cron job) is active.  If there is a better way to do this, please
> > > let me know.
> > 
> > It sounds like what you really want to use is some form of UUCP. If your
> > link is not available at all times, you'll have problems with incoming
> > mail as well. 
> 
> 	I have thought about two approaches:
> 
> 	- a mechanism to send (rapidly) to the scheduler some info,
> 	  that it should get channels matching "smtp/*" into active
> 	  processing.  (That is, expire their timeouts)
> 	  That is (among other things) subject to system resources
> 	  at the scheduler -- if it can't start running those channels
> 	  due to lack of resources, what then ?

Seems very clear to me that this is the way to go.  It should be
a simple straightforward implementation to just expire a timeout or
all timeouts and then the message(s) would get delivered.  This means
that either a single host/channel could be told to attempt delivery NOW
or all hosts should be retried now.
The sendmail program should be fixed to use this, i.e., the sendmail -R
option could finally be implemented.  Then you could just command line
dump a queue with the following command:

$ sendmail -R name.com
or
$ sendmail -R                  ;# for all queues to be dumped/attempted

Every time a site connects to an ISP or the process can be put in place
to tell the queue to be dumped *for that site*.  If so desired it could
be put in the crontab although that is not as elegant as doing it only
when the site has just dialed in and is UP.

The UUCP approach seems (IMHO) to be a rather inelegant approach
(to put it politely).

> 
> 	- some people have asked for an ability to:
> 		- try to send with SMTP
> 		- if SMTP timeouts (no connection), send with UUCP
> 	  That can (perhaps) be solved with alternate-routes
> 	  mechanism, however it was never finished in the
> 	  original system, and there are just some hooks, but
> 	  small parts of it are still missing...  (Like a way
> 	  to handle interlocks of multiple channels processing
> 	  same message..  Consider the SMTP vs. UUCP above,
> 	  if BOTH systems send, you will get double delivery
> 	  every time..)
> 
> > --
> >  "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 
> 
> 	/Matti Aarnio <mea@utu.fi>
> 


> paul fox wrote:
> 
>  > 
>  > > I guess one good solution exists now, although its expensive (at least
>  > > for me): buy a router ($1000 US-$1500 US) that presents a dialup as a
>  > > virtual Ethernet (something like an Ascend Pipeline 50?) that would
>  > > connect transparently to your Internet service provider (ISP) whenever
>  > > an outbound SMTP connection to a remote host takes place.  However,
>  > > this solution would also require that your ISP implement dialup on
>  > > demand at their site too, something I think most ISPs wouldn't be
>  > > interested in.
>  > 
>  > 	Hmm.. You mean from your ISP to yourself so that the ISP
>  > 	does dialing ?   I see why they are not very much interested
>  > 	in such a setup  :-)  (It is a question of billing...)
> 
> ISP's are going to have to solve this problem -- a lot of people want
> that service.  one feature of the Ascend boxes is that they can do a
> dial-back connection -- your ISP can call you, your box hangs up, and
> calls back.  the Ascend product can _also_ do Caller-id authentication --
> i can refuse a call from you if it doesn't have the right CLID info.  so
> what is really needed is a combination of the two features -- refuse the
> call based on CLID (so that it is never answered), and then dial-back.
> the Ascend products do not do this, but if Ascend is as smart as it is
> profitable, it will soon.  :-)

Yes, ISP's need to solve this problem.  With the above described
fix and a simple addition to whatever authentication protocol
or dial-in sequence that is used, mail could be delivered
when a site comes on line.  Note that if a site is already online
mail would be delivered normally on the first try.  This will
work whether the ISP dials a site or the site dials the ISP.

> ...
> 
> paul
> ---------------------
>     paul fox                            american internet corporation
>     pgf@american.com			(home: pgf@foxharp.boston.ma.us)
> 


Cheers,

Chris Healey
chealey@globalcenter.net