When accepting a meeting request sent from an Outlook client (not 100% that this is required, but this is where we first started seeing it), the e-calendar-factory will crash.  From an initial backtrace investigation, it's clear that the property PR_SENT_REPRESENTING_NAME_UNICODE is being created but not properly initialized, and then passed into libmapi where a segfault occurs due to an attempted string read of $uninitialized number of bytes.  Backtrace:

+ Trace 226181

$1 = {i = 271, l = 2147746063, dbl = 6.9173879921431666e-310, 
  err = 2147746063, b = 15 '\017', d = 140009491661071, 
  lpszA = 0x7f568004010f <Address 0x7f568004010f out of bounds>, 
  lpszW = 0x7f568004010f <Address 0x7f568004010f out of bounds>, ft = {
    dwLowDateTime = 2147746063, dwHighDateTime = 32598}, lpguid = {
    time_low = 2147746063, time_mid = 32598, time_hi_and_version = 0, 
    clock_seq = "\000", node = "\000\000\000\000\000"}, Restrictions = {
    wrap = "\017\001\004\200V\177", '\000' <repeats 18 times>, "\004\000\000\000\000\000\000\000\004\000\000\000\024\000Jg\024\000Jg\000\000\000\000\000\000\000\300\220}\341C", '\000' <repeats 32711 times>}, RuleAction = {count = 271, 
    ActionBlock = 0x0}, bin = {cb = 271, lpb = 0x0}, MVl = {
    cValues = 2147746063, lpl = 0x0}, MVszA = {cValues = 2147746063, 
    strings = 0x0}, MVszW = {cValues = 2147746063, strings = 0x0}, MVguid = {
    cValues = 2147746063, lpguid = 0x0}, MVbin = {cValues = 2147746063, 
    bin = 0x0}}


Value of mapi_sprop:

(gdb) print *mapi_sprop
$3 = {ulPropTag = PR_SENT_REPRESENTING_NAME_UNICODE, value = {i = 271, 
    l = 2147746063, dbl = 6.9173879921431666e-310, err = 2147746063, 
    b = 15 '\017', d = 140009491661071, 
    lpszA = 0x7f568004010f <Address 0x7f568004010f out of bounds>, 
    lpszW = 0x7f568004010f <Address 0x7f568004010f out of bounds>, ft = {
      dwLowDateTime = 2147746063, dwHighDateTime = 32598}, lpguid = {
      time_low = 2147746063, time_mid = 32598, time_hi_and_version = 0, 
      clock_seq = "\000", node = "\000\000\000\000\000"}, Restrictions = {
      wrap = "\017\001\004\200V\177", '\000' <repeats 18 times>, "\004\000\000\000\000\000\000\000\004\000\000\000\024\000Jg\024\000Jg\000\000\000\000\000\000\000\300\220}\341C", '\000' <repeats 32711 times>}, RuleAction = {count = 271, 
      ActionBlock = 0x0}, bin = {cb = 271, lpb = 0x0}, MVl = {
      cValues = 2147746063, lpl = 0x0}, MVszA = {cValues = 2147746063, 
      strings = 0x0}, MVszW = {cValues = 2147746063, strings = 0x0}, MVguid = {
      cValues = 2147746063, lpguid = 0x0}, MVbin = {cValues = 2147746063, 
      bin = 0x0}}}


Following the trail of breadcrumbs, these fields are set unconditionally in exchange_mapi_cal_utils_write_props_cb (src/libexchangemapi/exchange-mapi-cal-utils.c).  They are set to the values contained in the callback data object passed from ecbm_modify_object (e-cal-backend-mapi.c), but these values are only set if the user is the organizer of the event (otherwise they are null, which explains how we got where we are).

I'm not 100% sure whether these fields are *required* for modifying the object, if so they could be fetched from the ECalComponent used elsewhere in exchange_mapi_cal_utils_write_props_cb (I quickly checked and it seems that the information in comp is correct).  However, it also seems to function properly if we just check for null and not pass the properties at all if they are not set (patch forthcoming)