I recently tackled this same problem. Turns out that deliver needs to
be called with the -m option 9.e.g 'deliver user -m foo'. If this is
done, deliver will correctly drop the mail in the right mailbox; if
the mailbox doesn't exist, the mail goes to INBOX.
Now, actually getting procmail/sendmail/exim/whatever to appropriately
call deliver can be annoying. I use exim and ran into two problems.
1) exim doesn't remove the '+' symbol from the suffix, so it kept
trying to call 'deliver kidder -m +foo' which, of course, doesn't
work.
2) exim downcases all email addresses, by default, which deliver is
case-sensitive about the mailbox names.
Problem 1 was solved with some interesting script hacking, in order to
properly strip off the '+'. Specifically:
#!/bin/sh -f
folder="`/bin/echo \"$2\" | /bin/sed 's/^+//'`"
exec /usr/sbin/deliver -e "$1" ${folder:+-m} ${folder:+"$folder"}
Problem 2 is less critical. I can turn this downcasing off, but that
means that mail to 'KiDdEr' doesn't get delivered anymore (so much for
my membership in the 3l374-crowd); a minor enough nuisance, but one
I'd love to see fixed.
-Brian Kidder
Juan Leon <[EMAIL PROTECTED]> writes:
> --On Sunday, March 11, 2001 11:26 PM -0500 Ken Murchison <[EMAIL PROTECTED]>
> wrote:
>
>
> >
> >
> > Juan Leon wrote:
> >>
> >> Can sieve be told to file mail to user+foo into folder
> >> foo, for any value of foo, for as long as the
> >> folder exists? Basically, I'd like to do something like:
> >>
> >> if anyof (address :matches ["Cc","CC","To","TO"] "user+*@*") {
> >> fileinto "INBOX.$1";
> >> }
> >
> > This can't be done. Sieve does not have variables.
> >
> > However, if the ACL on 'foo' is set so that 'anyone' has posting ('p')
> > privileges, you don't need a Sieve rule like this. Either an explicit
> > or implicit 'keep' will file the message appropriately (the same way it
> > would if you did not have a Sieve script).
>
> I thought "keep" puts the message in the default INBOX, not
> in the mailbox whose name comes after the '+'. The sieve
> documents seem to confirm.
>
> Thanks for your answer!
>
> Juan
