Mark E. Mallett wrote:
3. Discussion of finer points
The "refuse" action MUST refuse to accept an email for delivery at
the SMTP/LMTP level by returning a 5XX reply code, instead of
sending an MDN as required by the "reject" action, other than for
the two exceptions specified below. A SIEVE implementation that
cannot do so MUST NOT claim to support the refuse extension.
This means that scripts have to be written with awareness of the site's
email delivery architecture, and if that architecture changes, all
scripts have to change. I think this is a big burden on both script
writers and site admins. Even if approach is to have separate "reject"
and "refuse" verbs, I'd like to see some way of avoiding this burden.
There is an exception when a message has multiple valid recipients,
and at least one but not all of them are refusing delivery (whether
the refusal is caused by execution of a Sieve "refuse" or for
another reason). In this case, the server MUST accept the message
and generate DSNs for all recipients that are refusing it.
I get what this is saying, but I don't think this is said exactly right.
An SMTP server can issue 4xx deferal codes for some of the valid
recipients. This can be done for various reasons, e.g. if some of the
valid recipients are over quota, or if the SMTP server is using a trick
to allow it to do post-DATA rejection by only focusing on one recipient
at a time (I don't know if anybody actually does this, but I've heard it
proposed..). So it's really "when more than one RCPT TO has been
accepted" instead of "when a message has multiple valid recipients."
(picky, I know.)
That is exactly what Matthew and I were trying to say, but your
suggested text is much clearer. Thanks.
4.2 "reject" compatibility with other actions
Implementations MUST prohibit more than one reject in a SIEVE
script.
must prohibit "the execution of..." (certainly more than one reject can
appear in a script).
Yes. Fixed.
5.1 Action refuse
The "refuse" action refuses delivery of a message by sending back
the 550 SMTP response code to an SMTP client.
This extension can be only supported by a Sieve implementation
running in an MTA.
The way this is worded, an implementation that communicates with an MTA
via LMTP (or any other protocol or mechanism, for that matter) is
prohibited from using "refuse." There are multiple ways that an MDA may
be invoked by an MTA during the SMTP dialog, where refusal can be
communicated back to the SMTP client. The MTA itself isn't necessarily
(and probably isn't likely to be) running the Sieve script itself.
The current copy we are editing says "running in an MTA or MDA". Does
this address your concern?
The intent was certainly to allow for MDA.
Regarding MTA/MDA executing Sieve directly versa an external process
MTA/MDA is talking to: I certainly would want to allow for both, as this
is an implementation detail. So do you think "running in an MTA or MDA"
can be interpreted to mean that an external process is not allowed?
How should we make the clear?
And actually I am not sure that LMTP needs to be mentioned in the
document at all, other than as an example of one of the ways that an MTA
and an MDA might communicate during the SMTP dialog. The important thing
is that the Sieve script is being run at SMTP time and its results are
somehow used by the MTA to respond to the SMTP client.
I actually disagree. The sieve engine I am working on runs in LMTP
server, it is the one that has to implement refuse.
This extension can only be supported by a Sieve implementation
that is invoked on behalf of the MTA during SMTP time, and that
can communicate its results to the MTA which can then return a
status to the SMTP client.
Another somewhat thorny point is that a Sieve script may be invoked at
the time when the SMTP server sees the "RCPT TO" so that the refusal may
be communicated to the SMTP client at that time (before DATA). At this
stage, various Sieve facilities (e.g. header tests, fileinto, keep) are
not available. I don't know whether this has to be mentioned in this
draft, but once you have "refuse" capability, this does come into play.
Running Sieve scripts before message headers/body are available is
certainly possible and not prohibited by the draft.
However I think this is somewhat outside the scope for the document, as
this is effectively a different Sieve profile.
Example:
require ["refuse", "spamtest"]
the missing comparator was already mentioned, but it also needs
"fileinto" for the elsif to work.
if spamtest :value "ge" :comparator "i;ascii-numeric" "6" {
refuse text:
SpamAssassin thinks the message is spam.
It is therefore being refused.
Please call 1-900-PAY-US if you want to reach us.
.
;
add "}" here.
Both fixed, thanks.
elsif spamtest :value "ge" :comparator "i;ascii-numeric" "4" {
fileinto "Suspect";
}