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(_at_)andrew(_dot_)cmu(_dot_)edu