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.