ietf-smtp
[Top] [All Lists]

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

2009-03-05 19:02:57

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

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