On Sat, Aug 04, 2007 at 07:25:14PM -0400, John C Klensin wrote:
--On Saturday, 04 August, 2007 19:09 -0400 Jeff Macdonald
<jmacdonald(_at_)e-dialog(_dot_)com> wrote:
...
John and Ned, you both mentioned 'worth the effort'. Is that
because you both believe the RFC wouldn't be an "Independent
Submission"? I'm very new to this whole process, so forgive me
if this is a stupid question.
It is certainly not a stupid question. The question (at least
my version -- Ned might have a different one) is whether it
would be worth the trouble for existing server implementations
to change their code
I've viewed policy as something that is site specific. Therefore it
makes sense that policy is configurable by an administrator. At least
that is the case for me. I use a MTA with a custom sieve
implementation.
and existing client implementations to adapt to the new sub series.
I'm not aware of any MTAs that pay attention to extended SMTP codes.
Could you supply some examples?
<snip>
So the question is whether this change would have enough value
to tell the community that they should go change things and
whether the implementer community would believe it has enough
value to be worth the trouble to make those changes. I have my
doubts about both.
Depends on which communities we are talking about. I don't think there
needs to be any server changes. It simple a new set of codes for
administrators to use when they set their policies.
But I suppose you may be talking about anti-spam black boxes.
Compared to either of those questions, the cost of pushing a
relatively short and clear document through the IETF system is
fairly low although I would discourage you from trying unless
you think the answers to those questions would be "yes, enough
implementers would believe this is worthwhile to do it if the
spec were written and approved".
I do. Thanks again.
--
:: Jeff Macdonald | Principal Engineer, Messaging Technologies
:: e-Dialog | jmacdonald(_at_)e-dialog(_dot_)com
:: 131 Hartwell Ave. | Lexington, MA 02421
:: v: 781-372-1922 | f: 781-863-8118
:: www.e-dialog.com