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.
Then you really need to provide better evidence that such a loophole exists -
because I'm not seeing it. In this particular case the text you propose
changing currently reads "Sieve implementations that are able to reject
messages at the SMTP/ LMTP level MUST do so and SHOULD use the 550 response
code." So where's the loophole? Any implementation that is invoked by an
SMTP/LMTP server and has the ability to control SMTP statuses is by definition
"able to reject messages ..." and therefore falls under this requirement.
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).
Not only does this not strengthen any requirements over the previous text, it
actually weakens them, since all an implementation now needs to do is claim it
is operating, to use the traditional phrase, "with UA authority' and it is free
to do whatever it pleases because now it has categorized itself as an MUA.
Howver, if this revised language makes you happier about the document I have no
objections to it. However, I must reject the notion it tightens things up. If
anything it does the opposite.
It's an important interoperability issue.
This OTOH, I see as a bit problematic. Since this isn't an interop issue in the
usual sense we think about such things, I find this to be confusing and cannot
support its inclusion.
They SHOULD use the 550 response code to do so."
This is fine, of course.
This can replace the relatively vague first sentence of 2.1.1.
There's nothing vague about it IMO.
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"
As I said previously, I think this is OK.
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.
2.1.2 discusses sending DSNs and is therefore entirely the wrong place for
this. It belongs at the end of 2.1.1, the section talking about SMTP/LMTP level
rejects.
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.
I fail to see continuing to impugn the motives for the position I have taken is
in any way helpful here. But in the interests of keeping this civil I'm not
going to respond further.
But this is a compromise. (A change to the default behaviour would make
the draft SIMPLER too.)
A simpler but unacceptably incompatible change is still not acceptable.
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
This is in the IANA registration, which given that IANA lifts these things out
and puts them in the registry means it is for all intents and purposes a
separate document. I don't think it is in any way apppropriate to use
requirements langauge in this context and therefore oppose making this change.
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
This cannot be a MUST, if for no other reason that such generators could
easily be operating in an MUA content where ereject is not available.
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.
The problem with such claims is that the bar they effectively set is so
high ereject cannot meet them either. I'm therefore opposed to this as well.
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
It is entirely possible for there to be critters in the email universe that act
at the UA level but which aren't thought of as UAs. So what you are doing
actually weakens the requirement by making it sound like it only applies to
MUAs specifically.
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.
Fixed how? Suppose the LMTP client is on an ingress MTA. Messages come
in from the Internet using SMTP and are then sent on using LMTP to affect
final delivery.
Suppose the Sieve implementation is operating as part of the LMTP server. (This
isn't how I'd ever do it, but it is nevertheless a perfectly legitimate
implementation option.) A message comes in via SMTP and is queued for
delivery. The LMTP client sends it to the LMTP server, which then runs
the Sieve which then does an ereject. This is then translated into a
550 LMTP response.
What is the MTA supposed to do now? It has exactly two options available:
(1) Silently discard the message.
(2) Generate a DSN and send it to the MAIL FROM address.
(1) is only appropriate if the MAIL FROM is emoty, NOTIFY=NEVER is in effect,
the MAIL FROM Is somehow known to be forged. That leaves generating a DSN
as the only viable alternative in most cases.
Returning a 550 SMTP response is not possible for the simple reason that the
SMTP connection is long gone - in fact it could have taken place hours or even
days earlier.
I will also note that the behavior of such an MTA, which not only isn't the
agent with the Sieve implementation, it likely will not even be aware that
Sieve is involved, is entirely out of scope for this working group. We cannot
impose requirements here even if we wanted to.
If there is indeed such a case, it needs to be specified.
Specify what? The unfortunate reality is that once a message has been accepted
by an ingress MTA the options for getting rid of it narrow down to
discarding it, with or without sending a notification.
Now, I have long been a proponent of turning away as many messages as possible
while the connection is still there for reporting errors. But neither this
document nor this workging group are the places to make the case for doing
things this way.
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.
I agree the terms need to be defined but the right way to do is is by
referencing the architecture document. The Sieve environment draft did so and
this has not proved to be a barrier to publication.
Ned