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?