ietf-asrg
[Top] [All Lists]

Classification of solutions and which ones do real-time check (was Re: [Asrg] porkhash: flexible anti-impersonation mail signatures)

2003-04-04 02:13:27
A system which doesn't require either distribution of the secret, or
ready access to the secret by uninvolved parties would seem better.

There is very little we can do if server can not verify what it just got. 
In current email system all information regarding the message is contained 
in the message itself and this is exactly what got us in the situation we 
currently have because spammer can enter whatever he wants and email appears
to be right to the receiving system since it does not do any validation.

There are 3 ways around it (very generalized):
1. Email (or some kind of other property of connection, such as connecting
system name or ip) can have some information that receiving system will 
check (during delivery or shortly afterwards) with another system to 
verify that this is correct. This is direct verification, like porkhash, 
like rmx, like message tracking verification, etc. 
2. Email (or connection property) can be assumed to be correct if certain
parameters match (or even no parameters) such as it contains a S/MIME or 
if name of the server that sent it matches name in "From:", etc. However 
to avoid spammers using valid parameters, a verification would still need 
to be done with some server/service that has "bad parameters list",for 
S/MIME  this would be revocation server. In this category goes also all 
blacklists and similar systems (email assumed right, check with blacklist).
Ther are two subclasses here:
  a. Verification service is external to receiving system and requires check
     through internet at the same time or shortly after email is received.
     All blacklist dns servers go into this category.
  b. Bad parameters list is distributed to each system prior to it receiving
     email and it can then use this list to verify each email at the time
     of delivery but it does not require separate lookup. Example of this
     would be certificate revocation list distributed to all systems.
     Another example of this is your /etc/mail/access file, which is 
     static blacklist which you setup prior to receiving email.
3. Email (or connection property) can be assumed to be bad unless it is 
expected and contains some specific parameter negotiated with receiver 
prior to the email transmission. Example of this are all challenge/response
systems. The benefits of this are, of course, that receiving server already
knows this unique email parameter that it is expecting and does not need 
to do any lookup, but this is done only because it has already negotiated 
this parameter with sender before. Another example of this would be my 
opt-out system, where also a key is somehow provide to sender to be used 
in sending out the message. Also all whitelists go into this category as 
here verification parameter is "From" which is checked against prior made 
lists of good addresses.

Of the above 2b and 3 do not require any lookup during transmission, but 
unfortunetly they all require prior negotiation and generally this may not 
work very well with such a widely used media as email (huge lists of 
good/bad that needs to be ready prior to receiving email).

Also while we're on this subject, the above 1, 2a, 2b, 3 are actually kind 
of attempt to classify solutions (taxonomy), if you notice #1 and #3 are 
example of fail-close system where email is assumed bad unless it contains 
some parameter that system is able to verify. With #2 its fail-open where
email is considered good but is check with some service to see if its actually
bad. On the other hand 1 & 2a are examples of systems that require real-time
check with external service/database during delivery (note that this includes
dns checks) to see if email is good or bad, while 2b and 3 are examples of 
systems where prior to receiving email the particular paramters for the 
email being received are already present on receiving end - so basicly for 
1/2a & 2b/3 we have another on how to classify a solution.

The presence of many of these components that can be used to classify every
solution is why I dislike all taxonomies that have been done so far - they 
are all binary trees and assume some comon top-level property (why any one 
in particular?). The better approach to taxonomy in my view would be to 
create a matrix where on X-axis we can have list of parameters and on 
Y-axis list of solutions. I'd like to create something like this, but
I just done have time...

----
William Leibzon
Elan Communications Inc. 
william(_at_)elan(_dot_)net

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg