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

From: "Martin Stecher" <[email-masked]>
Date: Thu, 7 Jul 2005 10:37:29 +0200

Rob,

thank you for your feedback 

> >>
>    SMTP is a store and forward protocol.  Current email filtering
>    systems either operate at SMTP time or they operate on 
> messages after
>    reception either on the MTA's queue or by being handed from the MTA
>    to a mail filter and back again.
> <<
> 
> I'm not sure I understand the "handed from the MTA to a mail 
> filter and back again" message filters might take place at a 
> variety of times after reception by the MTA, and not all of 
> them require being "handed back again"
> 
> I suggest rewording as:
> 
> ...either operate during the SMTP exchange or on messages 
> that have already been received, after the SMTP connection 
> has been closed (for example, in an MTA's queue).
> 
> >>

Will do.

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

That draft also decribes SMTP architecture in a certain detail.
The section of this OEPS draft is mainly intended for the OPES group
that so far dealed mainly with HTTP to get a very brief overview and
introduction into SMTP.

> --
> 
> Section 1 states:
> 
> >>
>    This work focuses on SMTP based services that want to 
> modify command
>    values and those that want to block commands by defining an error
>    response that the MTA should send in response to the response it
>    received.  OPES MTA will be involved in SMTP command 
> modification and
>    command satisfaction, analog to request modification and request
>    satisfaction from HTTP [9].
> <<
> 
> 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?

Regards
Martin

---

From: Rob Siemborski <[email-masked]>
Date: Thu, 7 Jul 2005 08:19:43 -0700

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

> 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-masked]
Software Engineer     |                       |            650-623-6925

---

From: Rob Siemborski <[email-masked]>
Date: Thu, 7 Jul 2005 08:36:06 -0700

On 7/7/05, Dave Crocker <[email-masked]> wrote:
> thanks for the prod.  i need to do another revision.
> 
> (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, IMO, close *on the other side* of it.

Indeed.

-Rob

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 7 Jul 2005 12:30:58 -0400

----- Original Message -----
From: "Rob Siemborski" <[email-masked]>

Rob,

[Side note]

Just so you know, this document only recognizes Seive as the official
Internet Email Filtering component.

I specifically argued against this specific usage as there could be any,
what I call "Mail Filter Agent" (MFA) hooked into the system such as OPES
and others in mind which currently operate in the real world (i.e., Spam
Assasin).  But this general point of MFA recognition didn't seem to get
anywhere.

In my opinion, Dave will have to finally recognized the generality of a MFA
and add it to the document, among other things, so that a OPES based MFA can
be recognized.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com