Subject: RE: Late comments on the msgtrk documents

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
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.

-----Original Message-----
From: Eric Allman [mailto:[email-masked]]
Sent: Monday, October 15, 2001 5:29 PM
To: Gregory Neil Shapiro
Cc: Vaudreuil, Greg M (Greg); [email-masked]
Subject: Re: Late comments on the msgtrk documents 

Good point, and (as we discussed) in some cases you _can't_ use
your host name, as for example if you get a dynamic name from an
ISP (since it can be re-used you can't guarantee uniqueness of the
LHS).

eric

============= In Reply To: ===========================================
: From:  Gregory Neil Shapiro <[email-masked]>
: Subject:  Re: Late comments on the msgtrk documents 
: Date:  Mon, 15 Oct 2001 15:14:43 -0700

: The text I am referring to in 4.2 is
: 
:           envid-parameter = "ENVID=" unique-envid
:           unique-envid    = local-envid "@" fqhn
:           local-envid     = xtext
:           fqhn            = xtext
: ...
:                                      In most cases, this means setting
:       fqhn to be the fully qualified host name of the system  generat-
:       ing  this  ENVID
: ...
: 
: "In most cases" leaves the door open for it not being required.  The
: document never says what "fqhn" must be.  By my reading of the document,
an
: ENVID of "123@6425ChristieAvenueSuite4000EmeryvilleCA94608USA" is
perfectly
: legal as long as I can guarantee it's uniqueness.

---

From: Eric Allman <[email-masked]>
Date: Mon, 15 Oct 2001 16:57:53 -0700

Interesting idea -- create (locally) the full

	[email-masked]

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-masked]>
: 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.

---

From: Steve Hole <[email-masked]>
Date: Thu, 18 Oct 2001 16:38:58 -0700

> the server discards duplicates.

I would suggest that we make a recommendation that FQDN is a good 
candidate for generating uniqueness.   Further, if the FQDN can't be used 
directly because it is too long, then a SHA1 hash of the FQDN is a 
suitable substitute.   It is further recommended that the application 
create the lhs of the envid such that it conveys uniqueness over a large 
set of possibilities.  The combination is *very* likely to be unique.

If the fqdn can't be used because it is not reliable or doesn't make sense
(the allocated address scenario), then it is left to the application to 
provide unique information. 

Cheers.
---
Steve Hole
Chief Technology Officer -  - Billing and Payment Systems
ACI Worldwide - MessagingDirect
<mailto:[email-masked]>
Phone: 780-424-4922