ietf-clear
[Top] [All Lists]

[clear] Sender's Declaration of Identity

2005-06-11 07:40:10
At 05:06 PM 6/10/2005 -0700, Matthew Elvey wrote:

Your scheme doesn't require network traffic, but it does require SMTP 
server software be upgraded.

I've been thinking some more about this problem (the need for SMTP *client* 
software to be upgraded).  Servers (receivers) will need to be upgraded 
immediately regardless of the method.  Clients (senders) will need to be 
upgraded eventually, but for the first year or so, it would be nice if they 
could get by with just conforming to existing standards, e.g. a valid 
hostname in the EHLO command.

With that in mind, I think we could assume a Default Identity (in the 
absence of an explicit Declared Identity).  I can think of two good 
candidates - a) The second-level domain name from the EHLO command, and b) 
A hash of the IP-block(s) associated with the session IP.  The IP blocks 
could be determined by a WHOIS lookup on the session IP.

The requirements for the Default Identity are a) It must be easy to 
determine from existing pre-DATA information in the SMTP session, b) It 
must impose minimum burden on SMTP senders needing to change their setup, 
and c) It must provide a compromise between aggregation and segregation of 
sender's identities.  Aggregation is necessary to reduce the number of 
records we need to keep in our databases and DNS caches.

The second-level EHLO name might be too much aggregation for some large 
domains, e.g. rr.com might prefer to have separate identities for 
austin.rr.com, etc.  The WHOIS lookup might be too little 
aggregation.  rr.com has many IP blocks, and you get only a few of them 
with each query.  Again, the lack of perfection in picking a Default 
Identity is only an interim solution that will go away when all senders 
provide a Declared Identity.

I'm leaning toward the first alternative, but I still need to understand 
all the implications.  What do you think?

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *