[ingo] sieve filters on addresses doesn't follow expected behavior: reasoning?

[Steve Block]

Todd Merritt <tmerritt at email.arizona.edu> Said:
> I would disagree.  If I enter a filter like if from address begins with
> foobar, I would expect it to match the _address_, not some random text.
>  Consider the inverse of your example.  I want to discard all mail from
> pest at annoyance.com, how can I effectively do that if the only part I
> can filter on is dynamic ?

If you filter on the From: header for pest at annoyance.com with  
contains: it would match exactly how you expect it to. The From:  
header includes both the part before the brackets and the part inside  
the brackets. I see your point if you want to use exact matches,  
because that would break, but the current behavior is also broken  
because I have no option to filter the From: field by anything _but_  
the email address.

On the current filter creation page you can select |From| |contains|  
and then type something in the From field. It really does imply that  
it is checking the whole From: header and not just the email address  
inside <>.

Perhaps ingo needs a user-defined option. A checkbox that says "filter  
by email address only" for example. Or perhaps it just needs another  
drop down option. From and From (address only) for example.

> Steve Block wrote:
>> Hi.
>>
>> I recently installed horde, imp, ingo, and turba from CVS and got

>> everything up and running. Setup was fairly easy and the system   
>> seems to work quite well. My mail server is running Cyrus 2.1.18,

>> and I use sieve for server-side mail filtering.
>>
>> I was having trouble with a few of the sieve filters I created in

>> ingo, however. In particular, the filter I created to sort email   
>> from the server's cron daemon into its own folder did not appear
to
>> be working.
>>
>> I looked at the ingo-generated sieve script more closely and   
>> realized that it was only checking against the From _address_, and

>> not the whole header. I had created the rule to file the email   
>> where From contained "Cron Daemon", since the 'root' email address

>> sometimes sends other mail
>> that should be filed elsewhere. Since the generated script only   
>> checked against the address, the match would always fail and the   
>> message would always end up in my inbox.
>>
>> I checked into the sieve.php file for ingo and found where the   
>> checking for To, From, Cc, or Bcc occurs, and where it switches   
>> into matching by address rather than header. I then disabled that

>> check, told it to match by header, and things seem to be working   
>> the way I expect.
>>
>> So far all this makes sense, except the reason why this extra
check
>> was implemented in the first place. The comment above that check  says:
>>
>> /* Do 'smarter' searching for fields where we know we have

>>             * * e-mail addresses. */
>>
>> but I find this behavior to be anything but smart. I don't believe

>> that one can assume that a user going to the Filters page to
create
>> a filter on the "From" field knows that he should be using an
email
>> address as the criteria. Most mail clients, IMP included, show the

>> person's name in the From field on every email, and this behavior

>> would lead the user, like it did me, into thinking he could filter

>> on anything in From.
>>
>> Not only that, but in this day and age of free email addresses,   
>> some people, including some of my friends, seem to send mail from
a
>> host of random accounts they have opened. One day I may get an   
>> email from 'Your Friend <somebody at gmail.com>', and the next day it

>> might be
>> 'Your Friend <somebody1235 at yahoo.com>'. I should be able to create

>> a filter based on matching Your Friend if I want to.
>>
>> Thus, this clever programming breaks what I believe to be the
>> standard user-expected behavior for filtering by who sent the
email.
>> It eliminates any flexibility in matching on those headers as
well.
>>
>> I checked CVS for when this was implemented, and the changelog for
>> sieve.php when this behavior was introduced has the following   
>> comment: "When the From/To/Cc/Bcc fields are selected in the   
>> condition, it
>> generates the same type of test as for the rest of the header
tests.
>> This isn't ideal because it includes the text outside of the <>'s.
>> Instead, use Sieve_Test_Address instead of Sieve_Test_Header if
one
>> of those fields is selected."
>>
>> I fail to see how this wasn't ideal. What's more, I fail to see
how
>> the change is ideal, even if the original implementation wasn't  either.
>>
>> I do see that this change was made over 2 and a half years ago, so
maybe
>> I'm the only one who finds this frustrating. Obviously I have
dealt with
>> the problem for myself, but I wonder if the reasoning behind the   
>> original change should be revisited, and better filter generating

>> behavior introduced.
>>
>> I know this message was long, so thanks to those who made it all   
>> the way through. I hope I was coherent enough to get my point   
>> across without
>> sounding like too much of an asshole.
>>
>> Regards,
>>
>>

-- 
Steve Block
http://steveblock.com/
http://ev-15.com/
scblock at ev-15.com