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.
That doesn't really supply a justification for why a code change would be
worth it.
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?
The MTA I work on (PMDF/SJSMS) has had code to process enhanced status codes in
place for almost a decade. This includes looking at the second and third value
of the status code, althogh to be fair this is only done when gatewaying to
non-SMTP environments. In the SMTP-only world the code is extracted from
responses and copied into DSNs and whatnot, but I don't believe the second and
third values actually control MTA behavior in any way.
I'm fairly confident at least PP does similar things as well - it would have to
in order to support X.400 gatewaying if nothing else.
But examination and use of enhanced status codes is hardly limited to MTAs -
indeed, while MTAs have reason to find and copy these codes around they
generally don't need to look at their values. The same canont be said for
various other agents such as MUAs wanting to localize DSNs or list managers
wanting to automatically process DSNs. I cannot cite an example of a deployed
MUA that does DSN translation but that doesn't mean there aren't any. As for
list managers, I know of at least two that process enhanced status codes.
As for whether or no the specific coes we're talking about here are ones that
implementations would check for and care about, they don't matter to our code
but they may to other implementations.
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.
You're assuming these codes are specified as part of policy settings rather
than there being code to enforce a given policy that returns a hardcoded error
when the policy is violated. We use both approaches in our code and I doubt
very much we're alone in that.
But I suppose you may be talking about anti-spam black boxes.
And all sorts of other stuff.
Ned