From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22914 invoked from network); 19 Apr 2001 18:27:13 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 19 Apr 2001 18:27:13 -0000 Received: (qmail 21860 invoked by alias); 19 Apr 2001 18:27:07 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 14043 Received: (qmail 21848 invoked from network); 19 Apr 2001 18:27:05 -0000 Sender: kiddleo Message-ID: <3ADF2DF6.BE358FD5@u.genie.co.uk> Date: Thu, 19 Apr 2001 19:27:02 +0100 From: Oliver Kiddle X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.15 i686) X-Accept-Language: en MIME-Version: 1.0 To: zsh-workers@sunsite.dk Subject: Re: completion for MUAs References: <3AD7461F.A6B691FC@u.genie.co.uk> <1010414180144.ZM3683@candle.brasslantern.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bart Schaefer wrote: > There are quite a variety of addressbook formats, ranging from nothing > more than a batch of commands or assignments in the MUA's init files > through Pine's tab-delimited records to networked LDAP lookup. Rather > than try to provide a function that parses any significant subset of > these, I suggest working out some kind of a plugin model -- paste up a > function name using $service or the like, and call it if it exists. That's certainly a possibility but I want to allow, for example the standard UNIX mail command to complete addresses from the user's normal MUA's addressbook. A style could override the function called. Most people probably stick to one MUA (unlike me at the moment) so it isn't much of a problem if only one addressbook is parsed. What do you think this separate function achieves mainly - simplicity, speed? > Then there's also completion of user names @ the local machine, and > maybe even /etc{/mail,}/aliases names or the equivalent for other MTAs. Yes. So we need handling for different MTAs too. I also suspect that in some contexts (URLs maybe) these might need @localhost appended. > Some MUAs also are happy with comma-separated lists of addresses in one > or more command-line arguments while others make each argument an address > and don't attempt to parse it further (which can lead to strange problems > later when calling the MTA or having an SMTP conversation). Yes, that can probably be handled in the MUA's completion with suitable options such as -S ','. Is the situation that some MUA's aren't fussed and rely on the MTA to complain if it wants to with MTAs varying on whether they accept comma separated lists? > I'd advise completing only the user@host part, unless it's too difficult > to pick it out of the addressbook entry (but that'd be up to the plugin > in any case, if you take my advice above). Yes, okay. It would be better to only complete the other stuff if we can separate the constituent parts and do it all intelligently. > By "distribution lists" do you mean `@groupname:addr,addr,addr;' syntax, > or are you talking about e.g. completing individual addresses that appear > in the definition of a group or alias in the addressbook, or ...? I was using the pine terminology and meant aliases/nicknames which map to more than one e-mail address. I've not seen syntax you mention. How does that work - is it some specific MTA's shorthand or something understood by MTAs and defined in an rfc? I also seem to remember some syntax, possibly using exclamation marks where you can specify the route through specific mail servers the e-mail takes (actually I wonder if I can use that to specify addresses in my MTA at work which go direct to the host's MX such as a.mx.sunsite.dk and bypass the smtp server here which adds an annoying advert to the bottom of every mail about the virus checker it uses). It'd be nice to properly complete these sort of things, partly because it would provide an easy reminder of the syntax for them. I had some vague ideas of displaying names next to aliases/nicknames with the verbose style which would be complicated for distribution lists. Pine certainly allows a description of the group. Also, I thought of doing some sort of expansion (like _pids does for process names) so where nicknames are not going to be understood, they could be expanded to the address(es). The crux of it is that what I'm concerned about is how does one safely parse e-mail addresses. I've read enough of the mail rfcs and sendmail configs to know that e-mail addresses and correct parsing of them is extremely complicated but I've not retained enough details in my head on this to feel confident of doing something which is absolutely correct. In particular, how do you separate one address from the next one safely. Much of this parsing is going to be common to MUAs, particularly mush/Mail/mutt where the format is something like alias nickname=address so there is scope for using some common code which makes me unsure about your plugin function idea. I was also hoping that someone would happen to have some existing script which parses their addressbook. Maybe the best plan is if I just come up with something simple based on what we currently have at the bottom of _mutt, _pine etc and then we can evolve it to something better. Oliver