Hello,
I think draft-ietf-sieve-refuse-reject-06 implicitly forbids sending
550 after RCPT. In Section 2.1 (Action ereject) the SMTP 550 way is
shifted to Section 2.1.1 (Rejecting a message at the SMTP/LMTP protocol
level) and Section 2.1.1 shifts the problem to Section 2.1.2 (Rejecting
a message by sending a DSN). Or may be I am wrong?
I'm sorry, but you are quite simply wrong about this. First, just because
something isn't discussed doesn't mean it is disalllowed. And section 2.1.2 is
quite clear in stating that it applies to rejections occuring after message
data has been received. That's the only sensible interpretation the phrase "may
receive a message via SMTP" can possibly have. And the text goes on to talk
about the fact that this restriction doesn't apply to LMTP because LMTP has
per-recipient replies after DATA, which only makes sense if we're talking about
responses after message data has been transfererd.
Now, while I think the current text is already quite clear, in order
to forestall further argument I suggest changing the first paragraph
of section 2.1.2 to read:
An implementation may need to respond to the transfer of message
data when more than one RCPT TO has been accepted by the server,
and at least one recipient but not all of are refusing delivery
(whether the refusal is caused by a Sieve "ereject" action or for
some other reason). In this case, the server MUST accept the
message and generate DSNs for all recipients that refused delivery.
Note that this exception does not apply to LMTP, as LMTP is able
to reject messages on a per-recipient basis after message data
has been transferred.
About the spamtest issue: it shall be evaluated after data.
Why? What if the necessary information is already available and nothing in the
message body is capable of overriding it? Why would a ban on early evaluation
of scripts that use spamtest make any more sense than a ban on early evalaution
of scripts that use reject?
If I
remember correctly, there was an idea to extend the envelope test to
check against the sending host (apart from sender and recipient) and
check using external lists if the sending host is blacklisted.
However, no such extension has been defined or even, aside from a passing
mention, discussed.
Then the
mail can be rejected according to the user's preferences and not due the
site policy. Can we leave for now spamtest out the discussion?
Not if what we're talking about is explicit adding text discussing early
evaluation of sieve scripts. In that case I insist that the discussion
encompass the effects of early evaluation on every test and action we have
defined so far. When it comes to implementation methods we either have to
discuss a given approach thoroughly or not at all.
The idea of the early evaluation in multi-recipient messages is to
reduce the amount of generated NDRs, when some of the recipients are
mailboxes (accept spam) and others are mailing lists (who do not want to
discard messages from non list members, ignoring the spaminess). The
problem with NDRs is that they might end in a spamtrap/honeypot and
blacklist your server. With early evaluation all this is avoided...
We're all well aware of these issues.
And
once again: does draft-ietf-sieve-refuse-reject-06 forbid this behaviour?
No.
> FWIW: My sieve interpreter does exactly what we're (not) allowing: I
> fetch the sieve script as part of verifying that the rcpt to address
> exists, and evaluate until some test fails for lack of data. I think
> the draft as it stands is fine.
I think this is wrong, as it does not allow combining keep and reject.
I fail to see anything in this implementation description that would create a
problem for combining keep and reject. And even if it did, since the draft
strongly recommends implementations to forbid this combination (our
implementation definitely does this), I fail to see the point of any of this.
The reject action shall be executed after RCPT TO:, if the script
terminated successfully (= reached <EOF> or stop; without making
header/body tests, or invoking the keep action) being executed there.
This goes much too far - it actually recommends if not requires implementations
implement early evaluation - and I am adamantly opposed to it.
Ned