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

Tim Showalter wrote:
> MTA is a misleading term.  If the only part of the MTA is the SMTP server,
> what happens between MTAs and MUAs?  There's stuff there, even if it's just
> a program that appends to a file.  You say it's not part of the MTA.  It's
> clearly not part of the MUA.  But it is a part of the SMTP model; it is as
> important as the MUA and the MTA, but it's not getting the recognition it
> deserves.
Yes, I think you're right, it definitely deserves a better recognition.
Not the least these days when the requirements is much higher on the
internet messaging model then it was in the earlier days. Everybody
would gain from having a more accurate model to work with.

> So that is, for most users.
>         [a message in Sender MUA]->[Sender MTA]->
>                 [Receiver MTA]->[{something}]->[Receiver MUA]
I would like to call the "something" a message store.
Although it's a term borrowed from the OSI model, it makes sense.
Someone suggested delivery agent, but I would regard that as the
mediator between the message transfer agent and the message store.

The presence of a message store is easier to understand today when
we have IMAP to play with. In particular, IMAP's capability to move
around messages between multiple mailboxes on the server side.
It seem not appropriate to say that the MTA is involved in such
post-delivery tasks. IMAP can be said to be the access protocol
to the message store.

> I consider the "something" to be part of the MTA because it is transferring
> the message.  But I really don't care.  My desire is that somewhere in
> "something" is a filtering agent.
Eventually it all comes down to how we define things. My view on an
nternet messaging system is most probably not the correct one. But
I do think the exercise of trying to find the least incorrect one
might pay off in a cleaner design of it's components such as Sieve.

I think filtering agent is a good term for an entity responsible
to perform rule-based filtering. Agent because it does the filtering
on behalf of someone, presumably the end user.

If I would choose a place for filtering agents to reside in, it
would be the message store. The reason is because this is the only
place where you have access to the end user's mail folders.

I was opposing a bounce action as part of a filtering rule primarily
because I thought it to be performed as a post-delivery event. My
view of filtering was as a service for the end user to organize the
flow of incoming messages to his/her maildrop.

The more I spend time on this issue, the more I get a feeling that
most of the words spent sofar have it's origin from one or more
misunderstanding. Early on there was a discussion on whether a
bounce was a kind of a reply or not. Their similarity might not
be important after all. From my point of view they seem to be in
contexts that are mutually exclusive to each other. So, were a
bounce is a valid action, reply is not. And vice versa.

It might be good to recognize in the draft that Sieve might be
put in use in either pre-delivery or post-delivery processing.

In the case of pre-delivery processing, it's all about to decide
whether the delivery will succeed or not. A bounce action will
generate a DSN as described in the draft. As a matter of fact,
after re-reading the DSN spec (RFC 1894) it might be an idea to
rename that action to fail or failed to better match the
intended use of DSN. This seem to be a task for the MTA.
(Or may be the message delivery agent, MDA ;-)

In the case of post-delivery processing, the task is to help
the end user to organize incoming messages in a configurable
way, including moving messages to different mail folders.

I would suggest to identify the transfer point between pre- and
post-delivery to be the maildrop. Before the message have reached
the maildrop, an end user can only accept or reject a message.
After the message have reached the maildrop, the message have
been successfully delivered and can therefore not be rejected.
What's left is for the end user to decide how to handle the
message.

I would suggest to not allow a bounce action in post-delivery
processing of incoming messages, only reply action.

-- 
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