Message queueing

[holger krekel]

Christopher Browne wrote:
> > On Thu, May 02, 2002 at 10:45:29PM -0400, Christopher Browne wrote:
> > > The BIG problem with the "rolling via SMTP" is that SMTP doesn't
> > > provide you _any_ kind of end-to-end guarantees on delivery.
> > 
> > Theoretically you are right. SMTP by itself does not guarantee
> > much of anything. But using something like the well (C-)written
> > highly modular 'qmail' on both sides might make it easy to be sure that
> > a message has been sent and received. You should prefer peer-to-peer
> > relaying instead of sending it through several hops.
> > I am pretty sure that you can get guarantees without having to resort 
> > to implement TCP over mail :-) 
> > 
> > I admit that i haven't tried such a setup myself. But i would definitely
> > give it a look especially because qmail is - apart from highly
> > secure - fast and very easy to configure.
> 
> Which SMTP server you use makes _zero_ difference if some misconfiguration 
> means that dropping messages in means they go in the "bit bucket";

thats exactly the reason i talked about 'peer-to-peer' and qmail
on both sides. We are *not* talking about putting some SMTP-servers
somewhere on the net and using them as intermediate relays. More specifically
the idea is that you configure 'smtproutes' to directly deliver messages
to a specific server (without any intermediate hops). The OP
certainly wants to have complete control over *all* smtp-instances to
make sure that QoS-properties can be guaranteed. And of course you
have to be sure that nothing is misconfigured. What do you think 
happens if you misconfigure IBM MQSeries?

    holger