Re: MSGTRK pre-drafts

gshapiro> * Off loads the tracking work from the mail server.

gshapiro> * There isn't a one to one match between MTA and tracking server.
gshapiro>   For example, consider a delivery to example.com which has the
gshapiro>   DNS records:

gshapiro> example.com.		IN	MX 10	smtp.example.com.
gshapiro> smtp.example.com.	IN	A	10.1.1.1
gshapiro> smtp.example.com.	IN	A	10.2.2.2

gshapiro> The message could go to either server.  When tracking time comes, you
gshapiro> don't know if the message went to 10.1.1.1 or 10.2.2.2 so holding the
gshapiro> track server inside the SMTP protocol doesn't gain you anything.

This point brings up another subtle issue.  When an MUA submits a message
which should be tracked, how does it know which system to contact using
MTQP?  MX and A records may change and the SMTP server isn't necessarily
the MTQP server.

A possible solution:

1. The EHLO "TRACK" reply include the hostname of the MQTP server:

   S: 220 smtp.ietf.org Greetings
   C: EHLO smtp.gshapiro.net
   S: 250-TRACK msgtrk.ietf.org
   S: 250 HELP

   or perhaps:

   S: 250-TRACK SERVER=msgtrk.ietf.org

   or perhaps:

   S: 250-TRACK SERVER=msgtrk1.ietf.org,msgtrk2.ietf.org

   Parameters on the reply could also allow for other information such as
   TTL=7D or something similar to indicate how long the server will be
   holding tracking data.

2. The MQTP protocol should support the ability to refer the client to
   another server in case the MTQP data is moved to another machine or for
   proxying.  This ability is already being researched for the non-chaining
   case but regardless of whether chaining or referrals are used, we need
   the ability for other purposes such as this one.

Ok, time for bed.