ietf-mta-filters
[Top] [All Lists]

Re: sieve draft

1997-10-31 19:02:50
Tim wrote:

The bounce action is not for spam, it's for refusing delivery of a message.

What other than spam would be a subject for delivery refusal?
Before you answer, remember that delivery refusal is not the same
as bounce, and that bounce almost always cost network resources
outside your own domain.

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.

Are you not mixing up filtering with screening?
A thing that a MTA would want to do is to screen unwanted traffic.
But that kind of processing should only use information that is
available as part of the protocol itself, not the data it is
transporting. At this level CPU time is a delicate resource and
message parsing should be avoided by all means. A good example
of why is the "denial of service" type of attacks.

Bounces will never have the desired effect on spam.

You are right, simply because spam should always be dropped
silently to minimize use of resources. But then, what other
reason is there to bounce a message once it has been dispatched
for delivery?

I can understand that spam screening should be done at MTA
level if possible. But isn't it more of a function based on
statistical information at the protocol level, rather than
information extracted from the actual message? And if so,
in what way does a scripting language like Sieve improve that
particular kind of processing?

Some users will want bounce (and reply); some sites will probably need to
prohibit it.  Can I make the draft reflect that?

I would like to see some examples on why a user would want to bounce
a message before reflecting such a behavior in the draft.

Actually, can you give examples of any other filtering tools that
allow a bounce action that is distinguishable from a reply action?
I'm not sure you can, you know...

--
Tomas Fasth

<Prev in Thread] Current Thread [Next in Thread>