Re: [Fetchmail-users] Is it possible to have fetchmail chk /var/spool/mail/

[Matthias A. <mat...@gm...>]

Am 15.01.22 um 17:15 schrieb Peter Pentchev:
> On Sat, Jan 15, 2022 at 04:26:11PM +0100, Matthias Andree wrote:
>> Am 15.01.22 um 16:21 schrieb hput via Fetchmail-users:
>>> If it is possible to have fetchmail check for mail at
>>> /var/spool/mail/MY-USER
>>>
>>> Can anyone give me a few clues as to how that would be entered into
>>> ~/.fetchmailrc along with the polls of pop3 servers.
>> Harry,
>>
>> Why would anyone need that?
> It is possible that their setup is the same as mine here - fetchmail
> handling a couple of remote accounts and delivering to a Maildir in
> my home directory, and me wondering what to do with the messages that
> my local system is sending to me - cron reports, apt-listchanges after
> updates, sbuild logs, etc. For the present I've made a symlink making
> it easier to point Mutt at it every now and then, and that's enough
> for me personally.
>> /var/spool/mail/$USER is traditionally where fetchmail would *PLACE*
>> downloaded mail by means of a mail delivery agent or mail transport
>> agent, not *FIND* it.
>>
>> Consequently, fetchmail cannot do that, and it is unlikely it ever will,
>> because that would be reversing the purpose. It is way out of scope.
> Of course, one *could* run a local POP3/IMAP server with a simple
> configuration that only provides access to this one account and
> this one mailbox... It might be a bit of overkill, but it would allow
> fetchmail to query it and move the mail somewhere else.

Guys,

after reading through Russell's and Peter's replies,

sorry for not making clear that my "why" question was a rhetorical and
suggestive question.
My implication was "nobody should need that", on the assumption that one
should not use third-party software (= fetchmail) to patch around what I
perceive as local configuration inconsistencies. I surely would NOT want
my system to generally, excuse me, litter my mail around to various piles.

Thanks for imagining some creative approaches on how *not* to configure
a system.

Further thoughts on why my "no" isn't just a simple brush-off:

* it takes quite a bit of hoop-jumping (meaning more effort than just
using default settings) to make fetchmail deliver to *different* place
from where the system would send locally-originating email.
   Default is to talk SMTP to localhost and ship to the user invoking
fetchmail, and I do not see how that would then differ from delivery of
locally-originated mail, unless someone deliberately set it up for some
purpose.
   Alternatively, fetchmail could use the same MDA as the rest of the
system.

* for locally-originated mail, my expectation is that the mail delivery
mechanism (or local mail server) allows for configuring where your mail
goes.
If it does not allow that, swap it out and install software that serves
the purpose. That serves both (1) unifying where mail goes no matter if
fetchmail fetches it or the local system generates it, and (2) the
purpose of forwarding somewhere else. Consistently.
Traditionally, we have used ~/.forward files, which also supported
pipe-syntax to feed the messages into configurable software, for
instance, maildrop.

* if your distribution only ships a dumbed-down local delivery agent,
complain there.

* if you have multiple mail servers competing for the various inbound
mail paths, then either fix that by removing one and transferring some
equivalent configuration to another, or align their configurations.


Does that leave any reasonably valid use cases outside laziness to "get
my system configured consistently and properly", and that would fall
within fetchmail's scope "fetch mail from a remote system via some
network protocol"?
Note I am sking "reasonably valid", not "freakingly astonishingly
strangely imaginable" purpose.

Regards,
Matthias