[Top] [All Lists]

Re: I-D ACTION:draft-ietf-sieve-refuse-reject-05.txt

2007-10-06 13:39:14

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:

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

    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 
( 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.