Summary:	ASTERISK-12872: [patch] make_email_file() uses different values for "cidname" and "enc_cidname" (0013643 issue unresolved)
Reporter:	Tomo Takebe (tomo1657)	Labels:
Date Opened:	2008-10-10 16:14:36	Date Closed:	2011-06-07 14:10:35
Priority:	Trivial	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_voicemail
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) enc_cidname.patch
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. ****** STEPS TO REPRODUCE ****** 1) Use ${VM_CALLERID} in custom subject as well as body 2) Call from a device that doesn't use caller ID names but uses caller ID number 3) leave voicemail to an account with email attachment enabled The resulting email would have different values for the same ${VM_CALLERID} variable: In the subject: "" <1234567890> In the body: 1234567890
Comments:	By: Leif Madsen (lmadsen) 2008-10-14 11:22:00 As this issue appears to be related to a previous issue you worked on, and this looks to be expanding upon that issue to be more consistant, I've assigned this issue to you. Please feel free to set this status back to confirmed and unassign yourself should this not be the case. Thanks! By: Tilghman Lesher (tilghman) 2008-10-14 17:16:04 I disagree.  This is intended behavior.