ietf-mxcomp
[Top] [All Lists]

Giving it some structure

2004-03-04 12:03:23

Hi,

I was thinking about a structure where the different
proposals fit in an which allows to separate the differences. 


In common, we are playing the authorization game. Someone with 
some identity is trying to do something/make use of some resource.
Is he allowed to do?



- What kind of identity? How is it determined? 
  How is authentication done?


  * All proposals so far use the IP address

       + most of them simply use the peer address of the 
         running SMTP connection (getpeername())

       + Microsoft CallerID proposes a method of delayed
         determination by analyzing Received-Lines in MUA.




- Determining the resource/mail address for authorization:


  * Some use the HELO parameter
 
  * Some use the Envelope sender address

  * Some (MS CallerID) analyze the header




- Localizing the authorization record/server

  * Most proposals have an implicit method to simply
    build the DNS suffix from the mail address domain part, 
    e.g.   _lmap.somedomain....

  
  * RMX++ has an explicit DNS query step (A/SRV/opt. TXT)




- Fetching the Auth Record / querying the Auth server


  * RMX, SPF, CallerID,... download authorization record from 
    DNS

  * RMX++ downloads record from HTTP/HTTPS

  * RMX++ passes parameters up to the auth server.
    Those proposals mapping the sender's IP address into the 
    DNS and look for existing A or TXT records can be considered
    as similar (= passing params as part of the query)





- Encoding of the Auth Record/Statement

  * special RR Type (RMX)
  
  * TXT record 

  * A, PTR, MX records

  * XML (MS CallerID, RMX++)

  * simple text, ASN.1,... (RMX++)

  * "Yes"/"No" (RMX++)




- Nature of record/statement

  * static
 
  * dynamic

  * auth server side evaluation





Please comment if anything is missing.


regards
Hadmut


<Prev in Thread] Current Thread [Next in Thread>