PATCH: completion for MUAs

PATCH: completion for MUAs

[Oliver Kiddle]

On 20th March, Peter Stephenson wrote:

> - There are no completions for standard mail programmes or common
>   tools like elm and pine.

This patch adds these.

I used pine 4.21 and elm 2.4ME+ PL66 which are the versions which
happened to be on a machine at work. It is fairly probable that there
have since been changes to either of these. I've never been an elm user,
ever, so it might be useful if someone else checked the completion. I
left out the UWIN options for pine but they can always be added.

The UNIX `standard mail programmes' are unfortunately not as standard as
they maybe used to be. Linux has one programme which mostly resembles
BSD Mail. What I've done is made it complete the common options which
take an argument so that we are basically completing the right thing
even if all the options aren't listed. This does mean that for AT&T
mail, it completes some extra options but it isn't really doing any
harm. Both mush and zmail are basically supersets of BSD mail so I've
included them in the completion. I actually have a more complete mush
completion but it would probably be fairly pointless to add it.

The one thing which hasn't been done for any MUA is to parse the
addressbook/alias list and use it for generating the e-mail addresses.
I'm planning to look at this sometime soonish along with the stuff I
recently mentioned about completing hostnames.

I think that the best thing to do, rather than adding this separately
into each of _pine, _mutt etc would be to have one _email_addresses
which parses all the addressbooks it can find. Obviously we would only
want to complete aliases and nicknames for the appropriate MUA but it
could be useful to be able to complete e-mail addresses in other places
so for example mailto: urls would work and so if you use Mail to quickly
e-mail a file, e-mail addresses from the Netscape addressbook would be
available for completion.

Does anyone have suggestions for getting at or parsing the addressbooks
of different MUAs (apart from MH which is easy)?

Some MUAs are happy with addresses in forms like 'Name <user@host>' and
'user@host (Name)'. Any thoughts on how to deal with these (such as
whether it would be useful to expand to these) and other complications
such as distribution lists would be helpful.

Also in this patch, I've fixed _mutt, _ncftp and _multi_parts where they
weren't declaring a variable local but should have been.

Oliver

Index: Completion/Base/Utility/_multi_parts
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Utility/_multi_parts,v
retrieving revision 1.1
diff -u -r1.1 _multi_parts
--- Completion/Base/Utility/_multi_parts	2001/04/02 11:12:56	1.1
+++ Completion/Base/Utility/_multi_parts	2001/04/13 18:28:50
@@ -7,7 +7,7 @@
 # The parts of words from the array that are separated by the
 # separator character are then completed independently.
 
-local sep pref npref i tmp2 group expl menu pre suf opre osuf cpre
+local sep pref npref i tmp2 group expl menu pre suf opre osuf orig cpre
 local opts sopts matcher imm
 typeset -U tmp1 matches
 
Index: Completion/Unix/Command/.distfiles
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Command/.distfiles,v
retrieving revision 1.2
diff -u -r1.2 .distfiles
--- Completion/Unix/Command/.distfiles	2001/04/02 19:21:18	1.2
+++ Completion/Unix/Command/.distfiles	2001/04/13 18:28:50
@@ -11,7 +11,7 @@
 _configure    _gdb          _look         _patch        _su           _zcat
 _cpio         _getconf      _lp           _pbm          _sudo         _zdump
 _cvs          _gnu_generic  _ls           _perl         _tar          _zip
-_dd           _gprof        _lynx         _perldoc      _telnet
-_dict         _grep         _lzop         _prcs         _tiff
-_diff         _gs           _make         _psutils      _tin	_apm
+_dd           _gprof        _lynx         _perldoc      _telnet       _pine
+_dict         _grep         _lzop         _prcs         _tiff         _elm
+_diff         _gs           _make         _psutils      _tin	_apm  _mail
 '
Index: Completion/Unix/Command/_elm
===================================================================
RCS file: _elm
diff -N _elm
--- /dev/null	Mon Dec 11 17:26:27 2000
+++ _elm	Fri Apr 13 11:28:50 2001
@@ -0,0 +1,33 @@
+#compdef elm
+
+local curcontext="$curcontext" state line expl suf
+
+_arguments -C -s \
+  '::recipient:->userhost' \
+  '-a[use the arrow pointer regardless]' \
+  '-A+[attach file]:file attachment:_files' \
+  '-c[check the given aliases only]:*:alias' \
+  '-d+[set debug level]:debug level' \
+  '-f+[specify mailbox to load]:mailbox: _mailboxes' \
+  '-h[display help]' \
+  '-i+[specify file to include in message]:include file:_files' \
+  '-m[turn off menu, using more of the screen]' \
+  '-s+[specify a subject]:subject:' \
+  "-t[don't use termcap/terminfo ti/te entries]" \
+  '-V[enable sendmail voyeur mode]' \
+  '-v[display elm version]' \
+  '-w[write .elm/elmrc]' \
+  '-z[start only if new messages]' && return 0
+
+if [[ "$state" = userhost ]]; then
+  if compset -P '*@'; then
+    _description hosts expl 'remote host name'
+    _hosts "$expl[@]" && return 0
+  else
+    compset -S '@*' || suf='@'
+    _description users expl 'login name'
+    _users "$expl[@]" -q -S "$suf" && return 0
+  fi
+fi
+
+return 1
Index: Completion/Unix/Command/_mail
===================================================================
RCS file: _mail
diff -N _mail
--- /dev/null	Mon Dec 11 17:26:27 2000
+++ _mail	Fri Apr 13 11:28:50 2001
@@ -0,0 +1,24 @@
+#compdef mail mailx Mail mush zmail
+
+local curcontext="$curcontext" state line expl suf
+
+_arguments -C -s \
+  '(-f -u)*-b[specify a BCC recipient]:BCC recipient:->userhost' \
+  '(-f -u)*-c[specify a CC recipient]:CC recipient:->userhost' \
+  '(-b -c -u -s *)-f+[specify mail folder]:mailbox:_mailboxes' \
+  '(-f -u)-s+[specify a subject]:subject:' \
+  "(-b -c -f -s *)-u+[read specified user's mail]:user:_users" \
+  '(-f -u)*:recipient:->userhost' && return 0
+
+if [[ "$state" = userhost ]]; then
+  if compset -P '*@'; then
+    _description hosts expl 'remote host name'
+    _hosts "$expl[@]" && return 0
+  else
+    compset -S '@*' || suf='@'
+    _description users expl 'login name'
+    _users "$expl[@]" -q -S "$suf" && return 0
+  fi
+fi
+
+return 1
Index: Completion/Unix/Command/_mutt
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Command/_mutt,v
retrieving revision 1.1
diff -u -r1.1 _mutt
--- Completion/Unix/Command/_mutt	2001/04/02 11:57:59	1.1
+++ Completion/Unix/Command/_mutt	2001/04/13 18:28:50
@@ -1,12 +1,12 @@
 #compdef mutt
 
-local curcontext="$curcontext" state line suf
+local curcontext="$curcontext" state line expl suf
 typeset -A opt_args
 
 _arguments -C -s \
     '::recipient:->userhost' \
     '*-a[attach file using MIME]:file attachment:_files' \
-    '*-b[specify a BCC recipient]:BCC recepient:->userhost' \
+    '*-b[specify a BCC recipient]:BCC recipient:->userhost' \
     '*-c[specify a CC recipient]:CC recipient:->userhost' \
     '-e+[specify a post-init configuration command]:post-init configuration:' \
     '-f+[specify mailbox to load]:mailbox: _mailboxes' \
Index: Completion/Unix/Command/_ncftp
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Command/_ncftp,v
retrieving revision 1.1
diff -u -r1.1 _ncftp
--- Completion/Unix/Command/_ncftp	2001/04/02 11:58:34	1.1
+++ Completion/Unix/Command/_ncftp	2001/04/13 18:28:50
@@ -1,6 +1,6 @@
 #compdef ncftp lftp
 
-local bookmarks=$HOME/.$service/bookmarks
+local expl bookmarks=$HOME/.$service/bookmarks
 
 if [[ -f $bookmarks ]]; then
   bookmarks=(${"${(f)$(<$bookmarks)}"%%[[:space:],]*})
Index: Completion/Unix/Command/_pine
===================================================================
RCS file: _pine
diff -N _pine
--- /dev/null	Mon Dec 11 17:26:27 2000
+++ _pine	Fri Apr 13 11:28:50 2001
@@ -0,0 +1,68 @@
+#compdef pine pinef
+
+local curcontext="$curcontext" state line expl suf
+local optfile getopts='pine -conf' sortorder lusortorder opts send idx
+
+if [[ -n $+_cache_pine_options ]]; then
+  for optfile in ~/.pinerc /etc/pine.conf; do
+    if [[ -f $optfile ]]; then
+      getopts="cat $optfile"
+      break
+    fi
+  done
+  _cache_pine_options=( $($=getopts | sed -n 's/^\([^#]*=\).*/-\1/p') )
+fi
+
+sortorder=( {subject,arrival,date,from,size}{,/reverse} )
+lusortorder=( dont-sort {nickname,fullname}{,-with-lists-last} )
+
+opts=( -h -F -conf -create_lu -pinerc )  # exclusive options
+idx=( -f -c -i -I -n -o -sort )  # options used when viewing messages
+send=( -attach -attachlist -attach_and_delete -url )  # options when sending
+
+_arguments -C -s \
+  "($opts $idx $send -bail -k -z -r -p -P *)-h[display help]" \
+  "($opts $idx $send -r *)-F+[specify file to open and page through]:file:_files" \
+  "($opts $idx $send *)-conf[print out fresh global configuration]" \
+  "($opts $idx $send *)-pinerc[put fresh pinerc configuration in file]:file:_files" \
+  "($opts $idx $send *)-create_lu[create .lu from script]:addressbook file:_files:sort order:(${(j: :)lusortorder})" \
+  "($opts $idx -url)-attach[go directly into composer with given file]:file:_files" \
+  "($opts $idx -url)-attachlist[go to composer with given files]:file:_files" \
+  "($opts $idx -url)-attach_and_delete[go to composer, attach file, delete when finished]:file:_files" \
+  "($opts $idx $send)-url[open the given URL]:url:->url" \
+  "($opts $send)-f+[specify mailbox to load]:mailbox: _mailboxes" \
+  "($opts $send)-c+[specify context to apply to -f arg]:number" \
+  "($opts $send)-sort[specify sort order of folder]:sort order:(${(j: :)sortorder})" \
+  "($opts $send)-i[go directly to index, bypassing main menu]" \
+  "($opts $send)-I+[specify initial keystrokes to be executed]:keystrokes" \
+  "($opts $send)-n+[entry in index to begin on]:number" \
+  "($opts $send)-o[open first folder read-only]" \
+  "(-F -h)-r[restricted - can only send mail to oneself]" \
+  "(${opts#-F})-k[force use of function keys]" \
+  "(${opts#-F})-z[allow use of ^Z suspension]" \
+  "(${opts#-F})-p+[use alternate .pinerc file]:alternate pinerc:_files" \
+  "(${opts#-F})-P+[use alternate pine.conf file]:alternate pine.conf:_files" \
+  "(${opts#-F})-bail[exit if pinerc file doesn't already exist]" \
+  '*::recipient:->userhost' \
+  ${^_cache_pine_options}':option value' && return 0
+
+if [[ "$state" = url ]]; then
+  if compset -P 'mailto:'; then
+    state=userhost
+  else
+    compadd -S: mailto && return 0
+  fi
+fi
+
+if [[ "$state" = userhost ]]; then
+  if compset -P '*@'; then
+    _description hosts expl 'remote host name'
+    _hosts "$expl[@]" && return 0
+  else
+    compset -S '@*' || suf='@'
+    _description users expl 'login name'
+    _users "$expl[@]" -q -S "$suf" && return 0
+  fi
+fi
+
+return 1

_____________________________________________________________________
This message has been checked for all known viruses by the 
MessageLabs Virus Control Centre. For further information visit
http://www.messagelabs.com/stats.asp

Re: PATCH: completion for MUAs

[Bart Schaefer]

On Apr 13,  7:31pm, Oliver Kiddle wrote:
} Subject: PATCH: completion for MUAs
}
} I actually have a more complete mush completion but it would probably
} be fairly pointless to add it.

I apologize for the somewhat off-topic reply, but I thought some of the
zsh-workers might be interested in the following.

------------------------------------------------------------------------

     Subject: Open-source Z-Mail: a call for help
        Date: Thu, 12 Apr 2001 04:39:00 GMT
        From: Jerry Hudgins <jerry@e-farm.com>
 Organization:Western Digital Design, Marin County,
              California
  Newsgroups: comp.mail.zmail, comp.mail.misc,
              comp.mail.mime, comp.mail.mush

For the uninitiated:  Z-Mail is a powerful standards-based, MIME-aware
commercial mail program which descended from the freeware mush system.
It's scriptable, highly configurable, and runs on a wide variety of
UNIX platforms in shell, full-screen, and Motif modes.  There were
once ports to both Windows and Macintosh as well, and these versions
used the same mail file format and scripting language as their UNIX
cousin.

The Z-Mail product was purchased by NetManage several years ago, and
after retiring the Windows and Mac ports, they've now discontinued
the UNIX version.  They've pretty thoroughly purged it from their Web
site; however, if you're curious, a tutorial lingers:

http://supportweb.netmanage.com/tutorials/zmail-motif/zmail_intro.html

Given that they're no longer interested in selling it, I think that
NetManage should be encouraged to release the code as open source,
perhaps using the Mozilla model.  They could make money by selling new
support contracts for business users, if they liked, and both free and
commercial UNIX users could immediately benefit from its availability.
I'd also anticipate interest in reviving the Windows and Mac ports -
those platforms could use a better option again.

First, however, we must convince NetManage to release the code.  I've
sent my own note of encouragement to:

    sales@netmanage.com
    support@netmanage.com

and if you're willing to help, please do likewise.  Point out the
potential support revenue.  Remind them that their old competitor,
Ishmail, is now open-source.  Assure them of the resulting goodwill
toward NetManage, and the potential for increased interest in their
other products.  Educate them on the benefits of open-source efforts.

If we make enough noise, perhaps they'll agree to do it - and this
would be a Very Good Thing.  Pitch in if you can.

-jch

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: PATCH: completion for MUAs

[Bart Schaefer]

On Apr 13,  7:31pm, Oliver Kiddle wrote:
} Subject: PATCH: completion for MUAs
}
} The one thing which hasn't been done for any MUA is to parse the
} addressbook/alias list and use it for generating the e-mail addresses.
} 
} Does anyone have suggestions for getting at or parsing the addressbooks
} of different MUAs (apart from MH which is easy)?

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.

Then there's also completion of user names @ the local machine, and
maybe even /etc{/mail,}/aliases names or the equivalent for other MTAs.

} Some MUAs are happy with addresses in forms like 'Name <user@host>' and
} 'user@host (Name)'. Any thoughts on how to deal with these (such as
} whether it would be useful to expand to these) and other complications
} such as distribution lists would be helpful.

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).

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).

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 ...?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: completion for MUAs

[Oliver Kiddle]

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

Re: completion for MUAs

[Bart Schaefer]

On Apr 19,  7:27pm, Oliver Kiddle wrote:
} Subject: Re: completion for MUAs
}
} Bart Schaefer wrote:
} 
} > 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.

The problem is that there is no "normal MUA addressbook."  The really old,
found-on-every-Unix-system MUAs don't really have an "addressbook" at all,
just aliases in e.g. the ~/.mailrc file.  Sometimes the location of that
file is stored in the MAILRC environment variable, but sometimes not.

} What do you think this separate function achieves mainly - simplicity,
} speed?

Simplicity more than speed.  Make it possible for a casual user to write
a function to provide his address book to the completion system without
having to understand much more than the format of the address book file.
 
} > 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.

It's almost always better to append @$HOST I think.
 
} > 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).
} 
} 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?

Not exactly, though that certainly applies in some cases.  There are a
number of ways in which it can go wrong.  (I used to know all of them,
but I haven't been in the MUA business for a while now.)  Generally it's
just that parsing is applied to things like a "To:" line read from a
file (where multiple addresses are always expected) and skipped when the
command line is involved.  The most common failure mode is that the
SMTP conversation gets `RCPT TO:<user@host,>' (note placement of comma)
and results in a bounce message for an unparsable address.

} > 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'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?

