Subject: "refuse" ; Re: Registration of new Sieve extensions, and changes. (sieve-extensions)

From: Matthew Elvey <[email-masked]>
Date: Tue, 08 Jun 2004 19:46:40 -0700

An FYI, and a new post.
-----------
FYI, per an earlier post, I contacted IANA and heard back a month later:

On 6/8/2004 12:47 PM, IANA sent forth electrons to convey:

Matthew,

We have corrected the reference in the sieve-extensions
registry and registered the 2 sieve-extensions mentioned below.

Capability name: refuse
Capability keyword: refuse
Capability arguments: N/A
Standards Track/IESG-approved experimental RFC number:
     [draft-elvey-refuse-sieve-01.txt]
Person and email address to contact for further information:
    Matthew Elvey
    The Elvey Partnership, LLC
    3042 Sacramento-ietf St Ste 04
    San Francisco, CA
    U.S.A.
    [email-masked]

AND

Capability name: regex
Capability keyword: regex
Capability arguments: N/A
Standards Track/IESG-approved experimental RFC number:
    [draft-murchison-sieve-regex-07.txt]
Person and email address to contact for further information:
   Kenneth Murchison
   [email-masked]

Please see: <http://www.iana.org/assignments/sieve-extensions>

Please note:  Extensions designed for interoperable use
SHOULD be defined as standards track or IESG approved
experimental RFCs.

Best regards,

Michelle Cotton
IANA

-----Original Message-----
From: Matthew Elvey [mailto:[email-masked]]
Sent: Saturday, May 08, 2004 2:49 PM
To: [email-masked]
Subject: Registration of new Sieve extensions, and changes.

Hello, and thanks for your public service.

I think
http://www.iana.org/assignments/sieve-extensions needs some updates.

An RFC # (3685) has been associated with spamtest and virustest.
-see http://www.faqs.org/rfcs/rfc3685.html

Please add the RFC #, and add the following entries:

Per
http://www.ietf.org/internet-drafts/draft-elvey-refuse-sieve-01.txt :

   Capability name: refuse
   Capability keyword: refuse
   Capability arguments: N/A
   Standards Track/IESG-approved experimental RFC number:
[RFC-elvey-refuse-sieve-01.txt]
   Person and email address to contact for further information:

       Matthew Elvey
       The Elvey Partnership, LLC
       3042 Sacramento-ietf St Ste 04
       San Francisco, CA
       U.S.A.

       [email-masked]

Per
http://www.ietf.org/internet-drafts/draft-murchison-sieve-regex-07.txt :

    Capability name: regex
    Capability keyword: regex
    Capability arguments: N/A
    Standards Track/IESG-approved experimental RFC number:
[RFC-murchison-sieve-regex-07.txt]
 Person and email address to contact for further information:

    Kenneth Murchison
    [email-masked]

Thanks,
Matthew

---------------
Also, here's an email I sent to Mark M and [email-masked] instead of [email-masked]:

On 6/7/2004 11:19 AM, Matthew Elvey sent forth electrons to convey:

>> I'm suggesting that the spec should be adjusted to allow a best-effort
>> "refuse" with a fallback to another action...
>
>
>
> Please suggest the specific other action you would like it to fallback 
> to; if you don't it's difficult to make progress.
> Is the specific other action bitbucketing?  That is what you were 
> suggesting earlier.
>
>
>> Imagine a
>> change to an SMTP server that makes "refuse" not work- either for
>> a short while, or for the long term.  Neither is hard to imagine.
>>
> Please assume I have no imagination, and provide a specific example, of
>
> "situationally unavailable" which would result in a problem
>
> so we can discuss a specific situation.
> I can't think of such a situation where there would be a resulting 
> problem.
>
> I will respond further to your email, but want to deal with these 
> points first.
>