A bug was reported to the upstream BTS detailing a flaw in the way evolution
accepts IMAP server data.  To quote the upstream bug:

    The "SEQUENCE" value in the GData of the IMAP code (camel-imap-folder.c)
    is converted from a string using strtol. This allows for negative values.

    The imap_rescan uses this value as an int. It checks for !seq and
    seq>summary.length. It doesn't check for seq < 0. Although seq is used as
    the index of an array.

    This means that a negative index number can be fed to the array lookup by
    altering the output of an IMAP server.

    I'm marking this as a blocker (very very serious) security bug as this is
    remotely exploitable (I can put shell code in the UID field of the IMAP
    code, and make it execute on the victim's computer, as at the seq'd field
    of the index a g_strdup of the UID is written to memory. By carefully
    calculating the negative value and overwriting the instruction pointer
    near the array's start, I can let it point to that memory and get it to
    execute).

This flaw is only exploitable via a man in the middle, or a malicious IMAP server.