Failed authentication breaks imports

Problem/Motivation

If you configure the mailhandler feeds parser to 'Abort if authentication fails' the entire mail queue processing aborts.
For example, if you have 5 messages in the mailbox and the second message does not pass authentication, then the 3rd 4th and 5th messages do not get processed at all.

Proposed resolution

There are a number of ways that this could be solved, and I would love to get your opinion on the solution that you think might make sense.

1. Use the current UI (with slightly different wording), but have the parser simply skip messages that fail authentication.
   This may be the simplest solution. In the parse method of MailhandlerParser instead of throwing an exception - purge the message as you normally would, but do not run the commands for that message.
2. Provide an a different option for users to choose to skip messages that failed authentication.
   Leave the current option as is, but provide a different option to simply skip messages that fail authentication. (same as 1) purge the message as you normally would, but do not run the commands for that message.)
3. Expose a 'command' that implements this skipping behaviour.
   Instead of skipping the message entirely before parsing commands are run, allow the message to move to the command parsing phase, and optionally 'skip' the message if a 'skip' command is enabled/configured.
4. Something else

Currently a work around we've implemented was to use hook_feeds_after_parse to simply remove the items that were created, but had not passed authentication. While this works and does what we want, it is still done after a bunch of unnecessary parsing has occurred. In other words its not the most efficient place to keep messages from being imported as nodes.

Another option would be for us to write and release our own FeedsParser that extends MailhandlerParser and just have our own way of dealing with authentication problems, but I'd rather work with you to come up with a solution that makes sense for 90%+ of the use cases.

The first option proposed here would be a farily simple, but perhaps you had a different use case in mind when you exposed that option.

The second option is equally simply to implement.

The third option isn't ideal (for the reasons stated above), but it is a bit more modular.

Remaining tasks

Decide on a preferred solution and roll a patch.
We're glad to do the work of generating the patches depending on what solution you think might be best.

User interface changes

Possibly exposing configuration options to feeds ui.

API changes

None, unless we created a new 'skip' command.