Dave, Rob,
thanks again for your help in reviewing and your feedback.
[...]
(for each revision, i think it will be the last, but
someone winds up
pointing out a basic deficiency that needs fixing and turns
out to take serious thought.
I think the document gets better each time, but the effort is some
orders of magnitude higher than I had envisioned.)
Thanks, This is one of the reasons that I think the OPES use
case draft should try to reference it rather than rewrite
even a portion of it briefly, since its surprisingly complicated :)
But this OPES draft does not want that the beginner has to study a
"surprisingly complicated" subject.
Section 3 is a three pages brief overview and introduction.
Necessary info to deal with OPES/SMTP and also enough info for this use
cases document and first start.
I cannot find a section in draft-crocker-email-arch that I could refer
to that gives the same kind of brief introduction within very few
pages. We would need to refer to larger sections and probably also
other RFCs to give the same info as in section 3.
[...]
Section 4.7 Mail rerouting and address rewriting ..."or it rewrites
the recipient address"...
This is a modification of an SMTP command, isn't it?
I suppose that's a matter of opinion. The way I read example
4.7 was something more akin to how mail routing works today.
For example, today, an MTA might do an LDAP lookup to
determine the "next hop" of a message. No SMTP commands are
actually modified in this case. I'm not clear why the OPES
case is significantly different than this, except in the OPES
case the lookup happens via an OPES call instead of via LDAP.
(Is there something inherent in OPES that says it has to
modify protocol traffic?)
Once you get to the point where you need to actually modify
smtp commands you're sitting dangerously close to becoming a
proxy server.
Section 4.7 mentions both options. Next hop gateway and
address rewrite.
And this is a use cases draft. I am listing functions that are
performed today and potentially tomorrow (those that we could
think of and have listed before).
The next-hop lookup is an example how to do this and in an OPES
world that function would just move from a direct implementation
within the MTA into a callout server that then contacts the
LDAP server.
But this LDAP could also contain an address rewrite entry.
There are real world examples where this has already been done.
[...]
Perhaps a pedagogical aid is to equate "MTA" to "router".
How would folks feel about a router than changed the destination
IP Address?
For OPES we may better think of a firewall (and actually application
layer firewall) than a router. In almost all scenarios, a callout
server is modifying something.
And picking up your example: In a firewall, NAT is very much changing
destination addresses.
As we are dealing with an application protocol, let's look at an more
OPES familiar HTTP example:
Rewriting an SMTP address is similar to rewriting the HTTP URL.
An OPES processor (HTTP proxy or SMTP gateway) may or may not allow
a callout server to change that destination info.
A callout server can do many things but it is the responsibility of
the OPES processor to validate.
It's up to capabilities, polcies and authorative domains.
I guess we will have time later when talking about the OCP profile
to discuss whether and how this command modification feature is
implemented and what kind of "MUST check" duties are added for the
gateway.
It's not a usecases collection issue, IMO.
Regards
Martin