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