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

[Todd Merritt]

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 ?


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,
>
>