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
[email protected] wrote:
>
>> --On Thursday, March 05, 2009 13:05 -0800
>> [email protected] 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
>
