Ned,
No disagreement with anything you say below. My only point was
that the situation is a little ambiguous, that the 5321 text can
be read in different ways, that getting into an "I'm holier than
thou" discussion around the definitions of the standards is not
a particularly productive activity, and that, unless we are
going to retool the protocol specifications and their
definitions in major ways (starting with 5321 but definitely not
limited to it), maybe a little ambiguity is a good thing.
john
--On Thursday, March 05, 2009 15:35 -0800
ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
--On Thursday, March 05, 2009 13:05 -0800
ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
...
That's wasn't Tony's point. His point was that Sieve breaks
the RFC 5321 rule
by allowing scripts to assign whatever semantics they like
to local parts of
external addresses. Sieve can be case-sensitive or
case-insensitive (the latter
is the default) and even has an extension for extracting
subaddress information
from arbitrary addresses.
Ned,
I think whether Sieve is complaint or not depends, as all of
these things traditionally have, on how you model the delivery
process and its relationship to it.
Sieve is specified as occuring around the time of final
delivery. If it is applied just before final delivery, that
puts it in the scope of SMTP.
If I hang Sieve off of a relay in the middle of the network
and then start parsing and interpreting local parts, it would
clearly be non-compliant, but, to a certain extent, that
status is a definitional contradiction: a thing in the middle
of the network with a Sieve processor hanging off of it and
interpreting and acting on local parts (or any of several
other things), isn't a relay any more.
It isn't a conforming sieve implementation either. As such,
while I suppose you could implement such a thing, I see little
point in discussing it.
Whether it is a gateway
between logical spheres of administrative influence, a "final
delivery" SMTP server at the boundary of some domain that has
its own internal mail classification and routing machinery, or
some other sort of odd beast is a separate question --one that
I'm not sure we improve the world by trying to answer-- but it
is definitely not a 5321-conformant relay whether it
interprets those addresses case-independently or not.
And by the same token neither is an autoforwarder that performs
an authorization check on the MAIL FROM address by comparing
it in a case-insensitive way with a authorized address list.
So is this a gateway too? It doesn't meet the definitoin in
RFC 5321 - it's certainy not passing messages between
different transport environments. But let's ignore that for
now. Suppose it is a gateway. You've just reclassified a
significant fraction of the relays out there as being a
gateway. Those are now joined by the ones that apply Sieve
prior to final delivery, agents that employ various sorts of
white and black list technologies, and lots of other stuff.
Travel much further down this path and the pure relays RFC
5321 spends so much time on aren't endangered, they're
essentially extinct.
If the Sieve process is either beyond whatever one considers
to be the final delivery server or is acting, with
authorization, on behalf of that server or a user beyond it,
the 5321 rules are really not being violated.
All of this was a lot more clear when mail was delivered to an
SMTP server at the boundary of an enterprise which then
proceeded to interpret the addresses, rewrite the mail, and
deliver it using mail protocols that didn't work on the
Internet backbone. Those days are, fortunately, long gone.
In fact with the advent of complex webmail systems, one can
argue that these things are more popular than the various LAN
email systems ever were. But that's really a different
discussion for another day.
Ned