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

[Matthew Elvey <[e-mail]>]

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.
(Mark, have I convinced you? It wasn't clear from your last email.)

On 8/23/05 4:36 PM, Kjetil Torgrim Homme sent forth electrons to convey:
> the document could benefit from some editorial reorganisation. 
> ...
>
> in my opinion, section 3 should be renamed ("Server architecture
> requirements", perhaps) and made a subsection of section 5.
>   
Yup.  Holdover from when there was one action defined.  But let's 
finalize whether we're merging the two actions first...


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.
Good idea?