Subject: Re: sieve draft

From: Tomas Fasth <[email-masked]>
Date: Fri, 01 Nov 1996 23:07:09 +0100

Bart Schaefer wrote:
> 
> On Nov 1,  3:02am, Tomas Fasth wrote:
> }
> } What other than spam would be a subject for delivery refusal?
> 
> Some examples:
> 
> I run an email customer support service.  Customers with paid support can
> legitimately send mail to [email-masked].  All other messages
> sent to that address are bounced, with the suggestion that they pay up.
> (No, I don't really run such a service.  These are examples.)

IMO, your example above is not a subject for delivery refusal.
I regard it as a denial of service associated with a particular
maildrop.
I can easily imagine many kinds of commercial services similar to the
example above. Each having different access control mechanisms on the
same message store/maildrop site.
The question is, regarding that each automated maildrop service might
have it's own access control, where are all this best handled?
I suggest that a good design would be, from the MTA's point of view,
to regard the message as being successfully delivered to the maildrop,
which happens to have a service associated to it, a service which then
decides by it's own access control whether to accept the service request
or not.
I would not recommend to make that kind of handling a business of the
MTA. It would only be confusing and even hard to administer and
maintain.

> I subscribed to the [email-masked] mailing list, but now I don't
> want it any more.  I've sent a dozen unsubscribe requests, but nobody
> is managing the list and it keeps coming to me.  I want to bounce the
> messages back to the (admittedly unresponsive) list admin address and
> to the [email-masked] in hopes of getting their attention.  But
> that doesn't mean that everyone at my site thinks the fud-list is spam.

Hmm. In this case I think your approach is unfriendly.
Instead of taking the small annoyance of finding out the address of the
admin and the postmaster, and send them a polite request of removal,
you decide to bounce each and every message originating from that
particular list. I do not consider that a good use of filtering.

I do recognize a need of list management on the client side, but that
is hardly done by using filtering technics alone.

> I could come up with more, but they're mostly variations on one of those
> two themes:  (1) Only messages matching some criteria should be delivered,
> and all others should get a bounce explaining why they were not; (2) some
> source of mail not normally considered to be spam is for whatever reason
> abusing a mailbox, and a bounce should be generated to notify the sender
> of this unintentional abuse.

I suggest we begin by distinguish between message delivery and
message acceptance. By doing this we might be able to reach some
kind of consensus on what we are trying to achieve here.

My opinion is that a message ought to be regarded as delivered if
the message have successfully reached the maildrop. Note that a
maildrop can be more than just a simple file or a slot in a database.
A maildrop can be the entry to another subsystem which might control
the access to further processing or final storage.

My point is that if we use this description as a model, message
delivery is just about to find the correct maildrop. That makes
the task of the MTA much less complicated.
By delegating maildrop specific processing, for example message
acceptance, to the subsystem beyond final delivery, you have,
in my opinion, achieved a better modular approach to the messaging
infrastructure.

> Not true.  For example, there may be a valid reason for some mailboxes
> to reject all messages that do not have a digital signature, or that are
> not encrypted using a particular public key.  But the protocol doesn't
> reveal whether the data is digitally signed or encrypted.

Yes, there are reasons for rejecting certain messages depending on
what context they are in. Yes, the protocol handler should not bother
about digital signatures and such.
But then, I regard neither of those things to be among a message
transport agent's responsibilities.

> A reply action is typically directed to addresses taken from the RFC822
> header of the message, e.g. the "From" or "Reply-To" fields.  A bounce
> is typically directed to the envelope sender, e.g. the SMTP "MAIL FROM"
> address.

I see. My interpretation of current internet standards in this area,
is that the SMTP "MAIL FROM" address, also called the originator
address or return-path, is recommended to only be used by the MTA for
resolving non-deliveries and mail system failures. There are also RFC
documents describing how such a "bounce" should be formatted.

There seem to be a slight confusion between the SMTP type of bounce and
your type of bounce. But then, I am asserting that your type of bounce
is not really a bounce, but rather something that is in practice the
same as a reply. There are even draft documents describing something
called message disposition notifications. I think those can be used
in such similar situations that have been described here and earlier.

Further, I do not regard your use of return-path as conformant with
current internet messaging practice. 

> There presently aren't many (if any) tools that are able to
> make that distinction, because there are few MTA-level filtering tools;
> almost all must run "post-delivery" without access to the SMTP envelope.

Which is my point. There are reasons for running the filtering tools
as "post-delivery". One is that since the filtering rules originates
from an end user and therefore have unpredictable results, it's not
a good idea to let those rules control the pre-delivery process.

You can always argue that there is need for filtering rules that
are centrally administred by the postmaster. But then, I assert that
this might be a dangerous approach. Do you really want to do this?
Slightest mistake in one of the rules will potentially affect all
the maildrops on the site.
Isn't it bad enough to have the sendmail.cf to worry about? ;-)

> One purpose of the sieve language, as I understand it, is to enable the
> user to intervene *before* the MTA delivers the message, thus making it
> *possible* to have distinguished "bounce" and "reply" actions.

The very idea of having individual users to dictate the behavior of
the MTA is revolting to me. It even sounds outright dangerous.

But then, I am sure that your cause is absolutely sincere.
I only ask you to consider another approach of solving your problem.
And there are many good uses for a filtering language like Sieve,
although I disagree with your particular type of use.

-- 
Hälsningar/Regards

Tomas Fasth <[email-masked]>
tel: +46-13-218-181 cel: +46-708-870-957 fax: +46-708-870-258

---

From: "Bart Schaefer" <[email-masked]>
Date: Sat, 1 Nov 1997 20:19:41 -0800

On Nov 1, 11:07pm, Tomas Fasth wrote:
} Subject: Re: sieve draft
}
} Bart Schaefer wrote:
} > 
} > ... an email customer support service.  Customers with paid support can
} > legitimately send mail to [email-masked].  All other messages
} > sent to that address are bounced, with the suggestion that they pay up.
} 
} IMO, your example above is not a subject for delivery refusal.  [...]
} I suggest that a good design would be, from the MTA's point of view,
} to regard the message as being successfully delivered to the maildrop,
} which happens to have a service associated to it, a service which then
} decides by it's own access control whether to accept the service request
} or not.

