[asterisk-bugs] [Asterisk 0013670]: [patch] make_email_file() uses different values for "cidname" and "enc_cidname" (0013643 issue unresolved)

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13670 
====================================================================== 
Reported By:                tomo1657
Assigned To:                Corydon76
====================================================================== 
Project:                    Asterisk
Issue ID:                   13670
Category:                   Applications/app_voicemail
Reproducibility:            always
Severity:                   trivial
Priority:                   normal
Status:                     assigned
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases): 1.6.1 
SVN Revision (number only!): 148330 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-10-10 16:14 CDT
Last Modified:              2008-10-14 17:16 CDT
====================================================================== 
Summary:                    [patch] make_email_file() uses different values for
"cidname" and "enc_cidname" (0013643 issue unresolved)
Description: 
Hi Corydon76, we appreciate your work and thank you for the newest patch,
but unfortunately it does not resolve the original issue of ${VM_CALLERID}
variable yielding different strings within the same email between the
subject and the body.

The condition is when devices like a PRI has no Caller ID Name but has a
valid Caller ID Number.  The newest patch for prep_email_sub_vars() added
the condition:

(!ast_strlen_zero(cidname) || !ast_strlen_zero(cidnum))

but this always results to TRUE for such cases because cidnum is valid. 
This is fine by itself, but the problem originates from make_email_file()
that uses two different variables (cidname versus enc_cidname) with
different values (empty string versus NULL) within the same run.

This results in:

Subject: Message from "" <1234567890>
Body:    Message from 1234567890

If the custom text is set to "Message from ${VM_CALLERID}".
I agree that an empty string could purposely be sent as the caller ID name
in some cases, but since the PRI is sending no Caller ID Name at all (but a
valid caller id number), the subject should not be correct.

Basically I believe "enc_cidname" in make_email_file() should *NOT* be an
empty string when "cidname" variable is NULL; it should also be NULL when
being passed to prep_email_sub_vars().

The catch is that enc_cidname is later used in the IMAP headers so it
should not be NULL all the time.  

We can do this by passing NULL to prep_email_sub_vars() instead of
"enc_cidname" which is an empty string.  This patch attached, and is
essentially the same as the original one suggested in case 13486.

Like how you mentioned the core shouldn't be modified for this,
prep_email_sub_vars() probably should not try to fix what make_email_file()
does wrong.

The most complete fix may be to set enc_cidname to a pointer rather than a
const string and modify strip_control() to operate on the pointer while
making sure IMAP header substitution works, but this sounds rather
complicated for a simple issue.

Sorry for bothering you again but I really do think this is an unintended
behavior / bug that ruins the useful variable VM_CALLERID that's supposed
to take out the callerid name when it's NULL.  Thanks again.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
duplicate of        0013643 [patch] VM_CALLERID yields different re...
====================================================================== 

---------------------------------------------------------------------- 
 (0093652) Corydon76 (administrator) - 2008-10-14 17:16
 http://bugs.digium.com/view.php?id=13670#c93652 
---------------------------------------------------------------------- 
I disagree.  This is intended behavior. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-10-14 17:16 Corydon76      Note Added: 0093652                          
======================================================================