User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030713 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030713 Filtering on the reply-to: field of a message would be nice. Reproducible: Always Steps to Reproduce: A filter cannot be created that operates on the reply-to: field. Actual Results: A filter cannot filter on the reply-to: field of a message. Expected Results: Create a filter on the reply-to: field of a message.

Mailnews\Tools\Message Filters\ Open the drop-down box "subject.." (contains) and select costomize and create "Reply-To"

Was a user training issue. :-)

You could still leave this open if you want this entry by default but I think it's o.k. using the customize way.

There is a work around using "Customize" but reply-to being available as a defaul option to filter on would be a nice enhancement. :-)

I also whould like this to be an option instead of being forced to use a custom filter.

Not only whould I like it to be a default option. But there is no indication when using the custom filter field that it is active. The subject goes to a light color. Im going to file this under a different bug, because the filter rule doesnt work anyway when using the custom filter, either that or it is case sensitive.

Even with "Customize", we cannot check if the "reply-to" address is in one of my address books.

*** Bug 259104 has been marked as a duplicate of this bug. ***

Since Reply-to is supported as a default available field when addressing, it makes sense that it should also be a default available field for defining filters; and particularly, it makes sense (per comment 7) that the address in this field should be checkable against the address book. (In reply to comment #6) > there is no indication when using the custom filter field that it is active. > The subject goes to a light color. I can't understand any of this -- I don't know what the intended meaning is of "no indication ... that [the custom filter field] is active" nor of "The subject goes to a light color". In creating a filter with this custom field, I noticed no unintuitive UI behavior. > Im going to file this under a different bug, because the filter rule doesnt > work anyway when using the custom filter, either that or it is case sensitive. and I do not see the problem of filtering on a custom Reply-To -- I have defined a filter on the custom Reply-To, and it works, case-insensitively. (Note that the Begins With and Ends With filters are known to be case-sensitive -- bug 202558.)

sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.

Filter on "Nobody_NScomTLD_20080620"

rkent, would you accept a patch for this if I tried to make it?

But it must not become controversial as in bug 586101 :) There must be clear decision like "yes, we want a separate field in the filter menu that operates solely on reply-to". And we could also add it to the "All addressed" item.

(In reply to :aceman from comment #12) > rkent, would you accept a patch for this if I tried to make it? I don't really feel like I can make this decision on my own. BMO has never been a good place to make these decisions either. Perhaps a ruling by bwinton? Or is this sort of thing appropriate for tb-planning? I think you are wise to ask for clarification before you do the work. As I see it: Comment 7 is the strongest argument in favor of this. I don't really buy the argument that a custom search term is too hard to do. "Reply-to" is an advanced feature, surely the advanced user could figure out a custom term. But personally, I don't see the value of all of the complex variations of addressing filters that already occur in the search term list: To, CC, To or CC, From To CC or Bcc. Now this bug wants add one more. My search term list is already almost to the height of my screen with my many existing custom search terms, another (useless to me) required term is only an annoyance. But that is my narrow experience only.

(In reply to Kent James (:rkent) from comment #14) > (In reply to :aceman from comment #12) > > Comment 7 is the strongest argument in favor of this. I don't really buy the > argument that a custom search term is too hard to do. "Reply-to" is an > advanced feature, surely the advanced user could figure out a custom term. Sure, but if I read comment 7 correctly, adding a custom term will not make this searchable against addressbook, which is a major loss of functionality. I am strongly in favor of adding reply-to to complete the list of filters. Arguments in favor: 1) real search terms can be searched against AB, while custom search terms cannot (comment 7) 2) Reply-to is supported as a default field when addressing, so it certainly should be available as a default field for filtering, too (comment 9) 3) Both "Search messages" and "Filters" are advanced features, so they should be feature-complete for the advanced user (but I'll offer a new and reordered set of filters soon to make it easier for normal users, too). (Personally I don't even think that Reply-To is so advanced, more like extended default set of headers). > But personally, I don't see the value of all of the complex variations of > addressing filters that already occur in the search term list: To, CC, To or > CC, From To CC or Bcc. The pre-installed combined addressing filters (currently: To or CC | From, To, CC or BCC) have a very high functional value that cannot be achieved using manual combinations of the single headers, because the single headers have a severe limitation when it comes to combined searches: Scenario (and a pretty common one, I think!): User wants to filter on all mail - involving a specific person (as sender OR recipient) - AND involving a certain subject Person (Sender OR recipient) requires an OR search subject requires an AND search (Sender OR recipient) AND Subject requires both AND and OR in the same search. The current UI does not allow for mixing AND and OR searches, so the combined person filters (with implicit OR) are the ONLY option that allows for this type of search. > Now this bug wants add one more. My search term list > is already almost to the height of my screen with my many existing custom > search terms, another (useless to me) required term is only an annoyance. > But that is my narrow experience only. Well, citing your "many custom search" terms as an argument against adding a default term to the list is a bit strange, because that could be used against any filter terms on the default list. A long list is not necessarily clutter; it's clutter only when it's not well-structured and difficult to parse (which is true for the current list). I'll offer an XUL demo of a completely reordered list with better captions and some other tricks soon, which imho reduces the clutter-factor of this list significantly while improving the usefulness, completeness and ease of use for both casual and advanced users.

(In reply to Thomas D. from comment #15) > 1) real search terms can be searched against AB, while custom search terms > cannot (comment 7) That's "real" as in "inbuilt"/default set...

If the argument in favor is comment 7, then perhaps the correct solution is to add address book searching to custom headers. I don't think that would be very difficult.

(In reply to Kent James (:rkent) from comment #17) > If the argument in favor is comment 7, then perhaps the correct solution is > to add address book searching to custom headers. I don't think that would be > very difficult. I think the most common use of the filter would be as described in this GS topic.https://getsatisfaction.com/mozilla_messaging/topics/auto_reply_going_to_wrong_address Ie web page identifies the "sender" via reply-to:

(In reply to Matt from comment #18) > (In reply to Kent James (:rkent) from comment #17) > > If the argument in favor is comment 7, then perhaps the correct solution is > > to add address book searching to custom headers. I don't think that would be > > very difficult. > > I think the most common use of the filter would be as described in this GS > topic.https://getsatisfaction.com/mozilla_messaging/topics/ > auto_reply_going_to_wrong_address Ie web page identifies the "sender" via > reply-to: Isn't that bug 655428?