On 7/7/05, Martin Stecher <martin(_dot_)stecher(_at_)webwasher(_dot_)com> wrote:
Most of section [3] seems like it could be removed and
replaced with a reference to draft-crocker-email-arch, which
has put a lot of care into addressing these issues.
Instead, this document should focus on just where OPES would
be inserted into the existing architechure
draft-crocker-email-arch is a great document.
As an individual draft that has not yet been published as RFC how
much sense does it make to refer and wait for that?
Dave -- do you have any idea when draft-crocker-email-arch might be
seeing a last call?
However, (and I'm probably missing it) I don't see anywhere
that SMTP commands are modified in any of the use cases
(unless you mean the payload of a DATA command).
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.
-Rob
--
Rob Siemborski | PGP:0x5CE32FCC |
robsiemb(_at_)google(_dot_)com
Software Engineer | | 650-623-6925