On Mon, 27 Oct 1997, Chris Bartram wrote:
I'd like to drop require and rely on support.
I concur.
Your GUI implementation supports an extension Foo. My server does not.
You use it. My server rejects it as a syntax error. So there is a use for
it.
It might not be suitable to regard a call to an unimplemented extension
as a syntax error. In particular, if one choose to optimize the filtering
for high volume delivery, the script will be parsed and possibly optimized
once at startup but not evaluated until time of delivery later on.
If the unimplemented extension is rejected as a syntax error when parsed,
the whole script would become broken/useless in this environment. On the
other hand, we might instead regard it as a runtime error, and ask our
selves how that would be handled in a nice way. This is what I am aiming
at when I talk about exception handling.
I'm not sure how that would work, but that's not what it's for. It's meant
to be a way of moving the scripts around and tag them with the extensions
that the scripts require.
I'm not sure I understand that requirement.
It seems to me that the kind of problems you are discussing here exists
mainly because there is no effective two-way communication between the
creator and the executor.
Now, your talk about moving scripts around seem to me as a kind of
old fashioned way to communicate between networked devices. As a
matter of fact, I think I put out my neck and ask; why not use a
protocol to communicate filtering rules? Really, think about it,
shouldn't that solve a whole bunch of problems???
If one removes the bounce action, one must also remove the reply action
which does the same thing in a different context.
No. I strongly disagree with this statement.
You are correct in that bounce and reply is very similar in operation
but belong to different contexts. But that is also why I disagree.
A bounce can, per definition, only be done by the mail transport agent.
A reply can only be done by the end user, or on behalf of the end user
but still in the name of the end user.
The key here is the question; who is doing what for whom?
I regard filtering as effectuated on behalf of the local account
targeted for delivery. It is done as part of the delivery process.
From the MTA perspective, the message have been delivered.
It's the delivery agent who now try to figure out how the owner want
his message handled, with help from a sieve script for example.
Now, unwanted messages can simply not be bounced, only dropped or
replied (or forwarded). One reason for not allowing bounce as part
of delivery is the requirement from the network community to have
a reliable global mail transport system.
The bounce action is not for spam, it's for refusing delivery of a message.
I maintain the position that a delivery cannot be refused, only
processed. The delivery process can do many things, but never bounce.
I disagree. This stops the message while in a relay's queues, forcing them
to generate the same failure notification. The difference seems rather
marginal to me.
No, I maintain my opinion that you are wrong here.
The message is no longer in the relay's queue if it has reached a
point where the end user can affect it's processing, by defining a
sieve script for example.
Effectively, this is part of an MTA server process. I intend to have
sendmail run a program to do the filtering, making the filter part of the
MTA. These scripts are only intended to be run on messages once, at the
point where they're filtered into the user's mailbox -- this is close enough
to being part of the MTA for me.
Oh-oh. You are very close to break your MTA's integrity. I cannot stop
you from doing it, only ask you to refrain. If nothing else, you will
sooner or later be flamed by sendmail gurus by doing a thing like this.
You have a logical error in your thinking.
You cannot do filtering on behalf for a specific end user before
you have decided who to deliver the message to. You cannot possibly
know what set of filtering rules to execute before the actual point
of delivery. Once you have decided whom to deliver the message to,
you should accept the fact that the message have moved into another
domain of processing. You can't have it both ways.
To do this kind of refusing, you have to perform rules globally - not
from
any individual's rule-set (unfortunately); as obviously different users
will
have different rules.
I don't understand this. I think you're arguing against yourself.
I ask you to read it more carefully. There is an important point here.
We are not trying to fool you. We want you to understand that you
have a logical error in your thinking.
My proposal would be to drop the "bounce" action, utilizing just the
"drop"/"delete" action instead. Using bounce is going to put a major load
on "friendly" mail systems and will almost never have the desired (though
admirable) effect.
Bounces will never have the desired effect on spam.
Some users will want bounce (and reply); some sites will probably need to
prohibit it. Can I make the draft reflect that?
I strongly advise to drop the bounce action.
The argument is that an end user should not be allowed to cause a
bounce. The reason for that is simple. Bouncing unwanted messages
is an unfriendly action, only causing yet more traffic on the
network. This is something you should avoid to encourage.
--
Tomas Fasth