Re: Treat as a WGLC: draft-martin-managesieve-10.txt

["Robert Burrell Donkin" <[e-mail]>]

On Mon, Jul 7, 2008 at 9:46 PM, Jeffrey Hutzelman <[e-mail]> wrote:
> --On Monday, July 07, 2008 09:40:11 PM +0100 Robert Burrell Donkin
> <[e-mail]> wrote:
>
>> On Mon, Jul 7, 2008 at 9:23 PM, Jeffrey Hutzelman <[e-mail]> wrote:
>>>
>>> --On Monday, July 07, 2008 08:27:59 PM +0100 Robert Burrell Donkin
>>> <[e-mail]> 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