[Asrg] Re: draft-duan-smtp-receiver-driven-00.txt

This draft is worthless.

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

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.

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.

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 well as being based on a fundamentally useless idea, the details of the
specification are incompetent.

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.

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.

The attempt at cryptography in section 3.4 is laughable.

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg