--On Tuesday, August 29, 2000 15:50 -0400 Ken Murchison <ken(_at_)oceana(_dot_)com>
wrote:
Chris Newman wrote:
There's an installed base that finds localized 8-bit character sets in
headers useful. That doesn't mean it interoperates or should be blessed
in any way by a standard.
I agree, but for sake of argument, lets assume that Sieve is being used
with an internal MTA which is setup to handle local addresses (no
domain). If someone can send intraoffice mail to "ken", then I need to
be able to put "ken" in the ":addresses" option of my vacation rule.
Likewise, I should be able to do a redirect to "tjs" in this
environment.
I fully understand the scenario, and it's almost identical to the 8-bit
header scenario I mentioned.
I wouldn't setup my environment this way, but I think what Tim is saying
is that Sieve might be used in such an environment and should be locally
adaptable.
We certainly can't stop anyone from doing that if they wish, but neither
should it be standards-compliant syntax.
I don't see where there is an interoperability problem because this
would be a local configuration decision, and the local addresses are
only going to be useful if the corresponding MTA can handle them.
Obviously, these addresses would never see the public network.
Here's the interop problem:
Suppose I make a client to compose and upload Sieve scripts. Either it
refuses to allow unqualified local parts, in which case it interoperates
with everything, except your "local" server. Or it permits them, in which
case whether (and how) it interoperates with a given server is
unpredictable when an unqualified local part is used.
Indeed I think it would be quite useful to have a sieve client which can
test the script locally by running messages through the script. But such a
client couldn't perform a deterministic test unless unqualified local parts
were banned or it had a 100% reliable way to discover what the server would
do with unqualified local parts.
- Chris