ietf-822
[Top] [All Lists]

Re: Internet draft draft-onions-822-mailproblems-00.txt

1995-02-20 15:01:58
Eh Rick, I found RFC1440 and read it. It wasn't exactly what I had in          
mind, really.    ...                                                           
                                                                                
        Yes.   And I didn't mean to get the thread side-tracked.                
                                                                                
                         I rather see a multipart/uft with one part           
application/uft containing the control stuff and a second part                 
containing the file to be transferred with proper content-type: and            
content-transfer-encoding:.                                                    
                                                                                
        Exactly.   The protocol was intended to be "wrappable" in MIME          
very much as you've outlined there.                                             
                                                                                
Anyway, my dream of a submission protocol is somewhat more modest.             
I wish a MUA (Mail User Agent) could be able to submit a mail in MIME          
format without acting as a MTA (Mail Transfer Agent).                          
                                                                                
        I told Ned in recent mail that I was about to give up hope              
on this very concept.   SMTP is an on-the-wire protocol.   MIME is,             
because of its being an IETF thing,  also directed at IP,  but is               
all too often  IMPLEMENTED OFF-the-wire.   Think about it.                      
                                                                                
        MIME works (IMHO) nicely when examined as  "plain text                  
stored locally,  then sent via mail"  (whatever "mail" is).                     
Usually,  but not always,  this means the MIME object  (a piece of              
mail,  or a note)  will be carried over SMTP.                                   
                                                                                
        I've been making good use of  'sendmail -t'  on UNIX.                   
There's an analog in many environments.   The input to  /usr/lib/sendmail       
is  NOT  CRLF-delimited-lines,  but  NL-delimited-lines.   Sendmail does        
the translation  (what there is of it)  to SMTP's idea of plain text.           
                                                                                
implications as all (client-server) MUA's currently are destined to use        
SMTP to submit outbound messages. It has to know if the mailbox address        
differs from the identity of the user account. It is difficult as an           
administrator to keep large sites MUA configurations synchronised (mail        
domain and formal mailbox names, for example).                                 
                                                                                
        When submitting mail is implemented by function calls                   
instead of as a pipeline,  then you can deal with non-zero return codes.        
But that loses simplicity.   It might be reasonable to test for                 
"consumer terminated"  (SIGPIPE)  as a first crack at doing it right.           
(though UNIX sendmail won't quit,  it just eats the whole message and           
queues it;  failure is deferred,  and you get mail back from the daemon         
(gee thanks)  rather than immediate notification)                               
                                                                                
        Then too re-writing sendmail to terminate early in case                 
of error won't help gatewayed (non SMTP) mail.                                  
                                                                                
-- Tomas                                                                       
                                                                                
--                                                                              
Rick Troth <troth(_at_)ua1vm(_dot_)ua(_dot_)edu>, Houston, Texas, USA           
                 
http://ua1vm.ua.edu/~troth/                                                     
                                                                               
QUIT