As I've said before:
I strongly support ... requiring that all implementations implement the
ability to do
proper smtp-time (or lmtp-time) protocol-level refusals (other than
MUA-based implementations). It's an important interoperability issue.
Ned responded:
Yes, but the current draft already does this.
I disagree. There is a loophole for an implementer to decide that what he or
she feels is preferred is to not bother fulfilling this requirement. It needs
to be closed.
The latest language suggestion doesn't quite fix the loophole, so I suggest we
clarify by making explicit what Ned states is already implicit. I propose we
add it thus:
"It is REQUIRED that all implementations implement the ability to do
proper SMTP-time (or LMTP-time) protocol-level refusals (other than
MUA-based implementations). It's an important interoperability issue. They SHOULD
use the 550 response code to do so."
This can replace the relatively vague first sentence of 2.1.1.
We should use the latest language suggestion as well:
The ereject action MUST NOT be available in environments that do not
support protocol level rejection, e.g. an MUA, and MUST be available
in all other environments that support the reject action"
I also support the addition of the text Ned proposed:
"the risk that these actions will generate blowback spam are
minimized but cannot be eliminated completely even in the case of ereject, so
caution is advised when using these actions to deal with messages determined to
be spam."
It can go at the end of 2.1.2.
The loophole I described is why I suggested the language I did, including the phrase
"user's choice".
> To the sentence that begins:
> "The Sieve interpreter MUST carry out one of the following actions
> (listed in order from most to least preferred),"
> add something like:
> "MUST support the user's choice to carry out the most preferable action
> possible"
Ned responded:
> I confess I haven't a clue what you mean by "user's choice" in this
context, so I really cannot evaluate it.
I meant that, e.g. if the user wants to do a protocol-level refusal, an
implementation that's not an MUA must support that choice.
I still strongly support requiring a change to the default behaviour,
and feel that there is reluctance to change the current behaviour for
what was presented as nothing more than an unwillingness to explain what
we all agreed were net good reasons for the change.
But this is a compromise. (A change to the default behaviour would make
the draft SIMPLER too.)
Also I propose some changes to newer stuff:
of a message. The refusal should happen as early
should be
of a message. The refusal MUST happen as early
and I don't see why
Script generators SHOULD ensure that a rejection action being
shouldn't be
Script generators MUST ensure that a rejection action being
also, let's change
using the ereject action, as it is more suitable for such rejections.
to
using the ereject action, as reject is unsuitable for such rejections.
also, let's change
support protocol level rejection, e.g. an MUA, and MUST be available
to
support protocol level rejection, i.e. an MUA, and MUST be available
And I'm not clear why this is needed; I don't think it's the case:
(However, the LMTP client may then have no choice
but to generate a DSN to report the error, which may result in
blowback.)
Where it appears to be the case, the LMTP client may just need to be
fixed. If there is indeed such a case, it needs to be specified.
Oh, and the acronyms MDA, MTA and MUA are now used but not defined (as
Mail Delivery, Transfer and User Agents, respectively)
draft-crocker-email-arch-10.txt defines 'em, but it's been an I-D for as
long as this I-D, so I suggest we just spell 'em out on initial use.
-Matthew