It's certainly possible to handle it that way.  However, note that there
are nonzero costs associated with accepting delivery.  If the typical
message to my hypothetical support service contains a many-megabyte
coredump (and I have direct experience with users who mail such things
to support addresses), I'd much rather refuse delivery altogether than
have to consume the bandwidth to accept the message and then discard it.

My point is not that this is the best or only way to manage such a system,
merely that the bounce capability provides a useful alternative.  Whether
to permit it should be an administrative decision of the MTA maintainer,
not a decision of the language design -- unless there are other technical
reasons to omit it from the language.

Hmm; having written that, I see that as presently written the sieve draft
assumes that the message has already been "accepted" and that the bounce
action merely resends it via a DSN.  In that case I agree that "bouncing"
the message is much less interesting as a separate action.  However, I'm
not convinced that there aren't valid reasons to want to use a DSN rather
than an MDN to describe what has occurred.

} I would not recommend to make that kind of handling a business of the
} MTA. It would only be confusing and even hard to administer and
} maintain.

Why would it be any harder to administer/maintain than a collection of
individual services?  Especially if there is simply a seive script to be
associated with each such address.

} > I subscribed to the [email-masked] mailing list, but now I don't
} > want it any more.  I've sent a dozen unsubscribe requests, but nobody
} > is managing the list and it keeps coming to me.  I want to bounce the
} > messages back to the (admittedly unresponsive) list admin address and
} > to the [email-masked] in hopes of getting their attention.
} 
} Hmm. In this case I think your approach is unfriendly.

Note that I'm assuming that repeated polite requests have failed.  However,
again it's not up to the language designers to decide what is or is not
"friendly."

} I do not consider that a good use of filtering.

That is not a technical reason to leave the capability out of the language.

} I suggest we begin by distinguish between message delivery and
} message acceptance. By doing this we might be able to reach some
} kind of consensus on what we are trying to achieve here.

