ietf-openproxy
[Top] [All Lists]

Draft Minutes from IETF 62

2005-03-22 16:13:37

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


<Prev in Thread] Current Thread [Next in Thread>