IETF 48: Message Track WG Meeting Notes

Monday, July 31, 2000
13:00	Message Tracking

	Review current status
	- Want to finish within one or two more IETF meetings
	- Current document includes updates requested in Adelaide
	Model Document
	- Greg and Randy's comments in the mailing list will be addressed
	  in a new, last-call draft
	Message Tracking Report Format
	- MIME message/tracking-status type
	- Steal from DSNs where-ever possible
	- Don't appear to need additional Action: values
	- How to handle referrals/rejections of query
          - In MIME report or in MTQP response
	- Add field "Remote-Tracking-Server:"?
	  - Make it optional
	  - Aversion to storing remote tracking server in tracking database
	  - Therefore MTQP needs to handle requests for all possible
	    resolutions of a Remote-MTA hostname.
	Message Tracking SMTP Extensions
	- TRACK EHLO response
	- Needed to introduce a new truly unique global message identifier
	  - Should be ok
	- MAIL command MTRK= parameter specifies ID and possibly a timeout
	- Change to per-recipient tracking instead of per-message?
	  - Match DSN behavior, move MTRK to RCPT instead of MAIL
	- Need to look at HMAC (MD5 alone of a concat isn't safe, ways to
	  get back the secret).
	  - Tag method used.
	  - Chris volunteers to help with language.
	- Put authenticator information in this document instead of
	  protocol
	- Advertise the TTL for tracking information on system?
	  - Probably not the correct place since MTQP, not SMTP manages
	    this
	Message Tracking Query Protocol
	- Move from part of SMTP to a separate protocol
	  - Pros:
	    - DoS attacks
	    - Can administer server separately
	    - Can do referrals to an MTQP-only sever
	    - Offloads work from SMTP server
	    - No 1-1 match between MTA and MTQP server
	    - Could support tracking beyond foreign MTA gateways
	    - Parallel w/ POP & IMAP for access
	  - Cons:
	    - Another protocol
	    - Another port
	    - Admin two servers instead of one
	    - Need to keep MTQP server in sync with MTAs
	    - IANA considerations
	  - Keep as separate protocol (hum of consensus)
	    - Steve will confirm on list
	 - Commands:
	   - Simple VERB PARAM ... CRLF
	   - Verbs are case insensitive
	   - Verbs defined are:
	     - TRACK
	     - NOOP
	     - QUIT
	     - Add STARTTLS as optional (unanimous hum of consensus)
	 - Positive Responses
	   - Current
	     - Single line: +OK status info CRLF
	     - Multi line: +OK+ status info CRLF
	       - dot stuffed (simpler)
	     -             +OK+ status {count} CRLF
	       - handles complex responses
	   - Need both dot-stuff and count?
	     - Crowd appears to feel dot-stuffing is fine
	 - Negative responses
	   - Current
	     - -TEMP reason CRLF: temporary failure
	     - -ERR reason CRLF: permanent failure
	     - -BAD reason CRLF: protocol error
	   - Desire for hierarchical error codes
	     - Machine readable and extensible
	     - Change to form: "-TEMP" *[ / "..."]
	       - ... is a extensible token
	   - Make clear distinction between -BAD and -ERR
	  - Startup with a positive reply and optional list of
	    capabilities/extensions.
	    - STARTTLS will be the first extension
	    - Have MTQP be listed in greeting (+OK+/MTQP)
	    - Need an immediate referral mechanism
	      - Tony to produce syntax for the next document revision
	      - "-NO+<CRLF>
		 mtqp://tracking.server.fqdn/<CRLF>" (??)
	  - NOOP command
	    - NOOP <CRLF>
	  - QUIT command
	    - QUIT *ws <CRLF>
	    - Crowd requests removal of *ws
	  - TRACK command
	    - ABNF: "TRACK" 1*WS tracking-id 1*WS auth-cookie *WS CRLF
	    - Allow arbitrary WS?
	      - If keep, need to show in example
	    - Drop trailing *WS usage.
	  - Chris volunteers to help with Security Considerations section
	Last time
	  - Tracking at a firewall
	  - Unique message identifier
	  - Authentication review
	    - Chris wrote, will help Eric with more work to be done
	  - What happens if next step doesn't support tracking?
	  - DoS attacks by tracking request saturations
	  - Other security issues
	Summarize action items
	- Combine report format and tracking protocol into one document
	  - But if MIME, need to keep as three documents
	    - Will keep separate
	  - Tony -01 draft
	  - Eric -00 drafts
	  - Deadline: August 30