[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WG Last Call: draft-ietf-opes-smtp-use-cases-02.txt
On 7/6/05, Markus Hofmann <markus@xxxxxxxx> wrote:
> 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
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
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  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 .
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
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 Siemborski | PGP:0x5CE32FCC | robsiemb@xxxxxxxxxx
Software Engineer | | 650-623-6925