I don't think there's any disagreement on the terms, merely on when it is
appropriate to refuse.  And those are matters of opinion, not definition.

} My point is that if we use this description as a model, message
} delivery is just about to find the correct maildrop. That makes
} the task of the MTA much less complicated.

The name of this mailing list *is* ietf-mta-filters.  Have we all decided
that we're not talking about MTA-level filtering any more?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

---

From: Tomas Fasth <[email-masked]>
Date: Sat, 02 Nov 1996 22:32:52 +0100

> have to consume the bandwidth to accept the message and then discard it.

I can see your point.

But in order to avoid consuming bandwidth you need to apply the
filtering rules as part of SMTP negotiation. The information
available at that point will limit your filtering rules to operate
on the addresses of the originator and the recipients as negotiated
by MAIL and RCPT, and possibly some peer information.

I presume that you want to apply one set of rules for each recipient,
after first resolving the address for local delivery, but before
the point where the SMTP server have given a response to the RCPT
command. Am I correct?

If this is the case, a rule that resolve into an action other than
a simple "550 command rejected for policy reasons", has to be
postponed until the SMTP session has been completed, including a
"bounce" in the more reply-like fashion, since you need the complete
message or at least the message header section to complete the action.

I can sense an implementation obstacle here.
On the other hand, I have never tried to implement a complete MTA.
So who am I to write on people's noses how to do things? ;-)

-- 
Hälsningar/Regards

Tomas Fasth <[email-masked]>
tel: +46-13-218-181 cel: +46-708-870-957 fax: +46-708-870-258
TwinSpot is a subsidiary of EuroNetics Operation in Sweden

---

From: Tomas Fasth <[email-masked]>
Date: Sat, 02 Nov 1996 22:37:16 +0100

> than an MDN to describe what has occurred.

My opinion is that once the message have been delivered, sending a
DSN would not make sense anymore. Not the least since communication
beyond the point of delivery should be regarded as end-to-end,
between end-users (or their agents). From that perspective, using
MDN seem more appropriate if you want to do any "out-of-band"
communication to the other end.

-- 
Hälsningar/Regards

---

From: Tomas Fasth <[email-masked]>
Date: Sat, 02 Nov 1996 23:10:32 +0100

> associated with each such address.

I did express a feeling more than a fact, I admit that.
And I was relying on my own sense of modular design, which is not
guaranteed to suite any other than myself ;-)

Still, while you can provide a mechanism to allow pre-delivery
filtering to be applied on individual addresses, it seem to me that
this is a very different problem domain compared to when providing
means for a user agent to apply filtering rules on the inbox messages.

Especially when you're applying rules as part of SMTP recipient
negotiation, as you described earlier. In such a context, using Sieve
seem to be a big overkill. Or at least, most of the capabilities in
Sieve seem to be non-applicable.

The probability of applying broken rules as part of MTA operation
seem to be much higher in that context, if you persist in using a
language spec identical to the current draft of Sieve. In that case,
yes, I'm pretty sure it will add a burden to the admin task.

Compare this to a post-delivery senario, where the responsibility
for filtering has shifted from the transport domain to the user
domain. The transport is complete, delivery is successful. The
postmaster don't have to bother about MTA malfunction because of
some obscure set of filtering rules injected by a user. Or the
other way around, he don't have to spend time proof-reading every
set of rules the users want him to inject into the MTA operation.

All this have significance, particularly in larger installations.

-- 
Hälsningar/Regards

---

From: Tomas Fasth <[email-masked]>
Date: Sat, 02 Nov 1996 23:58:44 +0100

> again it's not up to the language designers to decide what is or is not

I can agree that language designers are not in a position to impose
any policies on the end user.

The question still lingers: Does this list have interest in pointing
out certain aspects of the Sieve draft that might not be appropriate
to have included, because of the possibility of being abused, or being
without practical use and therefore leading to confusion?

-- 
Hälsningar/Regards

---

From: Tomas Fasth <[email-masked]>
Date: Sun, 03 Nov 1996 00:10:04 +0100

> appropriate to refuse.  And those are matters of opinion, not definition.

