Inbox rules don't match transport headers with newlines

schiffermtq

Hi,

I’m trying to define an inbox rule for a List-Id header, but I haven’t found a way to match a value that contains a newline. Mailman will often generate headers like the following, including a newline followed by a tab character:

List-Id: Patches and discussions about the oe-core layer
	<openembedded-core.lists.openembedded.org>

I can filter using the first part List-Id: Patches and discussions about the oe-core layer, but that is rather ugly for mailing lists with very unspecific descriptions like “Discussion about the project”. For the particular case of Mailman’s List-Id, another workaround is to filter for another header like List-Post: <mailto:openembedded-core@lists.openembedded.org>.

Am I overlooking something, or is it not possible to match a value spanning multiple lines? If I’m interpreting the SMTP standard correctly, newlines followed by whitespace can just be ignored. I’m not sure how tabs are supposed to handled here though - I’m often seeing tabs after line breaks where a space would appear in an unwrapped line:

Organization: Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way,
	Swindon SN3 1R

Possibly whitespace should be normalized to a single space in such cases before a value is handled by rules?

Used versions:

WebApp: 3.5.10.2410+1355.1
Kopano Core: 8.7.82

jengelh

The WebApp rule “includes these words in the transport-headers” leads to a restriction like {RES_CONTENT, PR_TRANSPORT_MESSAGE_HEADERS, Way, Swindon} being added. This is far from ideal because

Transport Headers contains everything and one easily runs into a false positive
Transport Headers are stored by kopano-dagent in verbatim form with \r\n\t, and kopano-gateway expects them to be like that to satisfy the HEADERS request of the IMAP protocol. Changing the folding is probably not ideal, because that would change the message, which is something that perhaps wants to be avoided.

The proper way (according to the Exchange ecosystem) is to test for a different property, namely the one header you are actually interested in. The restriction is {RES_CONTENT, PS_INTERNET_HEADERS:Organization, Way, Swindon}. That would solve problem A, and avoids B too. For historical reasons, dagent needs to be told to index those (kopano-dagent.cfg):

indexed_headers = Organization

and then someone needs to spruce up WebApp to use PS_INTERNET_HEADERS:x.