[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

symbol() vs. symbol_db() usage for full name lookup in mkSender()




This is about a problem we have been having with the "From:"
field of messages produced by MUAs such as mail and elm  ever
since we upgraded from  2.99.49p8 to 2.99.50s2. The problem
persisted with upgrades to 2.99.50s11 and 2.99.50s15.
With 2.99.49p8 (and previous versions)  mail produced by such 
MUAs  used to have a "From:" field in the delivered message 
as follows:
 
From:   "Eugenia Distefano" <eugenia@eecg.toronto.edu>
 
Now instead the the "From:" field is missing the full name
and looks like:
 
From:   eugenia@eecg.toronto.edu
 
By stepping through the execution of the router code, it appears
that sp_lookup() of spt_fullnamemap in mkSender() (router/rfc822.c) 
always returns a NULL -- even though the trace had previously shown 
that the full name had indeed been stashed in spt_fullnamemap in a
prior invocation of uidpwnam().
 
The following change in router/rfc822.c seems to fix the
problem. [Line number refers to zmailer-2.99.50s15,
but the same change works in all the other zmailer-2.99.50
snapshots mentioned above.]
 
866c866
<       } else if ((spl = sp_lookup(symbol(name), spt_fullnamemap)) != NULL) {
---
>       } else if ((spl = sp_lookup(symbol_db(name,spt_fullnamemap->symbols), sp
t_fullnamemap)) != NULL) {
 
 
Do others observe the same problem? Would the above change break
anything? Why is symbol() used instead of symbol_db()? Shouldn't
spt_fullnamemap already have been initialized at this point? In
our case, symbol() seems to consistently return the wrong key in
the above statement.
 
Thanks
 
        -e
 
 
[The source was compiled on Solaris 2.5.1 with the following config
options:
 
./configure --prefix=/var/zmail --with-postoffice=/var/spool/postoffice --with-m
ailbox=/var/mail --with-logdir=/var/log --with-zmailer-conf=/etc/zmailer.conf --
mandir=/local/man --libdir=/local/lib --includedir=/local/include
 
Also, sometime --with-gcc (2.7.2) and --with-libmalloc=malloc
were included, with no difference in the observed results for
the purposes of the problem at hand.]