Re: New subscriber has questions

Mike Moore wrote:
> I did my Master's thesis in this area (http://moore.gb.com/msc/dissertation.pdf [714Kb]).

Very interesting!  A few comments:

* Section 4.1: Moving Assign Message ID, Publish Message functionality 
and  creating the Message Availability Notification to the originator 
MUA would only really seem to work if either the MUA was running on an 
always-online computer with a static IP address that didn't have 
incoming HTTP connections firewalled, or if the MUA uploaded the message 
to a webserver that met those criteria.  Perhaps originator MTAs could 
eventually be designed that would offload that functionality from the 
originator MUA, originator MUAs could be compatible with either or both 
methods, and we could eventually move to a world with that handled by 
the MTA, since to me at least, that seems a better solution.

* Section 4.2.3: Rather than inspecting the message body to determine 
that it contained a MAN, a MIME type could be specified in the headers a 
la Content-Type: application/x-man :-).  That would have the advantage 
of enabling things like:

MSGID: http://example.com/antone/1234123123412341
Expires: 20100127T14:35+0000 (probably didn't format that right!)
...plus additional extensions as they may be created

* If meta-information for a message is retrieved based on its GUID, all 
a spammer would have to do to avoid having their messages blocked after 
a few people marked it spam would be to send each person a unique GUID. 
It would be easy to construct them in such a way that accessing any of 
them would return the same message, so doing so wouldn't necessarily 
increase storage requirements. This would only require a message store 
either under the spammer's control or implemented in such a way that 
multiple URLs could access the same document (for example, using 
mod_rewrite, custom 404 handler scripts, etc.)

* HTTP server performance would be enhanced if messages could be 
distributed among multiple folders (an issue I don't think you addressed 
one way or the other). For example, if the message ID as 
12345678901234567890, it might be stored at 
http://example.com/antone/12/34/56/78901234567890. By significantly 
reducing the number of messages in each folder, the time required to 
find a particular message would be reduced significantly.  I don't see 
any reason to mandate any particular storage hierarchy (flat or not, 
etc) or GUID length, but of course, strongly recommending a minimum 
length for security purposes would be desirable.

* Perhaps the notion of a redirect notification would be useful in case 
people change ISPs. For example, if my message store used to be located 
under http://example.com/antone/, and I were to move to 
http://example.org/antone.roundy/, I might send notifications to 
recipients of messages not yet deleted from my store telling them where 
to look if they need to retrieve them again. Perhaps such a notification 
could include the URLs of all such messages as a sort of authentication 
(proving that I know not only where the old message store was, but the 
actual URLs of all of the messages in it). For example, (using our 
hypothetical application/x-man MIME type):

Message-Store-Moved: from=http://example.com/antone/ 
to=http://example.org/antone.roundy/
MSGID: 12/34/56/78901234567890
MSGID: 52/15/34/12341234125464
...

* Some method of saying "I've downloaded this and stored it locally, so 
you can delete it from your message store" would be useful. it's 
conceivable that a recipient or an aware recipient MTA might want to 
retrieve or even partially retrieve a message for analysis or previewing 
or something without committing to storing it locally, so just knowing 
that it had been accessed might not be enough. Also, it could be 
retrieved but some error could prevent storage, so it would be best not 
to automatically delete it just because it had been retrieved.

Well, enough for now. I'm surprised to see myself looking so favorably 
at a solution that builds on SMTP rather than trying to replace it!

Antone