----- Original Message -----
From: "Tony Finch" <dot(_at_)dotat(_dot_)at>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
Cc: "Kartik Gopalan" <kartik(_dot_)gopalan(_at_)gmail(_dot_)com>; "Tony Finch"
<dot(_at_)dotat(_dot_)at>; <ietf-smtp(_at_)imc(_dot_)org>; "Zhenhai Duan"
"Yingfei Dong" <yingfei(_at_)hawaii(_dot_)edu>
Sent: Tuesday, May 10, 2005 10:51 AM
Subject: Re: draft-duan-smtp-receiver-driven-00.txt
On Tue, 10 May 2005, Hector Santos wrote:
Off hand, I think I see a potential of DMTP becoming a source of
Once the user authorizes the intent, how to you control that a
final body of message with different intent is not delivered?
You could include in the message ID a hash of the message, which the
client can use to verify that the offered message corresponds to the
message that was received.
But this means the message must be received ... or is this part of the
responsibility of the client?
I had a example in my original message. I removed it to reduce the message
length. Let me show it this way. In regards to DMTP, a RMTP issues a MSID
MSID id-hash-includes-msg-hash "SMTP topic"
How would the user know what the body intent is really about? The user
sees this system "post master" message:
From: DMTP PostMaster
To: User Address
Subject: [Auto-Authorized Hash]
We received an unclassified message from:
If you want to to receive this message, simply reply to this DMTP
Besides the ergonomic nuisances behind this, how will a user know any
better? Seems like an interesting message purely based on the topic. Maybe
its an direct email from a person in this mailing list?
So what I am saying is that if DMTP is adopted widely, anonymous spammers
can simply use MSID lines which do not raise a red-flag.
The actual message body can be something entirely different from the topic.
(Note: Adding this feature does not prevent stateless spam servers because
they can still use other information in the opaque part of the message ID
to generate spam consistent with the hash on the fly.)
I think this depends on the hasing algorythm, but I see your point.
Consider also this:
If a client system "purports" compliance with DMTP or with any advanced
extended SMTP logic, then you "got him" exactly where you want him -
In such a movement does occur, then we got better ideas than DMTP to secure
the transaction. :-)
The problem is compliance. No compliance. You are back to square one.
The "greylisting" that is being implement by many is that it works with the
current SMTP flow control concepts. No change required and its based on the
theory that bad systems do not honor the retry response codes. Only good
systems do. If good systems did not, then greylisting would not be used.
Hector Santos, Santronics Software, Inc.