On Mon, 27 Oct 1997, Chris Bartram wrote:
- the "required" flag on rules...
I'm not particularly happy with the way required works out, but it may be
needed; all Internet protocols are required to have an extension mechanism.
I'd like to drop require and rely on support.
I know several *nix implementations will be reading these on-the-fly, and
might benefit from such a flag, but those of us who plan to implement GUIs
where you can't even enter an action or rule that's not valid will have
no use for such a flag...
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.
This is how it's supposed to work. I'm not sure it's good, but it's there.
I recall some of the debate on this earlier, and if the point is more for
"storage" of rules, perhaps to be downloaded to clients on demand, then
I withdraw my protest; though I didn't really get the impression that this
is what this proposal is about.
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.
- more importantly, the "bounce" action.
With regards to spam:
If one removes the bounce action, one must also remove the reply action
which does the same thing in a different context.
The bounce action is not for spam, it's for refusing delivery of a message.
A "bounce", to be effective, needs to take place in the MTA (SMTP Server
process) - refusing the message before it's actually delivered into any
local mailboxes (i.e. as the diagram below:
[snip]
This stops the message before it gets into your queues, and forces the
sender's system to deal with it as an undeliverable message -- using THEIR
resources, not yours.
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.
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.
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.
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?
--
Tim Showalter
tjs(_at_)andrew(_dot_)cmu(_dot_)edu