We need to focus of documenting what a suitable mechanism is rather than
assuming that some specific mechanism will always be used. We can, if we
think
it necessary, define something very specific, but doing so does not obviate
the need to lay down some general requirements.
That's fine with me. Actually, I would welcome a discussion on general
requirements which is not ACAP tainted. Not that I dislike ACAP in
general, but I have some difficulty to view it as the great savior for
all kinds of inter-agent communication either.
Let me take a stab at this and see what I can come up with. I note in passing
that much of this is probably obvious to many if not most participants. This
does not, however, mean we can get away with not writing this stuff down.
First of all, I think its obvious that security is, if not the key issue,
certainly a major issue.
Security breaks down into three things: Authorization, integrity, and
confidentiality
Authorization is obviously a mandatory requirement. It is imperative that
whatever agent adds a script to the delivery service on behalf of a user check
and make sure the script has appropriate authorization credentials to do so.
Failure to do this leaves the door open (again, obviously) to service denial,
mail interception, and mail bombing attacks.
Integrity checks are a trickier matter, especially since protocols like ACAP
(or LDAP, if you prefer) frequently have authentication checks but not
integrity checks. And without integrity checks a sufficiently determined
attacker can intercept or replace a script. This is intrinsicly harder than the
no-authorization situation, in that such attacks have to wait for someone to
submit a script.
I'm seriously tempted to make integrity a SHOULD or even a MUST sort of thing
here. While it is true that we have many protocols where connection stealing
and similar attacks are possible and we aren't doing much about it, I don't
think we're serving the commmunity by creating more of them.
Finally there's confidentiality. This is also tricky. It is tricky because one
of the things people will do with scripts is put passphrases into them as part
of building their own simple routing protocols, e.g. if the word "foobar"
appears on the subject like then direct this material to my cellular connection
which costs $$$. One can in fact argue that because of the potential for
scripts to contain passphrases and the IETF's position on password-in-the-clear
all script transfer must employ confidentiality services.
I personally think this goes too far, and that a MAY or, if pressed, a SHOULD,
would be sufficient. Nevertheless we need to explain that privacy is an issue
because the contents of scripts may contain stuff you don't want other people
to see.
Anyway, this is an attempt to start in on the security issues. This isn't the
only transfer requirement of course, but I think it will suffice to get
discussion started.
Okey, so, a minimum set of error capabilities would at least be
something. We might be lucky, Sieve is a sort of minimalistic language
and as such may limit the amount of possible parsing errors. And I think
a categorized (i.e. not too detailed) status report will suffice.
I agree that this is a possibility. I also think we should recommend that
errors return some amount of context information -- I personally often
find that returning a bit of context is more useful than the error message
itself. (Yes, I know, I sometimes have to deal with really lousy compilers.)
Ned