Re: New proposal for the interactive message tracking protocol

Sorry, the previous message was accidental!

> > The advantages of this solution are:
> >
> > 1. The same tracking protocol can also be used for other systems than
> > SMTP. It could then provide information about the whereabouts of a message
> > in an X.400 or even a proprietary system. Furthermore there could be
> > information as "fetched through POP3" and so on.
> >
> > 2. The tracking activity is kept away from the e-mail system, so that an
> > SMTP server cannot be saturated with tracking requests by malicious users.

This is good point.

> > 3. It requires only slight changes in SMTP, namely to generate the logs.

In most cases MTA already generate logs. The only change would be to add
records to some sort of temporary message tracking database.
Saying that, it would be simpler to extend SMTP than create new
protocol. Writing to message tracking database would be already in MTA,
so it would be easy in many cases to add querying the database. IMHO,
adding such query command would be as easy as adding support for VRFY
command when server already has RCPT TO:.

> > This prevents us from creating a real monster of a protocol.

Anyway, to leverage existing code it is better if not to extend SMTP,
but at least use SMTP syntax.
Also in Washington it was proposed to use DSN format for the response to
such command.

> > From my point of view the protocol independency mentioned in point 1 is of
> > primary importance, since it increases the quality of the tracking service
> > a lot. The other protocols would only have to create the same kind of log
> > entries, so that the software used for tracking could be remain exactly
> > the same.
> >
> > I am about to build a prototype implementation during my diploma thesis at
> > the Swiss Federal Institute of Technology and I would appreciate to get
> > your opinion on it.
> >
> > Yours sincerely
> >
> > ---
> > Roland Brand
> > Student at Swiss Federal Institute of Technology (ETH)
> > [email protected]