ietf-mta-filters
[Top] [All Lists]

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

2004-06-08 19:46:45

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.
   sieve3(_at_)matthew(_dot_)elvey(_dot_)com

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
  ken(_at_)oceana(_dot_)com

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:matthew(_at_)elvey(_dot_)com]
Sent: Saturday, May 08, 2004 2:49 PM
To: iana(_at_)iana(_dot_)org
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.

      sieve3(_at_)matthew(_dot_)elvey(_dot_)com


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
   ken(_at_)oceana(_dot_)com


Thanks,
Matthew


---------------
Also, here's an email I sent to Mark M and 
ietf-mta-filters-request(_at_)imc(_dot_)org instead of 
ietf-mta-filters(_at_)imc(_dot_)org:

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.




<Prev in Thread] Current Thread [Next in Thread>
  • "refuse" ; Re: Registration of new Sieve extensions, and changes. (sieve-extensions), Matthew Elvey <=