Allow me to begin my reply by saying that I've taken on editorship of
this document with the goal of publishing an RFC. The details are not
particularly important to me; for every option there are good arguments.
I'm focusing on making sure that the document itself presents a coherent
set of actions and that it is reasonably well written.
That said...
On Sat, 2007-10-06 at 14:14 +0200, Dilyan Palauzov wrote:
Hello
I am reading currently draft-ietf-sieve-refuse-reject-05 and want to say
some things:
If action reject shall be allowed only once and if it shall not
permit the execution of vacation, why doesn't reject imply action "stop"?
Section 3.3 says,
It is NOT RECOMMENDED that implementations permit the use of
"reject" with actions that cause mail delivery, such as "keep",
"fileinto", "redirect".
There are some circumstances where you might want to write a script like
this:
if whatever {
ereject "No thanks. But I'm keeping this anyways...";
fileinto "No Thanks";
}
IMHO, it would violate the principle of least surprise if the fileinto
failed to execute because ereject had an implicit stop.
More important, I do not get why a user needs both ereject and
reject . If she wants to refuse delivery, she needs one action and how
is it implemented (MDN, smtp 5xx) on the current protocol, does not
matter for her. My suggestion is to unify both reject and ereject in
reject, doing 5xx-reject when possible, otherwise something else. Near
LMTP and SMTP with one recipient, the 5xx reject can be applied in SMTP
with PRDR enabled
(http://www.ehsco.com/misc/I-Ds/draft-hall-prdr-00.txt). If the
environment is SMTP without PRDR, there are still some possibilities:
- accept the mail for the first recipient and all other recipients
that have the same script as the first one. Do temporary reject for all
other recipients. In this way the DATA-dot-response will be the answer
for all accepted recipients. In fact, the implementation can deliver
promptly the mails, save the performed action per recipient and
Message-ID and the next time it is contacted to receive the mails, that
were temporary rejected the first time, the implementation reports to
the connecting MTA if it is going to accept the first-recipient, but
does not deliver again the mail. The only drawback is, that after 24
hours or 4 days or whatever the sender might be notified that her mail
was not delivered yet.
- accept all mail and generate bounces for the undelivered one
If an implementation supports both options, then it is up to the
site administrator to choose which of both policy will be applied - in
some cases bounces might be totally unacceptable and so on. This
adjustment is necessary side-wide and I do not think it needs to be
specified in the sieve-script.
This has gone back and forth several times. Have you looked back on the
mailing list archives? There are good arguments both ways...
With respect to PRDR, I suspect that our references to the ability of
LMTP to reject messages on a per-recipient basis could be applied to
this new SMTP extensions without a specific reference in this document.
Unicode issues: if there will be bounces, then Unicode is not a
problem. If there will be 5xx reject, then ... either the implementation
transliterates the text to ASCII, or the user are given two options to
the reject action, the second optional one giving the reason in ascii
text and applied during smtp negotiations.
There were a number of people who disagreed strongly with changing the
rejection text without some authorization from the user.
All in all, I think the users need one action to refuse a mail, how
the refusal works is up to the implementation.
Greetings,
Dilian