If you are about to design a message filtering language, it seem
essential to determine in what context the filtering is actually
taking place. Depending on the context, some operations, or actions,
may or may not be appropriate.

Therefore, it might be important to define those contexts, which
then might give us technical reasons for whether an action is
appropriate or not. Refuse is one such action in question.

I regard Sieve as a language to be used for a very specific
purpose, and is therefore not a generic language by definition.
We should therefore be very careful not to give it characteristics
that fall outside it's scope of use.

-- 
Hälsningar/Regards

---

From: Tomas Fasth <[email-masked]>
Date: Sun, 03 Nov 1996 02:14:32 +0100

> that we're not talking about MTA-level filtering any more?

Good point. I have been questioning the overall concept of
MTA-level filtering. Which might not be a very good idea on a
list dedicated to the task of doing exactly that. If I have been
out of line here I appologize for that.

Still, I thought it to have been unclear when this MTA-level
filtering was about to take place. Reading one of my earlier
postings in this thread, I recognize my own confusion, mixing it
up with MUA-level filtering. My eager to argue, and therefore
showering this list with several postings on the same subject,
comes partly from my assumption that Sieve was going to be used
in the context of UA-level filtering.

But I seem to have been partly wrong. The Sieve draft states:
"
   Implementations of the language are expected to take place at time of
   final delivery, when the message is finally moved to the user-
   accessible mailbox.  In systems where the MTA does final delivery,
   such as and traditional UNIX mail, is reasonable to sort when the MTA
   deposits mail into the user's mailbox.  If the MTA does not do final
   delivery, or lacks the power to sort into separate mailboxes, as is
   the case under POP3, the MUA must do filtering into local-disk
   folders.
"

It seem to me that the text about an MTA doing a final delivery
is misleading. It might be the case that a monolithically designed
program is performing several tasks, among them SMTP handshake,
message routing, and local delivery. But this is not the same as
saying that the MTA is doing this and that.
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. 
On Unix systems it's sometimes not very easy to recognize the
borders between different components within the mail subsystem.
Still, I would like categorize the mail.local, pop and imap
programs as part of the message store, not the message transport
agent.

You might think I am one of those idealistic OSI guys, but I
ensure you, I'm not. I just like to have some order in the
terminology we are using here.

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.

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

If something good have come out of this thread, it might be the
distiction between SMTP-level filtering, MTA-level filtering and
MUA-level filtering.
The SMTP-level for processing filtering rules prior message
transfer. The MTA-level for processing after message transfer
but before local delivery (or possibly further relaying). The
MUA-level for post-delivery processing.

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?

-- 
Hälsningar/Regards

---

From: Tim Showalter <[email-masked]>
Date: Mon, 3 Nov 1997 17:05:23 -0500 (EST)

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:

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

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

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

> same set of rules are about to run on the MUA-level.

So don't do that.  (This would be a major configuration error.)

> you are about to initiate a bounce.

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

> to fix the cause of rejection).

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

> 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 [email-masked]

---

From: Tomas Fasth <[email-masked]>
Date: Tue, 04 Nov 1997 02:41:40 +0100

> important as the MUA and the MTA, but it's not getting the recognition it

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.

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

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

---

From: Tomas Fasth <[email-masked]>
Date: Tue, 04 Nov 1997 03:22:28 +0100

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

Hmm, would rather say that it makes the applicability clearer for
the implementors. But it depends on how specialized or generic you
want Sieve to be. I think Sieve is enough special to deserve an
explaination in what circumstances it is intended to be used.

> Rationale: I don't understand the difference between MTA and MUA filtering.

I admit, it _is_ confusing.
I have been asserting that there are a difference, of which I have
tried to explain my view on what the differences are. But that does
not mean that I am the one to be right. Therefore, this discussion
helps a lot to put things in perspective.

When you bring up Cyrus as an example of MTA filtering you should
note that although the filtering is typically done by using the
.forward mechanism calling something like procmail, it could just
as well have been done by the deliver(8) program, which is
distributed as part of the cyrus package, which I essentially
regard as a system for message storage.

