Subject: MSGTRK pre-drafts

From: Eric Allman <[email-masked]>
Date: Tue, 11 Jul 2000 09:55:07 -0700

Enclosed are two "pre-drafts" -- they really aren't up for draft status yet,
but I did want folks here get a glimpse of where they are going.

eric

---

From: Gregory Neil Shapiro <[email-masked]>
Date: Thu, 13 Jul 2000 08:49:24 -0700 (PDT)

eric> Enclosed are two "pre-drafts" -- they really aren't up for draft
eric> status yet, but I did want folks here get a glimpse of where they are
eric> going.

I noticed the documents still use an SMTP verb instead of an external
protocol for querying tracking information.  After the last IETF meeting, I
thought we were looking towards breaking the query out into it's own
service/protocol.

---

From: Eric Allman <[email-masked]>
Date: Thu, 13 Jul 2000 23:51:55 -0700

Erk.  I think you're right.  This never disappeared from my very early
outline, hence my confusion.  Just ignore that portion of the document.

eric

============= In Reply To: ===========================================
: From:  Gregory Neil Shapiro <[email-masked]>
: Subject:  Re: MSGTRK pre-drafts
: Date:  Thu, 13 Jul 2000 08:49:24 -0700 (PDT)

: eric> Enclosed are two "pre-drafts" -- they really aren't up for draft
: eric> status yet, but I did want folks here get a glimpse of where they are
: eric> going.
: 
: I noticed the documents still use an SMTP verb instead of an external
: protocol for querying tracking information.  After the last IETF meeting, I
: thought we were looking towards breaking the query out into it's own
: service/protocol.

---

From: Keith Moore <[email-masked]>
Date: Fri, 14 Jul 2000 14:05:57 -0400

I'd be curious as to the justification for creating a separate 
protocol for message tracking.  to me it doesn't make any sense.

Keith

---

From: Tony Hansen <[email-masked]>
Date: Fri, 28 Jul 2000 09:36:59 -0400

> protocol for message tracking.  to me it doesn't make any sense.

The proposal was made at Adelaide and there was little disagreement in
the room. I agreed to put together a straw proposal for such a protocol.
The question can certainly be brought up again in Pittsburgh. 

Like everything, it has its good points and its bad points. Here are a
few:

Good points:

    can administer message tracking server separately

    can do referrals to another server that is ONLY running MTQP server

Bad points:

    another protocol, another port

    need to administer two servers now instead of just one

	Tony Hansen
	[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Fri, 28 Jul 2000 09:57:03 -0400

>     need to administer two servers now instead of just one

need to keep msgtrk servers in sync with MTAs.

Keith

---

From: Gregory Neil Shapiro <[email-masked]>
Date: Fri, 28 Jul 2000 12:39:04 -0700 (PDT)

tony> Good points:

tony> can administer message tracking server separately
tony> can do referrals to another server that is ONLY running MTQP server

* Off loads the tracking work from the mail server.
* There isn't a one to one match between MTA and tracking server.  For
  example, consider a delivery to example.com which has the DNS records:

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

  The message could go to either server.  When tracking time comes, you
  don't know if the message went to 10.1.1.1 or 10.2.2.2 so holding the
  track server inside the SMTP protocol doesn't gain you anything.  There
  would be one tracking server, that gathers information from both 10.1.1.1
  and 10.2.2.2 in order to answer tracking requests for the name
  "smtp.example.com".

tony> Bad points:

tony> another protocol, another port
tony> need to administer two servers now instead of just one
moore> need to keep msgtrk servers in sync with MTAs.

In response to Keith's bad point, yes, that is true but not a reason to
include it within the SMTP protocol.  That argument would mean that SMTP
should do POP and IMAP as well since the final delivery MTA which handles
local delivery to a mailbox and the POP server which reads mail from a
mailbox must be kept in sync.  Use compatible implementations doesn't
require a single protocol.

---

From: Keith Moore <[email-masked]>
Date: Fri, 28 Jul 2000 20:15:39 -0400

> require a single protocol.

point taken.

Keith

---

From: Gregory Neil Shapiro <[email-masked]>
Date: Sun, 30 Jul 2000 21:57:30 -0700 (PDT)

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.