This is how the problem was described on pine-info recently:

http://mailman1.u.washington.edu/pipermail/pine-info/2006-February/046089.html
-------------------
This is how to reproduce the problem:
Compose message,
send to: testuser@phy.syr.edu,  which changes to Test User <testuser@phy.syr.edu> (due
to local lookup or addressbook?)
at this point if it's sent, goes fine.
But now try to hit CTRL-R for more headers, by mistake hit Ksent-mail and try to send,
doesn't exist, would you like to create... so I say no, go back and take the K off...
try to send and it balks changing the To: field to: Test@phy.syr.edu,
          UNEXPECTED_DATA_AFTER_ADDRESS@.SYNTAX-ERROR.
--------------
The error occured to me also very often, this mail helped me
and this is what I found (contains also my description how to reproduce):

I have found a piece in the puzzle in the quest around the
UNEXPECTED_DATA_AFTER_ADDRESS@.SYNTAX_ERROR bug. After long debugging,
I finally arrived at a way to reliably reproduce and found a way
to success. Here is the end of this part of the saga: I set a
breakpoint to the mm_log function which is called from the MM_LOG
macro here immediately before the bug is surfaces to the user:

          s = isalnum (c) ? "Must use comma to separate addresses: %.80s" :
            "Unexpected characters at end of address: %.80s";
          sprintf (tmp,s,string);
          MM_LOG (tmp,PARSE);
          last = last->next = mail_newaddr ();
          last->mailbox = cpystr ("UNEXPECTED_DATA_AFTER_ADDRESS");

A programmer can see, that there is a debug message triggered by the bug,
and if you compiled pine run pine with debug, you also get a message
in your debug log which contains the string on which the bug was
triggered. That's just a hint about a simple(r) way to get information
about it.

Ok, here we are in the debugger, at the breakpoint:

Breakpoint 7, mm_log (string=0xbfff62a0 "Must use comma to separate addresses: Kaindl", errflg=3)
    at imap.c:214

Here you see the message which is written to the log file, the string on which
the function failed is after the colon, it's my last name, Kaindl.

I used my own address as the "To" address for debugging, to not spam somebody
else with debug mails...

Let's show a complete walk up the stack to get the big picture where we are:

(gdb) backtrace
#0  mm_log (string=0xbfff62a0 "Must use comma to separate addresses: Kaindl", errflg=3)
    at imap.c:214
#1  in rfc822_parse_adrlist (lst=0xbfff66e4, string=0x86982e1 "Kaindl",
    host=0x8565810 "suse.de") at rfc822.c:915
#2  in strings2outgoing (header=0xbfffa9b0, bod=0xbfffab64, attach=0x0, charset=0x0,
    flow_it=0) at send.c:8097
#3  in pine_send (outgoing=0x8689000, body=0xbfffab64,
    editor_title=0x840718b "FORWARD MESSAGE", role=0x8673dd0, fcc_arg=0x0, reply=0x0,
    lcc_arg=0x0, custom=0x86830c0, sticky_fcc=0) at send.c:4367
#4  in forward (ps=0x855a008, role_arg=0x0) at reply.c:4260
#5  in cmd_forward (state=0x855a008, msgmap=0x858db10, agg=0) at mailcmd.c:3078
#6  in process_cmd (state=0x855a008, stream=0x856a2f8, msgmap=0x858db10, command=706,
    in_index=MsgIndx, force_mailchk=0xbfffd2b0) at mailcmd.c:645
#7  in index_lister (state=0x855a008, cntxt=0x8568f10, folder=0x855a0d5 "INBOX",
    stream=0x856a2f8, msgmap=0x858db10) at mailindx.c:1586
#8  in index_index_screen (state=0x855a008) at mailindx.c:663
#9  in mail_index_screen (state=0x855a008) at mailindx.c:651
#10 in main (argc=3, argv=0xbfffe924) at pine.c:1369

Ok, lets step up the stack two times:

(gdb) up
#1  0x08280b40 in rfc822_parse_adrlist (lst=0xbfff66e4, string=0x86982e1 "Kaindl",
    host=0x8565810 "suse.de") at rfc822.c:915
915               MM_LOG (tmp,PARSE);
(gdb) up
#2  0x081f0095 in strings2outgoing (header=0xbfffa9b0, bod=0xbfffab64, attach=0x0, charset=0x0,
    flow_it=0) at send.c:8097