It's defined in the standard email RFCs as far back as RFC822, and all
MTAs should understand it ... actually, I typed it wrong in the excerpt
above, it's just `groupname: addresses ;' with no leading @.  With a
leading @, then it's got to be inside < > like `<@route:address>' and
has nothing to do with groups.

} 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

That's very old and dates from the days before the Internet when most
mail was transmitted by UUCP (unix-to-unix copy).  It's the same syntax
that used to be used in the "Path:" header of usenet articles.  It's
just `host1!host2!host3!host4!user', where the intended recipient is
`user@host4' and `host1' is the "first hop" from your host towards the
eventual destination.  Yes, one used to have to know the names of all
the machines in the entire store-and-forward path between machines in
order to get mail delivered.

This was replaced by the <@route:address> syntax, which would look like
`<@host1,@host2,@host3:user@host4>' to mean the same thing.  That syntax
is strongly discouraged now, and most MTAs simply throw away everthing
up to the `:' and decide on their own how to route to `host4'.

} 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.

The grammar is actually pretty regular (if you ignore things like X.400
addresses [if you don't know, don't ask]) and can be parsed with a regex
with the exception of comments, which may use nested levels of parens
and therefore require a stack machine of some sort.

Here's the whole RFC822 grammar expressed as extendedglob patterns; I
converted this from a set of regex definitions I had, so I may have
missed turning a `+' into a `##' or the like but it should be mostly
correct:

