Re: e2e

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(_dot_)com(_at_)cs(_dot_)utk(_dot_)edu/~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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf