Subject: Anyone have Reply-To patch?

From: "Gregory J. Atchity" <[email-masked]>
Date: Fri, 4 Mar 1994 09:50:04 -0600 (CST)

I've got SLIP and LINUX running on my PC at home and I'd like to use Pine
for sending email from there, but really need the Reply-To header since my PC
is only on the net a few hours a night and my main mailbox is at work
anyway.

   Anyways, before I invest some time making source mods, does anyone have
patches that implement the Reply-To?

   Also, I found in the c-client where the remote IMAPd link (rimapd) is
specified as /etc/rimapd.  I might suggest that the path to rimapd be a
variable in the system .pinerc file in the next release.  My central mail
server sysop will not support IMAP (yet), so I had to make a source code mod
to run my own private copy of imapd.  I just changed the path to rimapd in
the source for my pc-linux version of pine (to bin/rimapd), and copied imapd
to to bin/rimpad on my private account at work.  It's working just fine so
far.

   Keep up the good work on Pine, I'm starting to prefer it over ELM.  As
soon as you put in user-defined headers and message tagging, it'll be no
contest between the two.  (Ok, one minor beef remains, I don't like that the
addressbook doesn't support comments.  But I've now a central ELM format
addressbook and a shell script I use to produce a Pine .addressbook).

---
Greg Atchity ([email-masked] and [email-masked])
Iowa State University and Ames Laboratory - USDOE

---

From: David L Miller <[email-masked]>
Date: Fri, 4 Mar 1994 09:09:48 -0800 (PST)

Greg,

The next version of Pine will include support for the Reply-To header.  
In the mean time, if your username is the same on your local and remote 
systems, you might be able to get the effect you want by setting the 
user-domain variable in your .pinerc.  The problem with making the path 
to rimapd configurable is that if you move it then only clients with the 
same configuration will be able to use it.  This would lead to no end of 
confusion if you get users trying to use other (c-client based) clients, 
or even the same client program with a different path.  

We are still mulling over how to implement user-defined headers.  Message
annotation and flagging are proposed or in the works.  Addressbook comments
may well come as a side-effect of IMSP support.  Anything else you need? 

Thanks for the request!

--DLM

|\ |  |\/|  David L. Miller    [email-masked]  (206) 685-6240
|/ |_ |  |  Software Engineer, Pine Development Team   (206) 685-4045 (FAX)
University of Washington, Networks & Distributed Computing
4545 15th Ave NE, Seattle WA 98105, USA

---

From: Mark Crispin <[email-masked]>
Date: Fri, 4 Mar 1994 13:59:47 -0800 (PST)

> to to bin/rimpad on my private account at work.  It's working just fine so

Hello.

The rimapd functionality is not for ``remote imapd'' (although you seem 
to be using it successfully for that), but rather for pre-authenticated 
IMAP connections using the BSD r protocols.  The normal means of 
accessing IMAP servers is via a TCP/IP connection to port 143.

The reason why the /etc/rimapd name is wired in to the code is that for
the pre-authentication service to be meaningful, it has to use a single,
globally-valid means of access.  If the attractive nuisance of having it 
as a parameter were available, then people would be misled into changing 
it, and then discover that the service broke when trying to access other 
systems.

We are aware that there are legitimate reasons such as yours why you 
would want to change it.  It is for this reason (among others) that we 
provide sources; we feel that someone who understands the issues will 
also understand how to modify the source code AND will understand that he 
is making a non-standard change.

For your particular application -- access to a private imapd -- it is 
intended that there will be an alternative mechanism.  This is part of 
the general idea to have ``dialup IMAP'' without requiring SLIP or PPP.
There isn't any time estimate yet on when this will happen; but it will 
probably be some time this year after IMAP4 support is finished.  So, 
help is one the way!

Thank you for your suggestions, and for reminding us that your type of 
application is still not adequately addressed.

Regards,

-- Mark --