#3 alternatives to -j for entries in virtualusertable

[Stuart Thiel]

Currently, if the emails are all coming from virtualusertable entries which don't match up with the usernames for the account (sensible to do, I find), then there's only the -j option available to get around the problem.

Why even check if you need to skip this most of the time?

So, a few things occurred to me.
1) Allow additional arguments to be passed specifying emails that qualify as owned by the receiving account
I think this isn't the best solution, although it was the first that came to mind. aliases/.forward files will get unwieldy and difficult to grasp quickly.

2) Allow additional emails to be specified in another db file
This seems better than my first option, but just moves the bulkiness elsewhere and adds another file.

3) Parse aliases and virtualusertable to automatically determine forwards
This seems like a good solution, but has a few flaws. First, that's a whole lot of parsing and work that has nothing to do with a vacation responder, so it makes the project less cohesive. I also don't know what other ways incoming mail can be accepted, and this is definitely a sendmail-centric approach as I've never used anything else, so that may not work out well.

4) Don't bother caring whether the recipient is actually listed (what if they were BCCd)
I guess this is partially spam protection, but I think it's the wrong approach. An email responder does give harvesters a good opportunity that one might not actually want, but I daresay the average harvester wouldn't find this to be problematic. A better approach is probably for admins to use greylisting or real spam protection. The main idea is that the auto-responder shouldn't be so responsible for the badguys (if this was the reason, not documented in the code), even if an auto-responder offers a unique opportunity to harvesters.