On Mon, Jul 7, 2008 at 9:46 PM, Jeffrey Hutzelman <jhutz(_at_)cmu(_dot_)edu>
wrote:
--On Monday, July 07, 2008 09:40:11 PM +0100 Robert Burrell Donkin
<robertburrelldonkin(_at_)gmail(_dot_)com> wrote:
On Mon, Jul 7, 2008 at 9:23 PM, Jeffrey Hutzelman <jhutz(_at_)cmu(_dot_)edu>
wrote:
--On Monday, July 07, 2008 08:27:59 PM +0100 Robert Burrell Donkin
<robertburrelldonkin(_at_)gmail(_dot_)com> wrote:
<snip>
it seems unfortunate that this means that a separate port is required
for sieve management. a compatible extension to IMAP would allow sieve
management using the same URI.
That makes the assumption that sieve scripts live only in IMAP servers,
which I don't think we want to do.
not at all :-)
the function contained in this protocol is really very trivial. i
doubt that any implementator using a storage mechanism other than IMAP
would bother creating an implementation rather than just reusing their
preferred protocol at the application level. for example, HTTP is a
well known protocol whose secruity characterics are know well
understood. sieve maintainance using RESTful HTTP would be much
simpler than creating an implementations of this novel protocol.
Only if you have a web server and a bunch of related infrastructure lying
around.
HTTP serving libraries of reasonable quality are common
If you're implementing sieve support in an MTA, such that admins or
even user can provide sieve scripts to be run as incoming mail is being
accepted (rather than waiting until it hits the mail store), then you may
not have the luxury of requiring people who want to use the new feature to
run web servers on their inbound MX's.
opening a new port with a new protocol with unknown and untested
security characteristics sounds unlikely to fly to me. system admins
are much more likely to want to use FTP or HTTP for out-of-protocol
communication (but this is drifting OT)
Now, I don't claim to be such an implementor, but I don't believe that HTTP
is the answer to all protocol problems any more than HTML is the answer to
all user interface problems.
IMO there are very good reasons why HTTP as a protocol has become
dominant (but that's drifting OT)
- robert