On Sun, 2006-07-09 at 17:56 +0100, Alexey Melnikov wrote:
1). “SHOULD be incompatible with other actions” is too strong, for
example there are good reasons to do reject+fileinto.
please state such reasons. I do not think it is a good idea to allow
the recipient system to outright lie about the success of the delivery.
I have to agree with Kjetil here. Of course a user could forge a failure
DSN, but that's no reason to make it easy to lie about the status of email.
Joe-jobs have caused enough damage to the way DSNs work already; we really
should do more.
I tend to agree that reject should be made compatible with other actions
(except for vacation), so I would like to at least downgrade SHOULD to MAY.
2). Non ASCII text in rejection string - should it cause creation of
DSN/MDN, runtime error or stripping of non-ASCII content?
Should we add a tagged argument to control this?
Or maybe we need another capability to enable UTF-8 clean rejection?
that capability needs to be added to SMTP, right?
I would assume UTF-8 error responses in SMTP are somewhere in the EAI
to-do list, but we shouldn't have a dependency on such work here..
I am leaning toward having an extra capability to enable UTF-8 rejection
text over SMTP/LMTP protocol.
fine with me. I don't think Sieve needs to address this point
normatively. the implementation can do its best within the limits of
the current standards.
Agreed.
3). Arnt has requested to allow for reject+redirect to be treated as
just reject. I am not sure I like that. Opinions?
I don't like it either. silently ignoring actions is bad.
Agreed as well.
Ned