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

["Martin Stecher" <martin.stecher@xxxxxxxxxxxxx>]

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