Before replying to your comments specifically, we'd like to stress
again that, unlike IM2000, DMTP classifies sender MTAs into three
categories: allowed, denied, and unclassified. The receiver pull model
is only used for messages from the unclassified category. Just as
usual, whitelisted senders can send mail using normal SMTP and
blacklisted ones are summarily declined, with no additional overhead.
The fundamental idea that it shares with IM2000 is based on a mis-targeted
optimisation. The main cost of spam is the human time it wastes, whereas
disk space on the recipient servers is very cheap.
DMTP holds the unclassified senders responsible for *managing* their
own outgoing messages. Storage is just one component of this
management. DMTP strongly discourages the current
"fire-forget-and-disappear" behaviour of spammers who now need to
wait (potentially indefinitely) for receivers to retrieve their
messages. This goal can hardly be called a mis-targeted optimization.
Now spammers would face the dilemma: They should online longer if they
want more people to read, on the other hand, the longer they stay
online, the more likely that they will be black listed.
In fact DMTP makes
dealing with poorly-classified email MORE time-consuming than it is
already, because a recipient must deal with a content-free notification
(containing only a forged sender address and a message ID) as well as the
actual message.
DMTP gives solution to the scenario that none of the currently used
anti-spam technologies can satisfactorily handle without receiving the
entire message. DMTP intent messages are used ONLY for unclassified
senders that are neither in receivers MTA's whitelists nor blacklists.
It is only unclassified senders who are treated using the
receiver-pull model. And even to this category you can apply the same
sender-discouragement schemes that are currently being applied -- such
as greylisting, any other challenge-response schemes, etc.
If you enhance notification messages so that they are sufficiently
informative for a recipient to be able to decide whether to retrieve the
bulk message, then spammers will just put the entirety of their payload in
the notification message. This has already occurred with certain kinds of
mobile phone spam.
First, this is inevitable in *ANY* form of communication where you
wish to allow untrusted parties to communicate with you (or to express
their intent to communicate). It is just like when your phone rings
and you can't recognize the caller ID, you either ignore it or pick it
up anyway. If its a wrong number, prank call, or a telemarketer, you
simply hang up. So the problem is not specific to DMTP.
Secondly, DMTP requires a configurable upper limit on the notification
size. It is effective to the extent that it limits the content of SPAM
delivered (just as phone caller ID helps in making an initial
decision). If one wishes, one could place additional restrictions like
not permitting HTML tags in the notification to make spammer's life
more difficult.
When in doubt about the spamminess of a message it is better to receive
the whole thing. This allows the full gamut of classification technology
can be applied to it, so that there is a greater chance of it being
classified before it wastes the time of a person.
One can still apply the whole gamut of classification technologies on
any complete emails in DMTP. Handling intent messages for a small
unclassified category of senders will not be too much of trouble. This
can even be implemented as transparently as retrieving the complete
message when *and only when* the receiver issues the open command on
the intent message at his/her MUA (again simply like deciding whether
to press talk/ignore upon receiving a caller-ID on the phone).
IM2000 and DMTP are also based on an incorrect assumption, that spam
messages actually cost space on the senders disks. Most spam software is
stateless, and it can continue to be in IM2000 or DMTP: the spammer just
encodes enough information in the message ID in order to be able to
reconstruct the message when it is requested.
As mentioned earlier, the primary goal is to discourage the
"fire-forget-and-disappear" behaviour that the current sender-push
model of SMTP encourages. Storage overhead is only one small part of
the picture. The bigger advantage is that spammer MTA needs to be up
and running for potentially indefinite duration if it wants the
receiver to read the entire message. In any event, storage becomes one
less problem for the receiver to deal with even if the spammer does
the kind of encoding you mention above.
It fails to use the SMTP extension model correctly. A client indicates
that it wishes to use an extension by using a command from the extenstion
or a MAIL or RCPT parameter, NOT by appending a keyword to its EHLO
command. It shows a misunderstanding of the difference between the SMTP
envelope and the message header. It has inexplicable colons in its command
names, in contradiction to SMTP's requirement that commands are
alphabetic.
The above is more a issue of syntax than of content and can be easily
addressed. We have noticed this issue already and are fixing it in our
next draft. As mentioned in the initial post, being new to IETF
process we appreciate such feedback.
It makes assumptions about IP routeing which compromise the usability of
DMTP with highly scaled MTA clusters, which often involve NAT and/or
multi-homed servers.
There is no assumption about IP routing anywhere in the draft. It is
true if you mean making MTA clusters DMTP-compliant would require
changes depending on nature of the cluster. However these are fairly
simple and straightforward changes. Also note that DMTP-compliant MTAs
can interoperate with non-DMTP-compliant legacy MTAs, whether latter
is a scalable cluster or standalone MTA. If the latter is whitelisted
with the former, the transaction is same as regular SMTP. If the
latter is unclassified, it is subject to sender-discouragement
mechanisms at the same cost as today.
The attempt at cryptography in section 3.4 is laughable.
There is no attempt at PKI whatsoever, if that is what you mean. The
terminology may be similar and can be easily clarified. If you read
that section carefully, the sole purpose of the related paragraph is
to make the mapping between a message id and a message itself less
guessable, and to speedup the lookup of the message when the message
id is presented. Moreover, as stated in the section, this is just one
of possible design choices. Different schemes can be deployed by
different MTAs, as long as it achieves the above purpose, given that
this is really a local matter at the sending MTAs.
- Kartik
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg