Folks,
attached the draft minutes from our meeting at IETF 62. Thanks to
Philip for taking the minutes, and thanks to Tony for taking care of
the Jabber.
In case you've comments, please provide them by Thursday, 3/24, 5pm
(EST), so that we can forward the minutes to the IETF in a timely manner.
Thanks,
Markus
------
OPES WG Meeting, March 8, 2004; Minneapolis, MN, USA; IETF 62
-------------------------------------------------------------
- agenda bashing
- status, milestones
- discussion of SMTP use cases
- next steps
- WG status
- 7 RFCs published
- one in rfc editor queue
- one AD followup
- one I-D being worked on: smtp-use-cases
- goal to finish with next 1-2 weeks
- milestones
- falling behind on OPES rules language
- ditto on SMTP uses cases
- cannot start OCP/SMTP profile until use cases done
- SMTP use cases (presented by Paul Knight)
- as always, more input, especially substantive, would be good
- overview of draft and OPES use
- desire to provide interoperability
- desire to use callout servers with different app. protocols
- for SMTP, OPES is focused on (hanging off) the MTA
- Philip: pointer to Crocker's arch doc should be used/added
- Randy: are intermediate MTAs truly appropriate?
- Newman: yes: enterprises need to do filtering at their gateways
- Rob: don't bother flagging as sane; each site may need to
make its own guarantees
- Keith Moore: need tracing info; extreme care in all
modifications; multiple modifications are likely to interact
poorly
- Markus: tracing will be addressed according to IAB
considerations
- activation points
- look appropriate
- as SMTP server
- as SMTP client
- look inappropriate
- on queued mail
- but it really is appropriate as there is an envelope
context and there are reasons to scan messages in the queue
- as SMTP proxy
- SMTP callout modes
- command modification
- command satisfaction (catch request and supply reply)
- reply modification
- message modification
- use cases
- three groups:
- command modification
- some similar to HTTP use cases (RFC 3752)
- virus scanning, spam filtering, verify S/MIME signatures
- command satisfaction
- logging or validating MAIL FROM or RCPT TO addresses
- OPES mail delivery side effects
- reject a message whose content violates a possible trigger
condition
- delay a message, change queues
- generate additional notification messages
- modifications
- callout servers need more context
- Newman, Moore: modifying protocol as wrong model
consent issues on changes
- Freed: interest in modifying parameters to commands
(change DSN parameters)
- use cases may preclude each other
- where are the administrative boundaries
- goal: message modifications need to move as close to sender
as they have the most information
- ...but you can't cross boundaries
- milter as model/example
- Open issues:
- can't treat satisfaction as modification, as some commands
change state
- legal restrictions on modification?
- responsibility moves at acceptance
- if called post-acceptance, how to reflect back into the SMTP
world
- monkeying with signed messages causes problems
- Moore: 822 model as permitting additions to headers, but not
modifications to content; and the IETF does not bless the
evil already done by SMTP servers
- timeout prevention methods?
- trust issues?
- IAB considerations, privacy considerations, etc
- Discussion:
- Moore: OPES should be closed down: SMTP work not driven by
people who know SMTP
- Freed: need to start with _useful_ use cases, got to winnow down
your scope
- Moore: no problem with that
- Markus: Need to re-focus use cases document to discuss specific
scenarios; helps setting the scope
- Guenther: current document is list of tools for attacking
problems; should start with use cases and figure out needed
tools from there