Re: bounce, mta, & mua (was Re: sieve draft)

Tim Showalter wrote:

> > In the case of sendmail, the final delivery is actually done by a
> > separate program (mail, rmail, mail.local). I would not include
> > that program in the domain of an MTA.
> Why not?  It's certainly moving an RFC-822 compliant* message from one point
> to another, even if it's not via SMTP.
>
> (* More or less, anyway.)
Hmm. It's not really about who has monopoly on moving messages around.
It's about what domains of responsibility the message is passing
through.
My view is that an MTA is not responsible of doing final delivery on
the local machine. Only to identify that the destination of the message
is local and then pass the message to the message store, (possibly using
a delivery agent ;-)

> > And in the end, what all my rioting in this thread have been
> > leading up to is my assertion that Sieve is actually executing
> > in the context of the message store, beyond the point where a
> > message have been delivered by the MTA but before the point were
> > it has been filed. Therefore a message cannot be bounced, only
> > handled by performing a drop, reply or store.
> Why?  What's the difference?  There is no prohibition of sending message
> status notifications from outside SMTP.
The difference is in how I define pre- and post-delivery processing.
Pre- is doing accept-reject decisions, post- is doing management
tasks. But that might be considered academical hair-splitting by
some.

> > Even if you allow to execute Sieve in a context where it is
> > possible to reject a delivery, you still have a problem when the
> > same set of rules are about to run on the MUA-level.
> So don't do that.  (This would be a major configuration error.)
Ah, but then, wouldn't it be a good thing to make a clarification
on when a set of rules is considered a major configuration error
and when not? Or maybe you suggest this to be addressed by the
implementation documentation. Which might be a better place
after all... Hmm.

What bothers me is that this spec is about to become a base for
several different implementations. I would recommend to design
Sieve in such a way that it will not become broken when shifting
from one implementation to another.

In this particular case, I asked for a clarification in what
contexts Sieve is to be designed for. If the context is not
clear, we might end up with a language causing more trouble
than joy.

-- 
Hälsningar/Regards

Tomas Fasth <tomas(_dot_)fasth(_at_)twinspot(_dot_)net>
tel: +46-13-218-181 cel: +46-708-870-957 fax: +46-708-870-258
TwinSpot is a subsidiary of EuroNetics Operation in Sweden