Re: e2e
Douglas Otis <dotis@mail-abuse.org> Fri, 17 August 2007 06:45 UTC
Return-path: <ietf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILvan-0003zZ-QZ; Fri, 17 Aug 2007 02:45:57 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILvam-0003zN-19 for ietf@ietf.org; Fri, 17 Aug 2007 02:45:56 -0400
Received: from harry.mail-abuse.org ([168.61.5.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILval-0005a3-B6 for ietf@ietf.org; Fri, 17 Aug 2007 02:45:55 -0400
Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 9062C414CF; Thu, 16 Aug 2007 23:45:54 -0700 (PDT)
In-Reply-To: <46C4CB54.9040403@cs.utk.edu>
References: <198A730C2044DE4A96749D13E167AD3701341995@MOU1WNEXMB04.vcorp.ad.vrsn.com> <8244E3BE-1A26-4B0A-99DC-0DF7AF7F8810@cisco.com> <46C29647.5070202@qualcomm.com> <FABD8E3A-D5CF-4EED-927B-A039BCAEE90C@cisco.com><46C36461.2060907@cs.utk.e du> <46C36599.9040907@cisco.com> <D03E4899F2FB3D4C8464E8C76B3B68B0DBB6F4@E03MVC4-UKBR.domain1.systemhost.ne t> <46C4658E.6030003@cs.utk.edu> <p06240602c2ea243c8fd3@[76.102.94.28]> <D03E4899F2FB3D4C8464E8C76B3B68B0E17BD1@E03MVC4-UKBR.domain1.systemhost.net> <46C4CB54.9040403@cs.utk.edu>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <7F5E2783-218A-45B3-9614-162C6768386D@mail-abuse.org>
Content-Transfer-Encoding: 7bit
From: Douglas Otis <dotis@mail-abuse.org>
Date: Thu, 16 Aug 2007 23:45:51 -0700
To: Keith Moore <moore@cs.utk.edu>
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: ietf@ietf.org
Subject: Re: e2e
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org
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@cs.utk.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@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- e2e John Kristoff
- Re: e2e Scott Brim
- Re: e2e Lixia Zhang
- Re: e2e Noel Chiappa
- RE: e2e Hallam-Baker, Phillip
- Re: e2e Joel Jaeggli
- Re: e2e Steven M. Bellovin
- Re: e2e Brian E Carpenter
- Re: e2e Fred Baker
- Re: e2e Keith Moore
- Re: e2e Fred Baker
- Re: e2e Lakshminath Dondeti
- Re: e2e Michael Thomas
- Re: e2e Keith Moore
- Re: e2e Michael Thomas
- Re: e2e Douglas Otis
- Re: e2e Keith Moore
- Re: e2e Douglas Otis
- Re: e2e Tony Finch
- Re: e2e Iljitsch van Beijnum
- Re: e2e Keith Moore
- Re: e2e Greg Skinner
- RE: e2e michael.dillon
- Re: e2e Gunnar Lindberg
- Re: e2e Keith Moore
- Re: e2e Ted Hardie
- Re: e2e Tony Finch
- Re: e2e Douglas Otis
- RE: e2e SM
- Re: e2e Douglas Otis
- RE: e2e michael.dillon
- RE: e2e michael.dillon
- Re: e2e Keith Moore
- RE: e2e SM
- Re: e2e Douglas Otis
- Re: e2e Iljitsch van Beijnum
- Re: e2e Keith Moore
- New models for email (Re: e2e) John C Klensin
- the curse of the S(imple) protocols, was: Re: e2e Iljitsch van Beijnum
- Re: the curse of the S(imple) protocols, was: Re:… John C Klensin
- Re: the curse of the S(imple) protocols, was: Re:… Steven M. Bellovin
- Re: the curse of the S(imple) protocols, was: Re:… Keith Moore
- Re: the curse of the S(imple) protocols, was: Re:… Henning Schulzrinne
- Re: New models for email (Re: e2e) Douglas Otis
- Re: the curse of the S(imple) protocols, was: Re:… Iljitsch van Beijnum
- Re: the curse of the S(imple) protocols, was: Re:… Steven M. Bellovin
- Re: the curse of the S(imple) protocols, was: Re:… John Levine
- Re: the curse of the S(imple) protocols, was: Re:… John C Klensin
- Re: e2e SM
- Re: the curse of the S(imple) protocols, was: Re:… SM
- Re: the curse of the S(imple) protocols, was: Re:… John C Klensin
- Re: the curse of the S(imple) protocols, was: Re:… Dave Crocker
- Re: the curse of the S(imple) protocols, was: Re:… John C Klensin
- Re: the curse of the S(imple) protocols, was: Re:… Dave Crocker
- Re: the curse of the S(imple) protocols, was: Re:… SM
- RE: New models for email (Re: e2e) Hallam-Baker, Phillip
- RE: e2e Hallam-Baker, Phillip
- Re: New models for email (Re: e2e) Michael Thomas
- RE: New models for email (Re: e2e) John C Klensin
- RE: New models for email (Re: e2e) Hallam-Baker, Phillip
- Re: New models for email (Re: e2e) Dave Crocker
- Re: e2e Fred Baker
- Re: e2e Dave Crocker
- Re: e2e Michael Thomas
- Re: New models for email (Re: e2e) Steven M. Bellovin
- Re: e2e John Day
- Re: New models for email (Re: e2e) Dave Crocker
- RE: New models for email (Re: e2e) Hallam-Baker, Phillip
- Re: New models for email (Re: e2e) Iljitsch van Beijnum
- RE: e2e Hallam-Baker, Phillip
- RE: New models for email (Re: e2e) michael.dillon
- Re: e2e Tony Finch
- Re: e2e Tony Finch
- Re: New models for email (Re: e2e) Tony Finch
- Re: New models for email (Re: e2e) John C Klensin
- Re: New models for email (Re: e2e) Tony Finch
- Re: e2e Keith Moore
- Re: New models for email (Re: e2e) Douglas Otis
- Re: e2e Dave Crocker
- Re: e2e Keith Moore
- Re: New models for email (Re: e2e) Dave Crocker
- Re: New models for email (Re: e2e) SM
- Re: New models for email (Re: e2e) Dave Crocker
- Re: e2e Iljitsch van Beijnum
- Re: e2e Tony Finch
- Re: e2e Keith Moore
- Re: e2e Michael Thomas
- Re: e2e Keith Moore
- Re: e2e Iljitsch van Beijnum
- Re: e2e Keith Moore
- RE: e2e michael.dillon
- Re: e2e John C Klensin
- Re: e2e Iljitsch van Beijnum
- Re: e2e Douglas Otis