spf-discuss
[Top] [All Lists]

Re: draft of email security glossary for review

2004-12-27 21:08:32

On Mon, 27 Dec 2004, Alex van den Bogaerdt wrote:

On Mon, Dec 27, 2004 at 02:29:01PM -0800, william(at)elan.net wrote:

As part of website for another project I'm currently working on email 
security
glossary and would like to receive your comments if you see anything wrong 
with text or would have any suggestions for  others terms to be added. The 
current draft text (which is NOT permanent location of this glossary) is at:
  http://www.elan.net/~william/emailsecurity/eglossary.htm

Thank you for your review and suggestions. I actually prefer to minimize 
number of messages, so I'm replying to mulltiple emails in this one.

1. CNAME 
 
  On Mon, 27 Dec 2004, Alex van den Bogaerdt in message 
   <20041227222207(_dot_)GB20937(_at_)alatheia(_dot_)elm(_dot_)net> wrote:
  > I would suggest to use another description for "CNAME".
  > Perhaps something like:
  > 
  > CNAME: a DNS RR pointing to the Canonical ("Real") name of
  >        a certain host, thereby facilitating aliases
  >
  > I think this makes its use more clear.  Perhaps for native
  > speakers, the meaning of "canonical" is clear enough.  For
  > me it's not.

  The description in glossary was:

  CNAME | Canonical Name - A DNS RR that allows to alias one name to another

  I note that "Canonical Name" is official full name while CNAME is actually
  an abbreviation. In all cases when dealing with abbreviation or similar
  term I always put official full name first then "-" and then desciption. 
  Where the term is not an abbreviation there was no initial "name -". 
  Therefore the description for CNAME was
     a DNS RR that allows to alias one name to another
  I have now change somewhat like you have suggested to:
     a DNS RR that is used for listing Canonical ("Real") name of a certain 
     host, this allows to alias one dns name to another. See 
     http://www.dns.net/dnsrd/rr.html and [RFC1035]

2. DNS Domains

  On Mon, 27 Dec 2004, Alex van den Bogaerdt in message 
   <20041227223432(_dot_)GB22505(_at_)alatheia(_dot_)elm(_dot_)net> wrote:
  > You talk about DNS domains as a group of records.  I think this is
  > not correct.
  > In "inmail-backup1.elan.net", this entire name is a DNS domain,
  > so are "inmail-backup2.elan.net" and "inmail-backup3.elan.net".
  > The way you describe it, the domain would be "elan.net".
  > 
  > DNS ZONE has a similar problem.

  DNS domains are in fact groups of HOST records and DOMAIN is something
  that has been delegated within DNS hierarchy (i.e. its what is pointed 
  by NS records). Its another point that for mail and most other protocols 
  what we use are "Fully Qualified Domain Names", i.e. FQDN, which are in 
  fact hosts but we also allow DOMAIN to be an FQDN if it has A or MX 
  records, in fact if I understandard FQDN - this refers to any dns name
  with record other then "NS. In regards to specific examples above I
  do not recognize "inmail-backup1.elan.net" to be a domain because this
  name has not been deligated, I do recognize it as a HOST and FQDN.

  In regards to glossary, I've not changed anything but now added new 
  terms for DNS HOST and DOMAIN and FQDN. I'm not however certain that
  it is possible to describe an exact relation between these terms within
  just a few lines of text so maybe things are even more confusing now.

3. GPG, DNS PTR

  On Mon, 27 Dec 2004, Alex van den Bogaerdt in message 
   <20041227224611(_dot_)GC22505(_at_)alatheia(_dot_)elm(_dot_)net> wrote:
  > Last suggestions:
  > Add GPG, and a pointer to/from PGP
  > Add "PTR" to the "important" list in the DNS description

  GPG has been added (which forced adding separate term for GNU). I do
  suspect that there seem to be too many people who uses GPG as kind of 
  synonym for PGP while in fact GPG is just one implementation of PGP...
  (and as such its not a term in itself or definition of any standard)

  DNS PTR already defined term under"P" (all dns records are defined 
  separately and not together with DNS), I've also added it to list of
  RRs under "DNS RR" term definition, but I have to note that list is
  just examples and not list of "most important dns record types".

4. CID and SID

  On Mon, 27 Dec 2004, Hector Santos in message 
   <001101c4ec6b$97d5e610$6401a8c0(_at_)hdev1> wrote:

  > Off hand with a quick glance, I have a problem with:
  >     CID         Caller-ID - a Microsoft proposal for verification of email
  > sender based.....
  >
  > CID or callerid stands on its on, Microsoft does not own this terminology.
  > Lets end this confusion now. Lets not feed it.
  >
  > Here is the Federal Standard 1073C definition for CallerID
  >
  > caller ID: A network service feature that permits the recipient of an
  > incoming call to determine, even before answering, the number from 
  > which the incoming call is being placed.
  >
  > I believe the more appropiate term for Microsoft proposal is to use 
  > its acryomn, MCEP "Microsot CallerID Email Policy."

  I'm not trying to introduce new definitions and abbreviations rather 
  I'm trying to describe existing ones already in use and I have not seen 
  "MCEP" used where as "CID" and "SID" do appear when referring to those 
  proposals by Microsoft (both of these acronyms have been in use on 
  spf-discuss in fact). I also have to point that what is described in the
  glossary is how the terms are used in email security and related 
   discussions - many of these terms and abbreviations do have other meaning 
  within different industry and only for 2 or 3 did I actually include 
  the 2nd or 3rd meaning (when I thought the term is sometimes used for 
  in email related discussions or when there very strong case of confusion).

  Now as far as CID - I specifically chosen NOT TO list "CallerID" or
  "Caller-ID" as separate terms and only list "CID" - in fact that is
  because I did not believe that Microsoft use of "CallerID" term is 
  approiate and they should not "own" this term. I'm not however aware
  of CID as being a defined or commonly used acronym when for example
  you talk about telephone CallerID and as such this seems ok. 

  So while I really do not see any need to make changes just to make it
  more clear what field these are for, I've added small disclaimer 
  "in email security this refers to" when defining CID and SID in glossary.


-- 
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net