ru.unix

 
 - RU.UNIX ----------------------------------------------------------------------
 From : Peter V. Chernikoff                  2:5020/2091    24 Jan 2001  04:18:20
 To : Pavel Narozhniy
 Subject : DJB проснулся (или я проспал?)
 -------------------------------------------------------------------------------- 
 

    [1]D. J. Bernstein
    [2]Internet mail
    
                               Internet Mail 2000
                                        
    IM2000 is a project to design a new Internet mail infrastructure
    around the following concept: Mail storage is the sender's
    responsibility.
    
    IM2000 is discussed on the [3]IM2000 mailing list.
    
 Some ramifications of this concept
 
    Each message is stored under the sender's disk quota at the sender's
    ISP. ISPs accept messages only from authorized local users.
    
    The sender's ISP, rather than the receiver's ISP, is the always-online
    post office from which the receiver picks up the message.
    
    The message isn't copied to a separate outgoing mail queue. The
    sender's archive is the outgoing mail queue.
    
    The message isn't copied to the receiver's ISP. All the receiver needs
    is a brief notification that a message is available.
    
    After downloading a message from the sender's ISP, the receiver can
    efficiently confirm success. The sender's ISP can periodically
    retransmit notifications until it sees confirmation. The sender can
    check for confirmation. There's no need for bounces.
    
    Recipients can check on occasion for new messages in archives that
    interest them. There's no need for mailing-list subscriptions.
    
 Some advantages
 
    In the old Internet mail infrastructure, keeping track of undelivered
    messages takes a lot of work. The mail client (e.g., ezmlm) and mail
    transfer agent (e.g., qmail) have to support variable envelope return
    paths; bounce messages then have to be parsed by an automated bounce
    handler that matches bounces with original messages. In IM2000, each
    message in the sender's archive carries its own delivery status.
    
    In the old Internet mail infrastructure, bounce messages are often
    misdirected by low-quality software. Users end up receiving bounce
    messages that should have been sent to an automated bounce handler. In
    IM2000, there are no bounce messages.
    
    In the old Internet mail infrastructure, mailing-list managers have to
    keep track of mailing-list subscriptions. Typical subscription
    protocols are slow, complicated, unreliable, difficult to automate,
    and trivially subject to forgery. In IM2000, mailing lists are a
    purely local matter for the receiver's software.
    
    In the old Internet mail infrastructure, the receiver's ISP has to
    carefully write every message to disk, so that messages will not be
    lost if the computer crashes. This limits the amount of mail that can
    be received. In IM2000, the receiver's ISP can keep notifications in
    memory.
    
    In the old Internet mail infrastructure, a message to a large mailing
    list is written to disk on a huge number of computers. In IM2000, a
    message to a large mailing list is written to disk only by a few
    receivers who want to save local copies of the message.
    
 Some questions
 
    How should receivers be identified? How will the sender's ISP find the
    receiver's ISP? Recipients will want to move transparently from one
    host to another.
    
    How should senders be identified? How will the receiver find the
    sender's ISP? Recipients will want to provide better handling to known
    senders; in the long run, recipients will want to debit unknown
    senders.
    
    How should messages be identified? How should messages be downloaded?
    Messages could be retrieved through HTTP, but an NFS/FSP-style
    UDP-based protocol would be much more resistant to denial of service.
    
    How should notifications, messages, and confirmations be protected
    against espionage and sabotage? DH authenticators seem more
    appropriate than public-key signatures for private email; they're also
    much faster and just as convenient.
    
    How should the sender create a message?
    
    How should the receiver download a list of notifications?
    
    What format should messages have?
 
 References
 
    1. http://cr.yp.to/djb.html
    2. http://cr.yp.to/mail.html
    3. http://cr.yp.to/lists.html#im2000
 ===============================================================================
 
 -- 
 WBR, Peter V. Chernikoff
 mailto: zsh7<at>chat<dot>ru
 
     Жизнь - это болезнь, которая передается половым путем.
                 
 --- Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Crater Lake)
  * Origin: Juggernaut ``DiggerNet'' News Server (2:5020/2091)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор