[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [iesg-secretary #5857] proposed addition to RFC 2821
Your request #5857 was resolved by jhargest:
IESG: FYI
>>>>>>>>>>>>>>>>>> Original Message >>>>>>>>>>>>>>>>>>
>From: John C Klensin <klensin@jck.com>
>To: Bob Reilly <breil1@attbi.com>
>Subject: RE: proposed addition to RFC 2821
--On Friday, 07 March, 2003 12:21 -0800 Bob Reilly
<breil1@attbi.com> wrote:
> John-
>
> Sorry, I forget that a .pdf is Microsoft-centric (I did the
> same thing to Ned Freed). Following is the Whitepaper in text
> format. By the way, is there a UNIX counterpart to the Adobe
> PDF format?
PDF is not a problem, and there are Unix-based readers (and
generators) for PDF. You sent the thing inside a TNEF
attachment.
> Your issue with the 'prior art' from RFC 821 is interesting
> and was certainly considered when I applied for the patent.
> Additionally, RFC 821 was specifically examined by the patent
> office for prior art concerning my patent and no conflict was
> noted. I think it is all explained in the Whitepaper but I
> want to clearly state that there is NO prior art regarding my
> patent.
I am not comfortable commenting on this at this time. However,
the focus in SMTP and its predecessors is on the SMTP-receiver
("server") identifying the new address, along with the local
delivery failure, to the client. If I correctly interpret your
white paper (after _very_ quick skimming), your intent is to
have the client machine perform some sort of lookup and mail
redirection after it receives a "no mailbox here" reply from the
server. That sort of activity wouldn't significantly impact
2821 or its successors: that document is focused on the SMTP
interactions between client and server in the mail transfer
process.
Instead, you'd be talking about what would be, for the IETF, a
new protocol, presumably one into which an old email address
went in and a new email address came out. You could certainly
write such a thing up and submit it to the ADs (Ned, Patrik, and
Ted) for comment on whether they would be interested in
proceeding with standardization. My own experience predicts
that, unless the requirement for the function is overwhelming,
the IETF is unlikely to touch anything for which the only
implementations possible require the use of a patented
technology for which you intend to charge a license fee.
Nothing said above should be construed as a statement on my part
that there is no prior art for a client-side lookup mechanism
that is triggered by delivery failure response, nor even that I
am unaware of such prior art. But, if 821 is all you looked at,
you not only did not look very hard, but, given that it shares
the orientation toward a dialogue between a mail transfer client
and server with 2821, you perhaps weren't even looking in the
right place.
Vis-a-vis your repeated comments about your being self-funded,
so am I and so, these days, are a number of other very active
participants in the IETF processes who are giving of their
efforts and making their results and thinking available without
charges or formal licensing procedures. This is obviously a
matter of personal taste and choice, but you should not expect
your independence from major sources of support to get you any
special sympathy.
regards,
john
> I am now looking at RFC 2026. It would appear that Section
> 10.3.2 would apply to my process. I originally invented this
> process as a complement to the SMTP process and plan to allow
> anyone (as a licensee) to implement, use and distribute the
> technology, with the sole proviso that all queries would be
> directed to the Mail Registry forwarding address server, i.e.,
> lookup.themailregistry.com. Additionally, my current software
> development is conceived as an open-source project, hence it
> will be easily available for anyone to implement.
>
> I do hope this is not a problem as I have no intention of
> placing the patent into public domain, but the service really
> should be available to everyone. And, not to sound too
> strident, I am funded by myself alone - I am not a tenured
> professor nor am I employed by a large corporation. Fair
> compensation is all I ask.
>
> thanks again
>
> bob reilly
>
> White Paper
>
> Automatic E-mail Forwarding
> U.S. Patent No, 6,427,164
> As implemented by Mail Registry, Inc.
>
>
>
> By: Robert Reilly
> Chief Technology Officer
> Mail Registry, Inc.
> breil@themailregistry.com
>
>
> History & Prior Art
>
> Internet e-mail started with the Request for Comments (RFC)
> 821, "Simple Mail Transfer Protocol", written by J. Postel,
> USC/Information Sciences Institute, August 1982, and RFC 822,
> "Standard for the Format of ARPA Internet Text Messages",
> written by D. Crocker, UDEL, August 1982.
>
> Essentially, RFC 821 defines the "addressing standards" and
> RFC 822 defines the "contents" (although it is also correct to
> say that Internet e-mail according to these RFC's is more of a
> "postcard" than a "letter").
>
> Prior to our patent, RFC 821 provided for the return of an
> e-mail that, for various reasons, could not be delivered to
> the intended recipient.
>
> Examples of the non-delivery error codes from RFC 821 and
> their English meanings:
> 550 Requested action not taken: mailbox unavailable
> [E.g., mailbox not found, no access]
> 551 User not local; please try . . .
> 552 Requested mail action aborted: exceeded storage
> allocation 553 Requested action not taken: mailbox
> name not allowed [E.g., mailbox syntax incorrect]
> 554 Transaction failed
>
> Forwarding was contemplated, as seen:
>
> 3.2. FORWARDING
> There are some cases where the destination information in the
> is incorrect, but the receiver-SMTP knows the correct
> destination. In such cases, one of the following replies
> should be used to allow the sender to contact the correct
> destination.
>
> 251 User not local; will forward to . . .
> This reply indicates that the receiver-SMTP knows
> the user's mailbox is on another host and
> indicates the correct forward-path to use in the
> future. Note that either the host or user or both
> may be different. The receiver takes
> responsibility for delivering the message. 551 User
> not local; please try . . .
> This reply indicates that the receiver-SMTP knows
> the user's mailbox is on another host and
> indicates the correct forward-path to use. Note
> that either the host or user or both may be
> different. The receiver refuses to accept mail
> for this user, and the sender must either redirect the mail
> according to the information provided or return an error
> response to the originating user.
>
> Example 2 illustrates the use of these responses.
>
> -------------------------------------------------------------
> Example of Forwarding
> Either
> S: RCPT TO:
> R: 251 User not local; will forward to . . .
> Or
> S: RCPT TO:
> R: 551 User not local; please try . . .
> Example 2
>
> -------------------------------------------------------------
>
>
>
> However, it's plain to see that RFC 821 does not even approach
> our patented process.
> In January, 1996, RFC 1891, "SMTP Service Extension for
> Delivery Status Notifications", was promulgated. It defines
> the Delivery Status Notifications (DSN) as error text messages
> in addition to the numeric codes above.
>
> For example, an SMTP reply of:
>
> 550-mailbox unavailable
> 550 user has moved with no forwarding address
>
> could appear as follows in a Diagnostic-Code DSN field:
>
> Diagnostic-Code: smtp ; 550-mailbox unavailable
> 550 user has moved with no forwarding address
>
>
> The Reply Codes were expanded in RFC 1893, "Enhanced Mail
> System Status Codes", by adding "Status Codes", however, the
> structure of the Reply Codes was retained and Permanent
> failures are still represented by the 5.X.X logic. This
> schema is quite extensive and is not included herein.
> Additionally, RFC 1869, "SMTP Service Extensions", RFC 1894,
> "An Extensible Message Format for Delivery Status
> Notifications", and RFC 2034, "SMTP Service Extension for
> Returning Enhanced Error Codes" all add to the complexity of
> non-delivery error reporting.
>
> At this point, it is sufficient to note that our patented
> process will utilize all of these code structures to determine
> the non-delivery status the e-mail encountered.
> The Patented Technology
>
> From the beginning, and up to this moment - Internet e-mail is
> seriously inefficient. It was designed to decentralize e-mail
> so much that each Internet e-mail server is essentially a
> "national" post office. Every time e-mail is sent to another
> domain, the user's e-mail server parses the domain name (the
> part after the @ sign in user@domain.com) from the recipient's
> e-mail address, queries its designated Domain Name Service
> (DNS) for the Internet Protocol (IP) address of the domain's
> mail server, and then contacts the receiving e-mail server
> directly. The sending and receiving process is complicated
> and slow, as the servers each say "hello" and the sending
> server announces that it has mail for a particular user (the
> name before the @ sign). If and when the receiving server
> says "ok", the mail is sent. If the receiving server doesn't
> say "ok", it can be for a variety of reasons, such as "there
> is no user here by that name" or "the user's mailbox is full",
> etc. The receiving server then sends a Non-Delivery Report
> (NDR) to the sending server, and the process ends without
> delivering the mail or attempting to resolve the problem.
> Forwarding of e-mail, 'automatic' or manual, does exist and
> was defined in the original Internet documentation (ibid).
> However, manual forwarding requires significant administrative
> or user intervention in the case of a user leaving the e-mail
> domain or in the case of the user merely wishing to re-send
> the e-mail to another address (e.g., the Unix "dot-forward"
> file). Pseudo-automatic forwarding, as is currently done by
> companies like Trueswitch.com and Re-route.com, requires the
> cooperation of the former ISP . The 'automatic' forwarding
> used by many e-mail servers exists only within the domain and
> also requires user or administrative access to enable. There
> is nothing truly automatic nor elegant about existing e-mail
> forwarding.
>
> The Way It Works
> Our patent provides for the automatic delivery of e-mail that
> has been returned (bounced) with a non-delivery notice (NDR)
> from the receiving e-mail server, providing that the address
> was correct at one time but the account is now inactive or for
> any other reason not accepting e-mail. Unlike other approaches
> to this situation, our patent employs a protocol-oriented
> process to correctly forward this e-mail and requires only
> that the intended recipient register his/her new address with
> Mail Registry.
>
> The following explains the patent claims in easier terms.
>
> The way it works now
>
> a. A sender ("Joe") sends an e-mail to a friend ("Bill"). In
> Joe's address book, Bill's e-mail address is Bill@ZXY.COM.
>
> b. Unknown to Joe, Bill has changed ISP's and is now at
> ABC.COM - Bill@ABC.COM.
>
> c. Joe's e-mail server (at his ISP) tries to send the e-mail
> to Bill. However, after the two servers connect, Bill's server
> says "Error - Bill isn 't here and I don't know where he is".
> This is called a Non-Delivery Report (NDR) and actually looks
> like "550" or "5.3.0".
>
> d. Joe's server receives the NDR and has no alternative but to
> put a message in Joe's inbox stating something like "Mail
> System Error - Returned Mail". Joe opens this message and
> reads something like:
>
> This Message was undeliverable due to the following reason:
>
> Each of the following recipients was rejected by a remote mail
> server. The reasons given by the server are included to help
> you determine why each recipient was rejected.
>
> Recipient: <bill@xyz.com>
> Reason: 5.3.0 < bill@xyz.com >... Addressee unknown
>
> Please reply to Postmaster@xyz.com if you feel this message to
> be in error.
>
>
> e. Joe now has to call Bill for his new e-mail address or
> possibly search through several hundred "directory service"
> websites to see if Bill registered a new address somewhere.
>
> Our basic claim-
>
> a. A sender ("Joe") sends an e-mail to a friend ("Bill"). In
> Joe's address book, Bill's e-mail address is Bill@ZXY.COM.
>
> b. Unknown to Joe, Bill has changed ISP's and is now at
> ABC.COM - Bill@ABC.COM. However, Bill has registered his new
> e-mail address with theMailRegistry.com
>
> c. Joe's e-mail server (at his ISP) tries to send the e-mail
> to Bill. However, after the two servers connect, Bill's server
> determines that Bill's address no longer exists in its
> database.
>
> d. Bill's e-mail server, which has the Mail Registry agent
> installed, now queries the Mail Registry Central Database (the
> "forwarding address server" in our patent) and asks "I have
> undeliverable e-mail for Bill@XYZ.COM. Is there a new address
> corresponding to this old address?"
>
> e. TheMailRegistry.com responds with an affirmative answer and
> supplies Bill 's new address to Bill's e-mail server. (There
> are parts of this 'conversation" between the two e-mail
> servers that guarantee privacy and authenticity, covered later
> in this paper)
>
> f. Bill's e-mail server now resends Joe's e-mail to
> Bill@ABC.COM and it is successfully received.
>
> ===============================================
>
>
> -----Original Message-----
> From: John C Klensin [mailto:klensin@jck.com]
> Sent: Friday, March 07, 2003 11:56 AM
> To: breil@themailregistry.com
> Cc: paf@cisco.com; Ned Freed; Ted.Hardie@nominum.com;
> iesgf-secretary@ietf.org
> Subject: Re: proposed addition to RFC 2821
>
>
> Bob,
>
> I am copying the current and incoming IETF Area Directors for
> Applications and the IESG Secretary, to make certain that there
> is a record of your note and my response.
>
> I will not (the procedures might be read to imply "cannot")
> discuss your suggestion at all until and unless you have made
> the IPR disclosures to the Secretariat and the IETF required by
> RFC 2026, section 10.
>
> Also, if you attached a whitepaper, it arrived in "MS-TNEF"
> format. That format is proprietary to certain Microsoft mail
> systems. I have no practical way to decode it and, given the
> history of such attachments carrying worms and viruses, I would
> not decode it if I could. If you want people around IETF to
> pay attention to your papers, I would suggest that you adopt an
> industry-standard, non-proprietary, format.
>
> I will, however, note that the current text of RFC 2821 that
> permits finding a new address and rerouting mail is adapted
> from RFC 821, which was, in turn, adapted from earlier
> documents and, indeed, from common and general practice in the
> fairly early days of email usage on the ARPANet. I would need
> to do some research to reconstruct the applicable dates, but,
> if my memory is correct, replies of the variety of "wrong
> address, please use..." and "wrong address, mail forward to
> ..., please update your records" date from around 1972 or 1973
> or earlier. If your patent claims invention and ownership and
> all techniques for determining a new address and rerouting
> email, I trust it predates those practices.
>
> regards,
> John Klensin
>
>
> --On Friday, 07 March, 2003 10:46 -0800 Bob Reilly
> <breil@themailregistry.com> wrote:
>
>> John C. Klensin
>> Dear Sir-
>> Just finished perusing your latest draft of RFC-2821, Simple
>> Mail Transfer Protocol.
>> Especially interesting to me is Section 3.4, in which you
>> write: * Servers MAY reject or bounce messages when they are
>> not deliverable when addressed. When they do so, they MAY
>> either provide address-updating information with a 551 code,
>> or may reject the message as undeliverable with a 550 code and
>> no address-specific information. But, if a 551 code is used,
>> they MUST NOT assume that the client will actually update
>> address information or even return that information to the
>> user. might I suggest adding the following text after this
>> paragraph:
>>
>> *Servers MAY attempt to determine if there is a new e-mail
>> address for messages that are not deliverable as addressed.
>> This process is patented by Mail Registry, Inc. and requires
>> that certain software developed by Mail Registry, Inc. be
>> installed on the server. When the server determines that the
>> original message address is not deliverable and the Mail
>> Registry software has been correctly installed, the server
>> MUST query a proprietary Forwarding Address Server (FAS) named
>> lookup.themailregistry.com with an SMTP packet type called
>> LCKP, containing the failed address. The FAS will then
>> determine if the owner of the failed address has registered a
>> new, correct address with Mail Registry, Inc. If not, the FAS
>> will return the query with a null (zero) response code and the
>> server MUST reject the message and notify the sender of the
>> address status (undeliverable, etc.). If the FAS returns a new
>> address, the server MUST then forward the message to the new
>> address. The server MAY, depending upon the data received
>> from the FAS, then return a message to the client with the
>> additional information provided by the Mail Registry FAS, as
>> the client MAY have Mail Registry client software with which
>> to update address information known to the client.
>>###
>>
>> Now, before you yell at me, please be assured that I have not
>> the slightest presumption that my process could be published
>> in your RFC in such a cavalier fashion. I know that the ISOC
>> has its rules and regulations (I am a member) and I also
>> acknowledge that in patenting my process I have stepped on
>> many toes.
>>
>> However, would you pause and consider the facts: this process
>> works, the software is presently being developed and
>> considered by at least two large e-mail software vendors, we
>> will be offering the service soon, and the process will
>> eventually become part of the SMTP RFC ?
>>
>> So, I'm asking you - why not do it now, in your RFC ?
>>
>> My company, Mail Registry, Inc., is not rapacious. We plan to
>> receive an average of about $13.30 per year for each primary
>> Registrant (subscriber) to our service. I have spent several
>> years and almost $100,000 getting to this point and I hope to
>> make a reasonable return on my investment. Yes, if we get
>> millions of people to subscribe, we'll make millions of
>> dollars. But at least we're helping these millions of people
>> get all of their e-mail, it's a reasonable charge for a very
>> functional service, and we're making our money "the
>> old-fashioned way, working for it". I have no other
>> employment other than Mail Registry.
>>
>> And, as an Internet e-mail expert, you've got to admit that
>> the process solves a problem in an Internet sort-of-way, i.e.,
>> as part of the infrastructure.
>>
>> Would you help us ? I am available to meet with you, at your
>> convenience, and discuss the proper way to either insert this
>> process into RFC 2841 or as a separate RFC. I am currently
>> financing the company from my own resources but feel strongly
>> about assisting the endeavors of the ISOC when profits are
>> realized. After all, if you and your predecessors didn't
>> contribute what you could, the Internet would be vastly
>> different today.
>>
>> The patent is U.S. No. 6,427,164. There are many other
>> options and possibilities, explained to some degree in the
>> Whitepaper attached. Please note that the Whitepaper was
>> written at a very high level, thus it will surely seem tedious
>> to you. Our website is located at www.themailregistry.com.
>> And yes, we are actively exploring alternatives to VC funding.
>>
>>
>>
>> Thanks in advance
>>
>> bob reilly
>>
>>
>> Robert Reilly
>> President
>> Mail Registry, Inc.
>>
>>
>>
>>
>
>
>
>