__specialx='][()<>@,;:\\".'
__spacex=" 	"				# Space, tab
__specials="[$__specialx]"
__atom="[^$__specialx$__spacex]##"
__space="[$__spacex]#"				# Really, space or comment
__qtext='[^"\\]'
__qpair='\\?'
__beginq='"'
__endq='(|[^\\])"'
__dot="$__space.$__space"
__comma="$__space,$__space"

__domainref="$__atom"
__domainlit='\[([^]]|'"$__qpair"')#(|[^\\])\]'
__quotedstring="$__beginq($__qtext|$__qpair)#$__endq"
__word="($__atom|$__quotedstring)"
__phrase="($__space$__word$__space)#"		# Strictly, should use `##'
__localpart="$__word($__dot$__word)#"

__subdomain="($__domainref|$__domainlit)"
__domain="$__subdomain($__dot$__subdomain)#"
__addrspec="$__localpart$__space@$__space$__domain"
__domainlist="@$__domain($__comma@$__domain)#"
__route="($__space$__domainlist${__space}:$__space)"
__routeaddr="<$__route#$__addrspec$__space>"
__mailbox="($__addrspec|$__phrase$__space$__routeaddr)"

Note that a comment is legal anywhere a space is legal.  That's the part
that drives everyone bonkers, and I've left it out of the grammar above.

It might be better to rewrite it for zregexparse.

With the above, given a string with the comments stripped out, you should
be able to tell if it is an address with something like:

    [[ $string = $~__mailbox ]] && echo "That's an email address"

} In particular, how do you separate one address from the next one
} safely.

In a strict RFC822 grammar, addresses can be separated only by unquoted
commas.  However, many MUAs fudge and try to guess what the user means
if he uses spaces between the addresses instead.  All bets are off in
an addressbook, though, because the RFC822 rules only apply to addresses
"on the wire".

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net