I'm taking myself off the notify list so that I'm not tempted to keep 
defending my claim.

I don't have the resources to convert my suggestions into patches, and 
I didn't think any comments I could add would clarify or otherwise help.



My intent in opening this ticket was to help the Horde project.  I 
found an aspect of the software which is confusing.  The problem I 
described is real.  Nothing about what I reported is inaccurate, and 
both my wife and I were confused by the program.  I don't see why this 
ticket should be closed.  There's no need to fix it right away, but 
until the problem goes away, why not track it as a problem?  Maybe 
someone new to the project will look through the tickets looking for 
easy problems to solve, like changing the contents of menus to be less 
confusing.  Or maybe someone more experienced will look for problems 
whose preferred sollution is hard with the current framework, so they 
can find ways the framework could be improved to make those solutions 
easier.



There's no reason why you should feel compelled to invest any effort 
in the problem, but don't reject a ticket just because you don't want 
to do it.  Reject it because it's not reproducable.  Reject it because 
the user is insane, which I'll admit is a possibility. If it's 
insanity, be more clear in that respect.  Don't reject it because the 
user hasn't fix the problem themselves yet.



My problem is 'solved' for me in that I have a work-around (use the 
right field name), but the root problem itself is still there.   
There's no cost to leaving a ticket open if the ticket is describing a 
real problem regardless of whether it's UI, documentation or a 'bug'.



Anyway, leave the ticket 'rejected' if you want, but you're wasting 
information if you do.  Noone is going to look through rejected 
tickets looking for real problems.  This problem will only get fixed 
if someone knows about it and wants to fix it, or if some unrelated 
change makes the problem moot.  I suggest you leave the ticket open, 
and at lowest priority, until someone determines that the problem is 
not real or is fixed.



And if my input is not considered helpful, then I appologize.  I have 
nothing but the highest hopes for the Horde project, its modules and 
its developers.

Moving back to rejected since it's been a month and no further 
feedback or patches have appeared. If they do they can be handled and 
the ticket re-opened if necessary.

As for the order, this can be changed via the config/fields.php file.   
Additionally, the text displayed to the user can be altered via the 
'label' parameter located in the same file.  Suggestions on improving 
the labels/order in the default fields.php.dist file are welcome.
This is not possible with the current ingo setup.  As mentioned 
previously, the current behavior (and the way the UI is setup) is that 
the user selects either a header, body, or size of the message to 
filter on.  There is currently no method of indicating a conditional 
search pattern (i.e. "if Sender is not available, filter on From").



That being said, this could be added by defining a new 
INGO_STORAGE_TYPE_* entry.  But this will require some coding (patch 
would be great).
If you want to filter on other headers, you can either add the header 
to the list in config/fields.php or the user can add it themselves via 
the 'self-defined header' option.
This still isn't a "bug".  Bug means the software is behaving 
incorrectly given the proper input.  In your case, the software is 
behaving incorrectly because you are giving it incorrect input because 
you don't understand what the input should be.  Thus, the UI or 
documentation needs to be improved.  As stated above, it is not even 
possible to do some of what you want the program to do which, by 
definition, is an "enhancement" not a bug - if the code doesn't even 
exist, it can't be buggy.



I will reopen this ticket for feedback and possible patches.

Everything you say is true, but few users of web mail will understand 
the difference between Sender and From, and will naturally think (as I 
did) that "Sender" meant "the source of the message".  I've been 
sending and receiving email since '92 and I've never used the Sender 
field on purpose.  I didn't even know it was an official field until I 
read the response to my bug report.



The RFC gives the example of a secretary sending on behalf of a 
manager, where the From contains the manager and the Sender contains 
the secretary.  It's certainly reasonable to think someone would want 
to filter on this distinction, but it's not reasonable to expect every 
Ingo user to understand the distinction, to remember the correct 
meaning, or to want to filter this way frequently.



Worse still, Sender comes first in the drop-down of fields, and 
Subject comes between it and From:



     To

     Sender

     Subject

     From



So as a first measure I would propose putting From at the top of the 
list.  As a second measure I would propose adding clarifying text 
after the field name:



     From     (message author)

     Sender (not message author)

     To

     Subject



Also, since the RFC recommends against specifying a Sender when it is 
the same as the From, how about filtering on From when Sender is 
absent instead of just failing without a heplful indication of why.



Furthermore, the list of fields is hardly exhaustive (what if I want 
to filter on Reply-To?), so how about having a checkbox to enable 
infrequently-used fields like Sender and Reply-To, and when the box is 
unchecked, just show the "normal" filtering fields, From, To, Subject, 
Body, X-Spam*.



I don't think a documentation patch would be any help since I would 
have no idea where to look in the documentation for why my mail didn't 
get filtered when I specifically told Ingo to move messages around by 
what I thought was "who sent me this".



In any case, this IS a bug in the sense that the program didn't do 
what I expected.  Just because it's behaving "correctly" doesn't mean 
it's behaving "well".  Hiding behind standards in the face of user 
confusion strikes me as bordering on what Steven Covey refered to as 
"Malicious Obedience".

'Sender' is a perfectly valid MIME header to filter on (see RFC 2822 
[3.6.2]).  Sender should most definitely *not* filer on the From 
address because that is not what the user is asking to do - if a user 
wants to filter on the from header, they should create their own from 
filter.  If you would like to provide a documentation patch if you 
find this confusing, that would be fine.  But this is not a bug as 
ingo is doing exactly what it is supposed to do.

Wrong queue! - imp does not do filtering.

This may be a mis-understanding about the meaning of filtering on 
Sender.  I thought filtering on Sender would cause the filter to make 
a best effort guess at who the sender really is and match against 
that.  Instead it just didn't seem to match anything.



The solution might be to better document the Sender field (perhaps a 
description in the field drop-down?), or it might be to make Sender an 
alias for From...



This is a VERY low priority bug. :)



Robert de Forest