... In particular, I have
poll pop3.mydomain.com ... account 1 settings
skip pop3.mydomain.com ... account 2 settings
and the only way I can make a poll of account 2 is by editing the
config file before polling.
I thought the cure for that sort of thing was to run two (or more)
instances of fetchmail, each with a different setting of FETCHMAILHOME.
The config language is a nightmare, and pretty illogical (e.g.
settings which I think should be settable globally and inherited
by all accounts, like 'ssl' for example, aren't; and working out
which settings apply to hosts and which to users has had me
digging in the source code more than once).
I haven't been reduced to digging in the source, but have had some
trial and error finding out whether certain settings are "host" or
"user". This is largely a matter of incomplete documentation :(
To be fair to fetchmail, in the olden days it *did* offer direct
to mailbox delivery, and it was ESR's decision that the design
would be made much cleaner by having delivery to a local SMTP
daemon instead. Then slowly, things crept back in like delivery
via a pipe to procmail, delivery by invoking an MTA command-line
directly, delivery by LMTP... but things I *actually* want, like
delivery to a Maildir, aren't there.
As long as we have the ability to hand off to a specified agent,
I would think it preferable -- at least, more modular -- to use a
different external agent for each type of local mail store, rather
than to try to amalgamate the lot of them into fetchmail. You can
have fetchmail invoke the same local delivery program that sendmail
would use to write to a maildir.