Personally I regard the POP3 protocol as a a maildrop forwarding
protocol. The end user are therefore restricted to perform post-
delivery filtering only when the maildrop have been forwarded to
where the message store is situated and where access to personal
folders is possible. In the case of a POP client, this is the
same as the local PC (or equivalent).

An interesting question: are POP clients supposed to be able to
generate DSN's? That might put some arguments on it's head. :-)

-- 
Hälsningar/Regards

---

From: Tomas Fasth <[email-masked]>
Date: Tue, 04 Nov 1997 04:08:09 +0100

> (* 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 ;-)

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

> 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

---

From: Tomas Fasth <[email-masked]>
Date: Tue, 04 Nov 1997 04:17:32 +0100

>         * performing a bounce restricts all other actions

I think that if bounce stays in the spec, it should be a terminal
action. That is, no further action allowed on the current message.
Otherwise, you will easily end up in all sorts of more or less
confusing situations. There are considerations to be done when
you want to be conformant to the DSN spec.

> Would making "bounce" optional help?

Yes, that would help a lot. I even want it to be an extension.
By doing that, the ambiguity in it's operation is no longer part
of the base spec.

-- 
Hälsningar/Regards

---

From: Tim Showalter <[email-masked]>
Date: Mon, 3 Nov 1997 22:24:02 -0500 (EST)

Please don't CC me on list messages.  I'm subscribed to the list, and it's a
little annoying.

> explaination in what circumstances it is intended to be used.

I really don't agree with this.  Systems that say, "Don't use this unless
you're in this position" don't get used.  It seems silly.

The major places where this could be used would be an IMAP server, a POP
client, or a Unix system using whatever local mail facilities are availible
(something more sophisticated than, say, Berkley mailspools).

> I admit, it _is_ confusing.

I'd argue that it doesn't exist.  I see no difference between pre-delivery
filtering and post-delivery filtering because I can't see the perceptible,
on-the-wire difference between a filter running at SMTP level as a part of
the SMTP agent and a filter running on the end of a pipe from sendmail.  One
is SMTP, the other just happens to convey the same information and take an
RFC822 format message.

Sieve is designed to filter a message at time of "final delivery", a
deliberately open-ended term concocted to make it clear that it's supposed
to happen just before the message hits the message store, and only happen
once.  I think this is enough.

> generate DSN's? That might put some arguments on it's head. :-)

Why shouldn't they?  They have all the envelope information they need.
If a message can't be given to the user but was delivered to the mail store,
the POP client is probably the only program that knows why.

> and when not?

No, I don't.  Prohibitions against configuring your mailer to do something
dumb are not typically part of protocol documentation.

> from one implementation to another.

Sieve scripts should be portable, and I know of no case where this isn't
true (other than the lack of non-INBOX-like mailboxes if a Sieve script is 
run on a POP server).

> clear, we might end up with a language causing more trouble

Please provide an example.  Bounce isn't it; it's not hard to generate a DSN
given an RFC822 message, which you have anyway.

Sieve was designed to be run on the server when the message is delivered as
part of the MTA.  My definition of MTA is broader than yours; I think the
MTA writes to the mail store, you think the mail store takes the message
from the MTA.

That said, I do not believe that "bounce" represents an ambiguity in Sieve's
role.  MTA, MUA, and other X.400-derived terms are useful for labeling parts
of an Internet mail system, but are not authoritive, or even rigerously
defined, or in the case of many specifications, defined (or used) at all.

Bounce can be implemented easily by any program that can connect to an SMTP
server given an RFC822 message, to the best of my knowledge.

---

From: "Jack De Winter" <[email-masked]>
Date: Tue, 04 Nov 1997 11:40:36 -0500

>(No, I don't really run such a service.  These are examples.)

another example is anyone who owns a mailing list.  I would love to
be able to set up a sieve script that handled legitimate users and
bounce users that are not on the lists.

regards,
Jack
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
(519) 884-4498		http://www.wildbear.on.ca/jacks/

---

From: "Bart Schaefer" <[email-masked]>
Date: Tue, 4 Nov 1997 08:43:07 -0800

On Nov 3,  5:05pm, Tim Showalter wrote:
} Subject: bounce, mta, & mua (was Re: sieve draft)
}
} So that is, for most users.
} 	[a message in Sender MUA]->[Sender MTA]->
} 		[Receiver MTA]->[{something}]->[Receiver MUA]

