ietf-smtp
[Top] [All Lists]

Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard

2009-03-05 18:32:28



--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.

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.    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.

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.  But the
basic model hasn't changed even if our terminology for the
boundary machine isn't "enterprise mail gateway" any more (and
maybe if it is).

And, if the boundary/Sieve machine is sitting somewhere at the
boundary between an ISP and the rest of the network, operating
according to rules determined by the ISP and not by the end
user, we've got a classic "middlebox" problem and all of the
(often pointless) debates about who controls it and what that
means, but no real model change: the machine is still acting as
a delivery server with post-delivery SMTP-level resending
functions and doing so on behalf of the target user mailbox,
whether that user likes it or not.

    john

<Prev in Thread] Current Thread [Next in Thread>