-
rswindell authored
- REPLYTOLIST (a mime-decoded version of RFC822REPLYTO) - RECIPIENTLIST (a mime-decoded version of RC822TO) - RFC822CC (a mime-encoded version of SMB_CARBONCOPY) - RFC822ORG (a mime-encoded version of SMB_ORGANIZATION) - RFC822SUBJECT (a mime-encoded version of SUBJECT) The RFC822* hfields are only created when necessary: there was a MIME-encoded hfield value received (e.g. by the mailsrvr) for the corresponding hfield. The to_list and replyto_list convenience pointers now point to the MIME-decoded (plain text) version of these header fields, since that's what everyone normally wants to see and use. The MIME-encoded flavors (RFC822*) are stored for relaying via SMTP or POP3 and retaining all data (no normalization or decoding). A new auxattr bit has been defined: MSG_HFIELDS_UTF8 (happens to be the same as P_UTF8 - snicker). This bit will be set in msg.hdr.auxattr when one or more hfield values are in UTF-8 format. When this flag is not set, all hfield values are assumed to be CP437 for backwards compatibility. Since we are using a single flag, all header fields have to use the same encoding (either CP437 or UTF-8). When the hfield values are all plain ASCII, there's no difference between CP437 and UTF-8 and the MSG_HFIELDS_UTF8 flag is not expected to be set, though setting it shouldn't hurt. The RFC822* hfield values should also include US-ASCII text (using MIME-encoding for any 8-bit charsets). smb_get_hfield() function prototype change: the 3rd argument changed from an hfield_t* to an hfield_t**, so that the caller can actually change the hfield type (in memory) if they wish. Nobody seemed to be passing any non-NULL 3rd argument value, so this changed appeared safe to make.
a8709616