8097                          rfc822_parse_adrlist(&new_addr, the_address,

Ok, we arrived in strings2outgoing(). During the debug sessions before,
looked at what pine did, and the functions rfc822_parse_adrlist() which
finally shows the bug is called many many times from many places inside
pine, and I never saw the error triggered when it was called from other
places than strings2outgoing, that's why I looked here. That's the place
where it happens - where rfc822_parse_adrlist is called by strings2outgoing:

                      if(!the_address)
                        the_address = pf->scratch;

                      rfc822_parse_adrlist(&new_addr, the_address, ...

Here, from the viewpoint of the string pointer "the_address" which is used
here to pass the address(es) to rfc822_parse_adrlist, more can be seen:

(gdb) p the_address
$6 = 0x86982d8 "Bernhard Kaindl"

Hm, so it looks like strings2outgoing didn't pass an address to
rfc822_parse_adrlist, but just my name without the address, no
wonder that rfc822_parse_adrlist complains, but let's veryfy
where it comes from:

                char *the_address = NULL;
....
                  /*
                   * If encoded exists, that means that build_address filled
                   * it in when expanding an addrbook nickname so as to
                   * preserve the charset information.
                   * If it wasn't edited at all, we don't go through here
                   * and we just use the original addr, which still has
                   * the charset info in it.
                   */
                  if(pf->he){
                      PrivateTop *pt;

                      pt = (PrivateTop *)pf->he->bldr_private;
                      if(pt && pt->encoded && pt->encoded->etext)
                        the_address = pt->encoded->etext;
                  }

So putting the above together to an expression, it's set if if
((PrivateTop *)pf->he->bldr_private)->encoded->etext
is set - it's set to the address pointed to by etext then.

Just for completeness what pf contains:

(gdb) p *pf
$7 = {name = 0x8673ce0 "To", type = Address, canedit = 1, writehdr = 1, localcopy = 1, rcptto = 1,
  standard = 0, cstmtype = NoMatch, val = 0x0, addr = 0x8689020,
  scratch = 0x869d690 "Bernhard Kaindl <bk@suse.de>", text = 0x0, textbuf = 0x0, he = 0x86861e4,
  next = 0x8685e04}

So there, in pf->scratch is indeed my full address as it was shown
in the composer before I pressed ^X. But since the condition in the
code above sets the_address to a different value (otherwise the working
value of pf->scratch = 0x869d690 "Bernhard Kaindl <bk@suse.de>" would
have been used)

Just for confirmation the printout of the culprit:

(gdb) p *((PrivateTop *)pf->he->bldr_private)->encoded
$11 = {etext = 0x86982d8 "Bernhard Kaindl", cksumlen = 28, cksumval = 600773573}

Obviously, what is told in the comment from the source code
above is not true for me. It doen't contain a address from an
addrbook nickname, but my name without the address, which is
not suitable for checking wether the address is correct...

It should be easy to just pass pf->scratch instead of the_address,
and then it should hopefully no longer be possible to trigger this
specific bug.

The questions are now:

* Is the same wrong assumption also made at other places?
  (We would still see some errors, even not using the_address here)

* Is it possible / worthwile to try fix the problem in build_address
  which looks like the the next way to look?

* If that is considered, could it break other users of encoded->etext?

How to trigger:

It seems you need to have to setup an Fcc field in your Mail header
editor, my 4.64 config opens an Fcc field when I press returm in
the To field when forwarding for example. I also use an IMAP server
for the primary mail folder collection, which may also be needed to
trigger it relably. What I do is the following:

I enter my nick which is found in yello pages, go down to the Fcc
field, edit the Fcc field to contain a folder name which does not
exist yet, press ^X, then I have some roles defines and pine asks
me now if I want to use the default role for sending this mail,
then pine asks me whether I may create the Fcc folder on the in
the IMAP folder-collection and then I anwser the yes/no promt with N.
I then kill what is entered in the the Fcc field and immediately
press ^X and now I indeed try to send the mail - and this is the
first time we enter strings2outgoing, and we have seen the rest
above.

Deleting the error strings and reentering them does not help,
so it's possible that
((PrivateTop *)pf->he->bldr_private)->encoded->etext
keeps its value. I have to exit the send function by
postponing the message and then after restarting the
mail send function, continuing the postponed message,
I can send to message (unless I say No to the Fcc folder
name while attempting to send again)

The error might indeed be initially triggered by the saying No
to the Fcc folder name. I didn't trigger it in other ways now.

I remember triggering this error some time ago with oder pine versions simply
bu having a non-ascii character in one of the recipient names.
This may have been a different bug back then however.

Quick (smallest change) solution to get rid of the problem:

--- pine4.64/pine/send.c
+++ pine4.64/pine/send.c
@@ -8094,7 +8094,7 @@
                      if(!the_address)
                        the_address = pf->scratch;

-                     rfc822_parse_adrlist(&new_addr, the_address,
+                     rfc822_parse_adrlist(&new_addr, pf->scratch,
                                   (F_ON(F_COMPOSE_REJECTS_UNQUAL, ps_global))
                                     ? fakedomain : ps_global->maildomain);
                      resolve_encoded_entries(new_addr, *pf->addr);