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 *
************************************************************ *