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

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

2005-08-23 17:40:27


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?


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