On Tue, 10 May 2005, Kartik Gopalan wrote:
DMTP classifies sender MTAs into three categories: allowed, denied, and
unclassified.
So do SMTP servers.
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.
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.
But only after you have wasted someone's time.
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.
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.
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.
The attempt at cryptography in section 3.4 is laughable.
There is no attempt at PKI whatsoever, if that is what you mean.
No, I mean that you are using a cryptographic hash incompetently.
Tony.
--
f.a.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg