I haven't thought about the interaction a lot yet. The important thing here is that there was subaddress checking when looking up the username and aliases. Once we've got the message heading towards the intended user, and if the user has a Sieve script, the script takes over 100%.
Your proposed solution doesn't feel right, because it allows the remote mail sender to bypass the user's Sieve script. I think your example case is exactly correct -- [EMAIL PROTECTED] -- the Sieve script should take precedence, even if it means ignoring all values, good or bad. libSieve supports an early revision of this draft: http://www.ietf.org/internet-drafts/draft-ietf-sieve-rfc3598bis-01.txt Aaron On Thu, 2006-02-16 at 10:17 +0300, Oleg Lapshin wrote: > Hello > > I try using subaddress delivery: > > SIEVE=yes > SUBADDRESS=yes > > sent message to [EMAIL PROTECTED] > > Current logic: > subaddress code found +SPAM and set mailbox to 'SPAM' -> ok > sieve code run sieve-script and found: > ' else { fileinto "INBOX"; } ' and set mailbox to 'INBOX' > so, message is saving to INBOX > > I think, this isn't what I want ;( > > May be logic must be: > subaddress code found +SPAM and set mailbox to 'SPAM' > sieve code must get this as _default_ mailbox instead of INBOX > so, that message is saved in mailbox, founded by subaddress code > but if 'fileinto "not_INBOX";' was found - save to that "not_INBOX" folder > > For now, I change: > > /* Sieve. */ > config_get_value("SIEVE", "DELIVERY", val); > - if (strcasecmp(val, "yes") == 0) { > + if (source != BOX_ADDRESSPART && strcasecmp(val, "yes") == 0) { > > to turn off sieve scripting, if subaddress was founded > > > What do you think about this? >
