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

Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h - Request for feedback on Open Issues.

2004-03-13 22:04:13


First of all, thanks to all for all the feedback so far.

Alexey and I didn't receive any feedback on Section 13 'Open Issues for
Discussion', items 2 or 3, so I'm sending this email to
ask folks (who may have missed it because it was at the end after the
boring boilerplate) to comment.

I note in passing that item 2 only appears in the -01 revision on your
web site - people looking at the -00 revision in the I-D directory
may be confused when they only find two open issues, not three.

Regarding item 2 -

  2) Should the following text be added to the draft? (Section 4.? ?)
Systems that support the extension must encourage use (by their
  users) of "refuse" over "discard" and "reject" where it is an
  appropriate alternative.

I'm not entirely sure what it means to "encourage use", but I guess it could
refer to offering refuse actions preferentially in a GUI or something similar.
If so, I regard this as a somewhat dangerous promotion of nonportable scripts,
since refuse as presently constituted is an MTA-only sort of thing.

The real problem here has nothing to do with sieve and everything to do with
the architecture of email itself: For a variety of reasons the most effective
way to deal with spam is to reject it at the SMTP level prior to final
delivery, but an MUA by definition operates after that point. So even if
you "fix" the portability "problem" you do not and cannot get the desired
behavior on an MUA.

The logical direction this leads is that sieves are best run on MTAs just
before or during final delivery. But do we really want to say this? Perhaps
it would make sense to say it in a BCP talking about spam filtering best
practices, but not, I think, in a technical specification of a sieve
extension.

And regarding item 3 -

  3) Explicitly supporting Enhanced Error Codes (RFC 2034).
The suggested text talking about how to generate an appropriate enhanced error
code is definitely appropriate and should IMO be included in the document. The
broader question of whether or not it is appropriate to give users control over
what code is inserted is the interesting one here. After thinking about this
I've concluded that the benefits just don't outweigh the risks - there really
aren't that many other codes that would be appropriate to use with refuse. If
this were to be supported at all there would have to be a list of the codes a
user is allowed to specify, and anything else would be ignored.

This is a shame, because there are a few other codes that make some amount of
sense, e.g. 5.2.3, "message length exceeds administrative limit". There are
even some 4.x.y codes that make sense, e.g. 4.4.4, "unable to route", when,
say, a presence check fails and an urgent message needs to be returned
immediately. (Note that this last case is one where a 5xy 4.a.b sort of
response indicating "message returned due to a transient problem" may be
appropriate - one of the things done in the revision of the NOTARY document when
they moved to draft was to make it clear such combinations are allowed.)

                                Ned


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