Procmail trouble migrating to Mavericks - everything delivered to /var/mail/ user

Question

My old hardware died Thanksigving afternoon, so I hastily migrated to the new machine I'd already been setting up with Mavericks. One post-migration problem was that user mail was delivered into /var/mail/<username> instead of into Maildirs. mail.log said it was delivering to procmail, but that's not where mail showed up. Removing (renaming) each user's .forward and .procmailrc files fixed this at the cost of turning off procmail's automatic filing.
In the old setup, each user had a .forward file that said |/usr/bin/procmail, also a .procmailrc that started with
# This causes delivery in maildir format.
DEFAULT=$HOME/Maildir/
In each user's home directory, Maildir was a symlink to /var/spool/imap/dovecot/mail/<some long hashcode>. Back in 10.6, each user owned their mail directory and all its contents.
In Mavericks, the mail directories have moved to /Library/Server/Mail/Data/mail/<some long hashcode>. Those directories are completely owned by _dovecot. I repointed the symlinks, but wondered if the different ownership might be a problem.
One seeming bug I found was that line 45 of /Library/Server/Mail/Config/dovecot/conf.d/10-mail.conf says
mail_location = maildir:/Library/Server/Mail/Data/mail/%u
Since %u is <username> and not <some long hashcode>, I think that should say
mail_location = maildir:/Library/Server/Mail/Data/mail/users/%u
But changing it and restarting dovecot had no effect. Only disabling procmail made mail go where it should.
My bottom line question is, how can I get procmail working again?

Answer 1

Possibly I've answered my own question-and-a-half. My mail is being sieved. For the record:
Setting mail_debug=yes in /Library/Server/Mail/Config/dovecot/conf.d/10-logging.conf put some helpful notes into /Library/Logs/Mail/mail-debug.log. Searching for "sieve" in there revealed that dovecot was looking for per-user sieves as /Library/Server/Mail/Data/rules/<long-hash-code>/dovecot.sieve. That path was specified with %u in the dovecot config, so%u must really mean <long-hash-code>, not <username> as I thought. (That was the half-question.)
So apart from having to create those directories and populate them, sieve was already configured and running as a dovecot plugin.