Re: IM2000 RNASP -- identifying message stores to recipients

JCB> OTOH, SMTP can more easily tie up offending site resources by
JCB> tarpitting incoming SMTP connections, at the SMTP protocol 
JCB> level as well as at the TCP level for each such connection.  

On the gripping hand, the reason for this sort of Judo is that with SMTP-based
Internet mail the malicious sender's end is the client and the protocol is
client-driven.  With, say, MSRAP in IM2000, the protocol is similarly
client-driven but the malicious sender's end is instead the server.  So the
idea simply doesn't apply.

This isn't to say that there aren't places where one _could_ employ
teergrubing in IM2000.  There is one protocol, RNASP (the original subject of
this thread), where the malicious sender's end is the client and the protocol
is client-driven, and one could employ teergrubing there.  There are fewer
round trips per transaction, but the RNASP server could still send response
PDUs with significant amounts of extraneous padding (which would have to be in
a place reserved by a protocol extension) or simply send them really slowly
octet by octet.

Two of the major differences between teergrubing in RNASP and teergrubing in
SMTP are that with RNASP even if the client withstands the Judo, that still
doesn't get the message that he/she wants to be delivered actually delivered;
and that there are other waste-the-attacker's time defenses already in place,
since submitted notifications are deliberately mergeable/discardable by the
server (with or without notice to the client).

JCB> It seems superfluous to demand that an outgoing message store
JCB> also have a domain name, which would imply that every "pull"
JCB> operation require a DNS lookup even when it isn't actually
JCB> needed.

Solutions to this have already been invented.  Every web page fetch (with a
domain name in the URL) over HTTP 1.0 in theory requires a DNS lookup.  This
is ameliorated both by local caching proxy DNS servers that cache the DNS data
and by the ability of the web browser to employ HTTP 1.1 persistent
connections.  The same can be applied to recipient MUAs fetching messages. 
Indeed, MSRAP was designed with the capability for multiple transactions per
session right from the start.

A more compelling argument for preserving the ability to include raw IP
addresses and port numbers in notifications is the "I've got a small
organisation and I don't want to be bothered with DNS service when the machine
on my network running my own private message store has a well known fixed IP
address that I could just plug in directly and use." argument.  Of course, in
such a situation one probably deals with private DNS service for other reasons
(such as for a Microsoft Windows NT 2003 network) already anyway.  So the
argument can often be a weak one.