On 7/6/05, Markus Hofmann <markus(_at_)mhof(_dot_)com> 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
closes.
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 |
robsiemb(_at_)google(_dot_)com
Software Engineer | | 650-623-6925