Re: Late comments on the msgtrk documents

Interesting idea -- create (locally) the full

	[email protected]

which can be arbitrarily long, and then SHA1 it so you get something
manageable.  This would make it fit into the existing definition of
ENVID.  Unfortunately, the failure mode could be nasty, assuming
the server discards duplicates.

One approach might be to say that duplicates are determined on the
(ENVID, MTRK) pair.  There is still a theoretical chance of getting
dups, but I think that's pretty far into theory.

I think sending "extra, bogus, records" to a requester could
reasonably be considered a security problem (information leakage).

eric


============= In Reply To: ===========================================
: From:  "Vaudreuil, Greg M (Greg)" <[email protected]>
: Subject:  RE: Late comments on the msgtrk documents 
: Date:  Mon, 15 Oct 2001 17:36:29 -0600

: 
: OK.  I get it.  But given that FQDNs can be quite long, even without ACE,
: should we not provide some advice about what to do when the suggested envid
: construction rules result in something too long?   How about a secure hash
: of the ENVID?    I guess in general I'd like to downgrade the requirement to
: use FQDN's but ensure that the requirement for globally unique envids are
: very clear.   
: 
: Also, given the presumably tiny risk of non-uniqueness, what is the failure
: mode look like?  Extra, bogus, records to be sorted out by the person
: requesting the trace?  If so, this does not seem too bad given the small
: risk. That is, assuming the trace records have other information to
: distinguish the bogus records, like message sender.  I figure I should be
: able to stand up in court and say "clearly your honor, these are bogus
: records and don't prove that my nasty message was delivered to Mr. Smith".
: 
: Greg V.