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

From: Markus Hofmann <[email-masked]>
Date: Wed, 06 Jul 2005 16:44:05 -0400

We are starting WG last call on the "OPES SMTP Use Cases" draft
(see attached). The last call period closes on Wednesday, July 13 at 
5pm EDT. Please post any comments, etc. to the mailing list, and
please point out whether you feel your comment is editorial or a
show-stopper.

Tony already provided (editorial) comments and will provide more small 
nits in separate email, which can be addresses without having to go 
through another WGLC. The suggestion is for Martin to incorporate 
Tony's comments in an updated version. Unless there are other 
comments, we'll then submit this updated version to IESG after WGLC 
closes.

Thanks,
   Markus

Subject: I-D ACTION:draft-ietf-opes-smtp-use-cases-02.txt
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Date: Wed, 06 Jul 2005 15:50:02 -0400
List-Id: <ietf-openproxy.imc.org>

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Open Pluggable Edge Services Working Group of the IETF.

	Title		: OPES SMTP Use Cases
	Author(s)	: A. Barbir, M. Stecher
	Filename	: draft-ietf-opes-smtp-use-cases-02.txt
	Pages		: 16
	Date		: 2005-7-6
	
The Open Pluggable Edge Services (OPES) framework is application
   agnostic.  Application specific adaptations extend that framework.
   This document describes OPES SMTP use cases and deployment scenarios
   in preparation for SMTP adaptation with OPES.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-opes-smtp-use-cases-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-opes-smtp-use-cases-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-opes-smtp-use-cases-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Rob Siemborski <[email-masked]>
Date: Wed, 6 Jul 2005 14:27:15 -0700

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

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

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).  What I do see (in terms of results of the
exchange) are:

a) Modification of the DATA payload
b) Returning an appropriate *response* to a command.
c) Returning metadata (e.g. directory information -- use case 4.7)
d) No return value (e.g. logging only)

Am I missing the case where actual commands are modified?  If not,
then we should reword this paragraph to indicate that these use cases
are only interested in modifying the DATA payload.

-Rob

-- 
Rob Siemborski        |     PGP:0x5CE32FCC    |     [email-masked]
Software Engineer     |                       |            650-623-6925

---

From: SM <[email-masked]>
Date: Wed, 06 Jul 2005 21:23:39 -0700

Hello,
At 13:44 06-07-2005, Markus Hofmann wrote:
>5pm EDT. Please post

In section 3.1.1, the example should be:

A typical (minimum) SMTP dialog between two OPES SMTP processors 
(MTA) will consist of the following (C: means client, S: means server):

S: 220 mail.example.com Sample ESMTP MAIL Service, Version: 1.2 ready 
at Thu, 20 Jan 2005 11:24:40+0100
C: HELO [192.168.0.138]
S: 250 mail.example.com Hello [192.168.0.138]
C: MAIL FROM:<[email-masked]>
S: 250 2.1.0 [email-masked] OK
C: RCPT TO:<[email-masked]>
S: 250 2.1.5 [email-masked]
C: DATA
S: 354 Start mail input; end with "CRLF"."CRLF"
C: From: [email-masked]
C: To: [email-masked]
C: Subject: Test
C:
C: Hi, this is a test!
C: .
S: 250 2.6.0 "[email-masked]" Queued mail for delivery
C: QUIT
S: 221 2.0.0 mail.example.com Service closing transmission channel

The HELO syntax is specified in RFC 2821 Section 4.1.1.1.  The 
address literal was used as no reverse mapping record is available 
for the client.  There is no space after the "MAIL FROM:" and RCPT 
TO:" SMTP commands.

Regards,
-sm

---

From: Markus Hofmann <[email-masked]>
Date: Wed, 13 Jul 2005 17:35:38 -0400

Folks,

thanks for all the comments during the WGLC.

Martin took all your comments and worked them into an updated version 
of the draft. Abbie just submitted this updated version for publication.

Since there ware no showstoppers and no disagreements, we'll submit 
the updated version to IESG for consideration as soon as it hits the 
IETF announcement list.

Thanks,
   Markus

Markus Hofmann wrote:
> (see attached). The last call period closes on Wednesday, July 13 at 5pm 
> EDT. Please post any comments, etc. to the mailing list, and
> through another WGLC. The suggestion is for Martin to incorporate Tony's 
> comments in an updated version. Unless there are other comments, we'll 
> then submit this updated version to IESG after WGLC closes.
> 
> Thanks,
>   Markus
> 
> ------------------------------------------------------------------------
> 
> Subject:
> I-D ACTION:draft-ietf-opes-smtp-use-cases-02.txt
> From:
> [email-masked]
> Date:
> To:
> [email-masked]
> To:
> [email-masked]
> CC:
> [email-masked]