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

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



>>>>> "Matti" == Matti Aarnio <mea@utu.fi> writes:

    Matti> 	I have thought about two approaches:

    Matti> 	- a mechanism to send (rapidly) to the scheduler some
    Matti> info, that it should get channels matching "smtp/*" into
    Matti> active processing.  (That is, expire their timeouts)

Instead of expiring their timeouts artificially, how hard would it be
for the scheduler to calculate the number of intervals needed to
sychronise to a given time, and set the job's timeout to exactly that
value; in other words, have the timeouts be determined automatically
instead of strictly following the configuration file?  Of course, this
means I've probably just volunteered myself to implement this feature
;-)

    Matti> 	- some people have asked for an ability to: - try to
    Matti> send with SMTP - if SMTP timeouts (no connection), send
    Matti> with UUCP That can (perhaps) be solved with
    Matti> alternate-routes mechanism, however it was never finished
    Matti> in the original system, and there are just some hooks, but
    Matti> small parts of it are still missing...  (Like a way to
    Matti> handle interlocks of multiple channels processing same
    Matti> message..  Consider the SMTP vs. UUCP above, if BOTH
    Matti> systems send, you will get double delivery every time..)

I agree, this would be complicated, at least for what I had in mind.
The interesting thing about this particular problem is that I imagine
more and more users will run into this, due to the proliferation of
PCs running Linux/FreeBSD/NetBSD over a non-dedicated link.

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.

--
Dario Alcocer
alcocer@netcom.com