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.