I believe the model that other IETF groups are aiming for is more like

	[Sender MUA] -> [Submission Agent] ->
	    [chain of zero or more Transport Agents] ->
		[Delivery Agent] -> [Recipient MUA]

There is active work on separating message relay (as happens in the chain
of transport agents) from message submission.

However, I think both the Submission and Delivery agents are legitimately
considered part of the transport system.

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

My desire would be that filtering could be inserted at almost any stage.
If the result of the filter is that the message is going to be rejected
or rerouted, then better to catch it as early as possible before the bits
have crossed the wires.

However, it is true that the farther you get from the recipient MUA, the
less likely the user is to get control over the disposition of messages.
 
} On Sun, 3 Nov 1996, Tomas Fasth wrote:
} 
} Rationale: I don't understand the difference between MTA and MUA filtering.

I see two differences:

1.  An MTA may not have access to all the UA's mailboxes.

2.  An MUA can't reject/reroute at the transport protocol level.

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

The Seive draft is written with the assumption that filtering happens at
delivery time, so that it's already too late for (2).  But (1) remains a
problem:

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

The significant difference is that, even if the envelope sender in the
Return-Path is correct, the POP3 client has no access to the envelope
*recipients*.  In an ideal world, that makes little difference, because
every recipient has his own POP3 maildrop.  In the real world, POP3 drops
are sometimes overloaded to delivery messages to an entire domain, e.g.
as a "replacement" for UUCP.

Of course, there's little the Seive language can do about that, except
to make it easier for the ISP in such situations to provide server-side
filtering.

} Would making "bounce" optional help?

I don't think so.  One could still construct and send a DSN using other
seive tools, so making it optional just makes it more difficult to do
the action, not impossible.

-- 
Bart Schaefer                                                   Zanshin
http://www.well.com/user/barts                   http://www.zanshin.com

---

From: "Jack De Winter" <[email-masked]>
Date: Tue, 04 Nov 1997 11:42:50 -0500

>by MAIL and RCPT, and possibly some peer information.

well, if I remember one of the discussion at the conference in
Memphis right, the problem occured if mail was send to A and B,
where A and B had different sets of filtering rules.  you would
have to accept both of them, and then apply another filtering
after the message duplication had occured.

regards,
Jack

---

From: Tim Showalter <[email-masked]>
Date: Tue, 4 Nov 1997 15:37:43 -0500 (EST)

> 2.  An MUA can't reject/reroute at the transport protocol level.

Ok; I never considered SMTP-level filtering seriously.  Which is why there's
an implicit assumption that the agent has the entire message.

> to make it easier for the ISP in such situations to provide server-side

How do sites like this handle mailing lists, BCCs, and the like?

