Re: WG Last Call: draft-ietf-opes-smtp-use-cases-02.txt

Rob Siemborski <[email protected]> Thu, 7 Jul 2005 08:19:43 -0700
Newsgroups gmane.ietf.opes
Message-ID <[email protected]>
On 7/7/05, Martin Stecher <[email protected]> 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    |     [email protected]
Software Engineer     |                       |            650-623-6925