On Aug 16, 2007, at 3:10 PM, Keith Moore wrote:
I also think there might be some merit in holding mail on the
sender's outgoing mail server until the receiver's MX is willing to
deal with it, thus pushing more of the costs toward the sender of a
message.
The concept of holding messages at the sender could be a basis for a
change in SMTP for supporting this model, but at a message
granularity. The changes would be similar to that of BURL but would
be Transfer by Reference or To Be Read, TBR.
The results seen after returning 4xx errors to SMTP clients is often
the client will then retry frequently. A better solution would be to
devise an architecture that allows the message reference to always be
accepted, but where actual message delivery occurs over a different
channel. This new mode of operation would occur when both sender and
receiver support an transfer by reference. Often more than 90% of
messages received are undesired. These messages will be either
refused, placed into a junk folder, bounced, or deleted. Many
bounces will be deleted as well. Actually transferring the message
is sub-optimal when done within the SMTP sessions due to extremely
high levels of abuse. Accepting the message rather than a message
reference also burdens the SMTP server with the duty of retaining its
disposition and possibly issuing bounces.
A problem also plaguing email is falsified originating addresses.
This has lead to rampant abuse where virtually little within a
message is trusted as being valid. While DKIM helps solve this
problem, this solution demands additional resources of the
recipient. Whether DKIM will be able to withstand abuse may be in
doubt, after all most email services are gratis. Providers might opt
for a cheaper solution. Transfer by reference ensures the
origination of the message is not falsified at substantially less
cost for the inbound SMTP process.
To implement an transfer by reference, the MSA would create two
hashes based upon the email message content. The MSA then publishes
the email message at a web-server where the combined hashes provide
an access reference for security. Rate-limiting 404 errors makes
attempts at guessing a link futile. If there is a desire to ensure
even those running the recipient's MTA do not have access the
message, a scheme like Open-ID could be employed. When there are
multiple recipients, a script on the web-server could request who is
accessing the message. Identifying who is fetching the message can
also be automated by inserting the recipient's address into the link
as follows:
MSGREF: http://bill%40example.com@xxxxxxxxxx/~moore/.mq/(sha1+sha256)
The web-server would track when an outbound message was posted, and
whether it had been accessed by all intended recipients. The web-
server could generate a report of outstanding recipients that failed
to fetch the message after some interval. The web-server may attempt
to retry sending the link to the recipient, or just notify the sender
of a delivery failure.
Banks or financial institutions could use https to better secure
message content, and to ensure customers they are at the expected web-
site. Any new MUA designed to handle transfer by reference should be
able to annotate whether a publisher had been listed within their
address book. This feature should help avoid look-alike exploits.
Fetch messages from the reference link offers a positive confirmation
of delivery. From a commerce standpoint, this confirmation would be
of significant value. Those concerned about keeping their IP address
private, should utilize an external proxy before accessing the web-
sites.
When an MTA encounters a down-stream MTA or user-agent that does not
support transfer by reference, it could fetch the message to remain
compliant. The cost of handling messages will is likely to be a
primary motivation for transfer by reference, along with secure
content, and a solid confirmation of delivery.
-Doug
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf