Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt

[Kjetil Torgrim Homme <[e-mail]>]

On Tue, 2005-08-23 at 17:40 -0700, Matthew Elvey wrote:
> Misleading the user into thinking that he's reducing bounces is 
> unacceptable.  I am extremely firmly opposed to any changes that allow 
> refuse and reject to have the exact same results from the users/victim's 
> viewpoint.  The AU's email system is compliant or it isn't.  Saying the 
> system is compliant when just a piece theoretically could be, but when 
> in actual use, the system isn't compliant makes no sense.  It seems 
> we'll have to go for rough consensus, noting this as a point of 
> disagreement.

I don't think we disagree much, really.

A) a Sieve implementation offering "refuse" is compliant if it is able
to reject the message during the submission attempt.

B) the e-mail system which the Sieve implementation is part of, is only
compliant if the same is true for the submission attempt coming from the
remote system.

it should be possible to evaluate a Sieve implementation's compliance to
the specification on its own.  e.g., Cyrus-IMAPD may be compliant even
if it is impossible to make a compliant system with AcmeMTA and
Cyrus-IMAPD together.  this implies that an implementation of the
"refuse" specification MUST allow the administrator to disable the
extension manually.

> Yup.  Holdover from when there was one action defined.  But let's 
> finalize whether we're merging the two actions first..

ah, good.

> This didn't actually get going:
> > FYI: Alexey and I are discussing the hurdles to merging refuse and 
> > reject and other options and will post about this anon. 
> My feelings: I kind of like this proposal (at least the one-action 
> part), but IIRC, we had run into an issue where some folks demanded to 
> be able to send (non ASCII) text that would only fit in an MDN or DSN, 
> it wouldn't fit in an SMTP response code.    So how can we have one 
> action w/o brushing this issue under the rug? 
> 
> Idea: We can say that a bounce is sent instead of a 550 if the 
> characters specified in the reason string aren't compatible with the 
> character set permitted in an SMTP response.  We can be baroque and add 
> another option, but I'd REALLY like to keep the thing as simple as possible.

when combined with "variables", non-ASCII characters from the message
can be captured and included in the reject message.  since this would
happen during runtime, we can't make it fail too badly.  I think we have
only two options:  turn the reject action into a no-op, or send a DSN.
I prefer the no-op option, with the addition that an implementation
SHOULD reject uploaded scripts which employs the "refuse" extension and
contain verbatim non-ASCII characters in the rejection text.
-- 
Kjetil T.