Tony,
Thank you for the helpful discussions. Let me try to clarify some of
the intuition behind the schemes in the I-D.
DMTP classifies sender MTAs into three categories: allowed, denied, and
unclassified.
So do SMTP servers.
Our comparison above was to IM2000. Indeed the current SMTP servers
know how to handle senders that are denied (blacklisted), or allowed
(whitelisted). A message that falls in neither class is currently
subject to the content filters to decide if it is a spam message or
not. To put it another way, the current SMTP does not have an explicit
concept of unclassified senders. The one we are aware of that supports
the similar concept is Greylisting, which defines unclassified sources
as new triplets that are not in the whitelist and blacklist yet.
However, as other people on this list have pointed out already,
spammers haven't yet adapted to this scheme because it hasn't impacted
their bottomline. This would happen once greylisting becomes
widespread.
The receiver pull model is only used for messages from the unclassified
category.
And this is the category of messages where it is least useful. You are
forcing people to guess whether they want to receive a message before you
have expended any automated effort to classify it.
This really is related to what kind of classification we are talking
about. As one example, the receiver can configure his/her MTA such
that most regular contacts are in the allowed class. As a consequence,
after a brief learning time period, most important messages fall in
the allowed category (that do not need the notification process) and
the receiver pays only infrequent attention to the notifications in
the unclassfied folder. Note that this definition of classification is
different and orthogonal from classifying a message based on its
content. Occasionally, an important message may lie unread for a long
time -- its not desirable but it is not a new problem. It happens even
now with automated content-based classifiers you mention above. You
get false positives all the time even now -- they are either tagged as
[SPAM] to be stored away in a junk folder or (worse yet) deleted
without receiver's knowledge. With DMTP, at least receiver gets to
periodically review the notifications from these unclassified senders
(if receivers so choose to).
You have not addressed the user interface issues of DMTP. How is a user
supposed to decide whether to receive a message given only the sender
address and message ID? You suggest that message IDs should be
cryptographically generated, and therefore meaningless to people, and you
do not address the problem of forged sender addresses. Therefore DMTP's
notification messages are useless to the recipient.
You missed one more piece of information in the notification: a
limited subject header summarizing the contents. You may say that
"well subject can be misleading and sender address can be forged to
make it appear like a regular contact". Its possible and happens with
viruses all the time. But this technique is useless to spammers
because it doesn't help them to send the tremendous volume of
commercial traffic that makes spamming so attractive. Just imagine the
amount of state and association they need to maintain per spammed
receiver to make heavy volume mailing successful with this technique.
Also,
1) Your regular contacts will typically be in the allowed class. If
you see a notification from your regular contact that is in the
unclassified folder, it is easy to tell it is a faked message and you
need not spend time on it.
2) For the other legitimate senders that are not in your allowed
class, how often you hear from them? and how likely is it that a
spammer knows that this is not only your legitimate contact but ALSO
is not in your regular contact class?
You are assuming that each server's idea of its own IP address is the same
as the other TCP endpoint's idea of it. You are assuming that incoming and
outgoing connections to an MTA are symmetrical.
This is a good point and Kartik's email addressed your question to
some extent by mentioning that some MTA modifications are inevitable
to make them DMTP-compliant. As it is in the current draft, the sender
MTA IP address is used for the RMTA to retrieve the complete message.
We made this choice because of security concerns and also for the
simplicity of the RMTA. It is possible that instead of relying on RMTA
to record the SMTA IP address, we can do a DNS MX lookup of sender
email address to get the MTA IP address at the sender side. However,
this indeed means that if sender side uses different MTA servers for
incoming and outgoing messages, they need to be in sync about state of
outgoing message queue (for example, shared file systems). In the long
run, its a tradeoff worth making.
There is no attempt at PKI whatsoever, if that is what you mean.
No, I mean that you are using a cryptographic hash incompetently.
We do not quite see you mentioning a specific concern here. As long as
the sender-side hash serves the purpose, it does not matter how
simple/complicated it is. For example, when you subscribe to a mailing
list, you normally receive a message asking you to confirm the intent
to subscribe. How complicated do you think the method to generate the
random text on the Subject line is?
Thank you,
-Zhenhai