Should Sieve handle this?  (I don't want to, but should it?)

> the action, not impossible.

OK; I was suggesting this as a policy choice as much as a technichal choice.

---

From: Tim Showalter <[email-masked]>
Date: Tue, 4 Nov 1997 16:22:50 -0500 (EST)

> an implicit assumption that the agent has the entire message.

Er, this is misleading; I'm sorry.  I didn't consider it at all.  Nor do I
wish to dismiss it.  The draft doesn't handle it.

---

From: "Bart Schaefer" <[email-masked]>
Date: Tue, 4 Nov 1997 14:12:46 -0800

On Nov 4,  3:37pm, Tim Showalter wrote:
> Subject: Re: bounce, mta, & mua (was Re: sieve draft)
> > In the real world, POP3 drops
> > are sometimes overloaded to deliver messages to an entire domain, e.g.

Very poorly, if at all.  Some implementations of delivery agents insert
extra information in the message headers, which is then hopefully stripped
out by the POP3 client on the other end.  Eric Raymond, the author of
fetchmail, was asking about this on another ietf list recently; and I
believe Dan Bernstein, author of the qmail-mta, said his MTA already uses
a custom header-field protocol for passing envelope information across
POP3.

---

From: Tomas Fasth <[email-masked]>
Date: Wed, 05 Nov 1997 00:17:26 +0100

> once.  I think this is enough.

Okay. I won't argue about that.

> the POP client is probably the only program that knows why.

Tim, I understand that, with the exception that Return-Path: might
not be available and you may therefore not be able to conform to the
following quote from RFC 1894 chapter 2 page 7 2nd paragraph:
"
   The DSN MUST be addressed (in both the message header and the
   transport envelope) to the return address from the transport envelope
   which accompanied the original message for which the DSN was
   generated.  (For a message that arrived via SMTP, the envelope return
   address appears in the MAIL FROM command.)
"

Anyway, a POP client generating DSN's does not make much sense to me.
The message has already reached it's destination, nothing can be done
to prevent a delivery.

> dumb are not typically part of protocol documentation.

Hmm. You might not want to prohibit.
But you might want to discourage inappropriate usage.

> true (other than the lack of non-INBOX-like mailboxes if a Sieve script is

Okay, I take that back.
I think I ment broken in the sense of doing undesirable actions.

> MTA writes to the mail store, you think the mail store takes the message

So, we have to live with that. I won't push it any further.

> server given an RFC822 message, to the best of my knowledge.

Right. Writing a program is one thing. Giving end users the power of
bouncing is another. This is something that have a potential of
becoming available to millions of users.

And I still don't understand why an end user would want to cause an
automatic bounce. Why is this a desirable action? Your argument seem
to be that it can be technically done, therefore it have to be
provided.

-- 
Hälsningar/Regards

---

From: Tomas Fasth <[email-masked]>
Date: Wed, 05 Nov 1997 00:39:07 +0100

> considered part of the transport system.

Thanks Bart for the clarification. I can accept that model. It seem to
me that [Delivery Agent] is more or less equal to a [Message Store], if
one equals [Recipient MUA] with an IMAP client.

> less likely the user is to get control over the disposition of messages.

Is it reasonable to believe that this could be done in a robust and safe
way? I fear such a dream can easily turn into a nightmare if not
carefully
analysed before implemented.

> } Rationale: I don't understand the difference between MTA and MUA filtering.

Just for the record: I (Tomas Fasth) did not made the qouted statement
above or any of the consecutive qouted statements. I think it was Tim
that made those statements.

-- 
Hälsningar/Regards

---

From: Tomas Fasth <[email-masked]>
Date: Wed, 05 Nov 1997 01:12:59 +0100

> the action, not impossible.

I would suggest to do exactly that. Even make it an extension.
(Oh, I think I already stated that in another mail)
It would give the result you describe above, which I would like
to see happen. Then it might be concieved as a not so normal action,
and might not be as frequently abused by mistake as it might be
otherwise.

-- 
Hälsningar/Regards

---

From: Tim Showalter <[email-masked]>
Date: Wed, 5 Nov 1997 03:51:09 -0500 (EST)

>    address appears in the MAIL FROM command.)

821 says MTAs write the MAIL FROM address into the Return-Path header.
While I can imagine an MTA that violated this, it's unlikely that a site
would want filtering and be unwilling to upgrade to a slightly more
compliant MTA.

> The message has already reached it's destination, nothing can be done

But in what context has it hit its destination?

> But you might want to discourage inappropriate usage.

How?  The only thing I can think of is something that suggests users try
avoiding doing dumb things, and that's rather difficult.

---

From: Tim Showalter <[email-masked]>
Date: Wed, 5 Nov 1997 04:03:05 -0500 (EST)

> analysed before implemented.

Procmail has done a fairly decent job and presents roughly the same dangers,
and I think it has even more potential to shoot users in the feet.  But I
haven't used it, and haven't even looked at the documentation much...

> that made those statements.

I made this statement.

I think bounce (or reject) has utility, although I'd like to hear more
concrete examples.  Bart Schaefer's examples seem valid enough, but I'm
wavering a bit.  I'm inclined to make it optional.