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

[Tim Showalter <tjs@xxxxxxxxxxxxxx>]

I've trimmed the CC line because I don't need multiple copies of messages.
If there are a number of followers of the thread who aren't subscribed, I'm
sorry.


If you find a good definition of MTA and MUA, please let me know.  The
definitions in 1123, if I recall correctly, are because people were using
them; they're very vague.

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.

So that is, for most users.
	[a message in Sender MUA]->[Sender MTA]->
		[Receiver MTA]->[{something}]->[Receiver MUA]

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.

On Sun, 3 Nov 1996, Tomas Fasth wrote:

> Still, I thought it to have been unclear when this MTA-level
> filtering was about to take place. [...]

Nailing it down limits the applicability of the draft.  What does it change?

Rationale: I don't understand the difference between MTA and MUA filtering.
In some systems (say, Cyrus) things will be done essentially by the MTA
(before the message ever hits a user-accessible mailbox).  In a POP3 system
where filtering has to be done where remote folders are stored, filtering is
done by the client.  Both are equally capable of sorting mail into folders,
generating a reply and submitting it to an SMTP server, of throwing the
message away, and of generating a DSN.

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

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

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

> It is not mandatory to keep the address to the SMTP originator
> beyond the point of delivery, so it might not be available when
> you are about to initiate a bounce.

Actually, the Return-Path line is for that purpose.

> Therefore, in the case of mailing list exploders, you may not
> know by what address the message was delivered to you, which
> makes a bounce pointless, because you may not have access to
> the return-path nor the recipient address (which may be needed
> to fix the cause of rejection).

You mail the mailing list exploder which has written its address into the
Return-Path line.

> Was Sieve really intended to do SMTP-level filtering as well?
> Or was this only a wild idea raised in the heat of the debate?

I hadn't put enough thought into this.  You can't filter a message until you
have a copy of the message (mostly).  So my intention was that the message
would have to leave SMTP before being checked with a Sieve script.

I believe the difference between MTA and MUA filtering, where the filtering
agent has the entire message, is more or less meaningless.


I have made mistakes with the bounce command.  At the very least, would
changing bounce so that

	* only one bounce per message
	* performing a bounce restricts all other actions

make things better?

Would making "bounce" optional help?

-- 
                                           Tim Showalter tjs@xxxxxxxxxxxxxx