when searched in multiline and ignorecase as is done for header_filter_rules will match headers with a From: followed by a Sender: with the same address. Thus, putting the two regexps
in a Privacy options... -> Spam filters -> header_filter_rules rule with action Accept will pass a message with a From: and Sender: with matching addresses in either order.
Then following this with a second rule with regexps
^from:(.|\n)*^sender:
^sender:(.|\n)*^from:
and action Hold will hold those remaining messages with both From: and Sender: in either order without matching addresses.
In any case, I consider this 'bug' to not be anything that can be 'fixed' and thus, invalid. Perhaps there is a feature request lurking in here somewhere, but I don't know what or how generally useful it would be.
If you're good with regexps, consider that
^from:. *[\s,<] (?P<femail> [^\s,>] +@[^\s, >]+)(.| \n)*^sender: .*(?P=femail)
when searched in multiline and ignorecase as is done for header_filter_rules will match headers with a From: followed by a Sender: with the same address. Thus, putting the two regexps
^from:. *[\s,<] (?P<femail> [^\s,>] +@[^\s, >]+)(.| \n)*^sender: .*(?P=femail) .*[\s,< ](?P<femail> [^\s,>] +@[^\s, >]+)(.| \n)*^from: .*(?P=femail)
^sender:
in a Privacy options... -> Spam filters -> header_filter_rules rule with action Accept will pass a message with a From: and Sender: with matching addresses in either order.
Then following this with a second rule with regexps
^from:( .|\n)*^ sender: (.|\n)* ^from:
^sender:
and action Hold will hold those remaining messages with both From: and Sender: in either order without matching addresses.
This could work, but a possibly better way to do it is with a custom handler <http:// wiki.list. org/x/l4A9>.
In any case, I consider this 'bug' to not be anything that can be 'fixed' and thus, invalid. Perhaps there is a feature request lurking in here somewhere, but I don't know what or how generally useful it would be.