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"?
Because the future is unpredictable. Even assuming there's no other action
that's compatible with reject currently (I haven't done any sort of check on
this) that does not mean nothing like that will ever be defined. For that
matter, while the current notify draft doesn't appear to say whether or not it
is compatible with reject, I think a case can be made for allowing it.
More generally, it fairly important that we keep the number of "control"
actions, that is, actions that affect the control flow of scripts, to a minimum
in order to facilitate script analysis.
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.
We've been back and forth over this a lot of times and I do not propose to
repeat those arguments. I suggest you read the list archives to see how/why
we've gotten where we are on this.
I will also add that I personally have no real preferences about any of this. I
simply want a specification I can implement without a lot of trouble. The
current reject/ereject specification looks fairly reasonable to me - my one
quibble is where it says that when UTF-8 Is downgraded to US-ASCII in order to
respond at the SMTP level the user SHOULD be informed. Short of sending the
user a message sauing that this has been done I have no idea how to do that and
I really don't think users will appreciate getting such messages notifying them
of how rejected mail is handled.
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).
A draft which was fairly controversial when it came out, hasn't been discussed
in months AFAIK and is now expired. The odds of this making to an RFC don't
look all that good. And adding support for this to an MTA isn't exactly
trivial, especially on the server side (lack of per-recipient error tracking
and associated code paths). So I'm not optimistic that even if it were
standardized that we'd see significant deployment at all soon.
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.
Which can lead to significant delays in message transfer.
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.
Couple of big problems here. First, since the message-id isn't available before
the message data is transferred you cannot tell which message you're dealing
with until the message body is tranferred, so the second time you still have to
do the "temporary reject all but one" trick. Then you can check and if you've
already figured out the result for this recipient you can then say yes or no.
But this means the message ends up getting transferred once per recipient. You
may have delivered the message to all recipients in a timely way, but you have
lied and said you haven't. This can easily devolve into a situation where the
originatore gets told there's a problem delivering even though the message has
been delivered. And that's really not acceptable.
Additionally, using the message-id as a unique identifier is nowhere near good
enough. It is unfortunately the case that different messages routinely end up
having the same message-id. They don't usually differ by much, but they do
differ and it is important that such duplicates not be eliminated. So in order
for this approach to work you have to compute a hash over the entire message.
And that's actually surprisingly expensive - this is something we have a lot of
experienc with because we do it sometimes for other reasons.
Now, you could try using ENVID instead of message-id if the DSN extension is
being used. This reduces the number of times the message is transferred to at
most two. But once again you're relying on a single identifier - a much more
reliably unique one but still possibly associated with different messages - and
DSN support is unfortunately not really ubiquitous enough.
- 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 is now doing nothing but rehashing past discussions. I suggest you read
the archives.
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.
All in all, I think the users need one action to refuse a mail, how
the refusal works is up to the implementation.
Been there, didn't reach consensus on that.
Ned