Re: [Fetchmail-users] fetchmail-6.5.0 questions

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

Am 30.10.24 um 17:06 schrieb Ken Moffat via Fetchmail-users:
> Hi,

Hi Ken,

thanks for reaching out.

>
> I see that fetchmail no longer supports using an MDA as SMTP
> fallback.

Yes. That only means there is no fallback from SMTP to MDA if the former
fails. The plan is to always behave consistently and not try to do A
today and in adverse situations we try B and you have to start looking
where/how your mail ended up, because B wasn't equivalent to A (and
fetchmail cannot prove or disprove that). I don't like such surprises.
So I threw the fallout behavior out without removing MDA or SMTP.

Assume you use Postfix. What if you had procmail as a fallback but
Postfix uses its own local(8) without procmail? Then procmail would
behave differently from Postfix's local... or some messages would be
logged by Postfix, others would not.

You configure an mda or use --mda on the command line, fetchmail uses MDA,
you don't use mda or --mda then fetchmail uses SMTP (default) or LMTP or
whatever else you configured.

> Sending mail to lists, and getting the incoming, for a home user has
> become increasingly complex and I try not to change my setup. As
> best I can understand (several years since I had to change it apart
> from a password), I'm doing the following: (one human user on my
> systems).
>
> 1. postfix on home server, running as servername.mydomain.
>
> 2. outgoing: postfix connects to my ISP's server using Cyrus-SASL.
>
> 3. incoming: a cron job to run fetchmail authenticating to my ISP
> and retrieving POP3.
>
> I have always specified --enable-fallback=procmail, but I see that
> my fetchmailrc has a comented-out invocation of procmail with a
> comment that procmail is not needed for that if the mail server is
> correctly setup.
>
> Am I worrying unnecessarily ?

Maybe. As long as you notice in some - for you, anyways - reasonable
timeframe that your Postfix is down, this should be good. I found that
on reasonable distros (I have used Fedora Linux and FreeBSD in the past
years and have been quite content) there aren't Postfix surprises for me.

...but fetchmail should notice that it has not succeeded in retrieving
those messages and will therefore not delete them and retry them later
(except maybe if it uses LAST on your POP3 server, in that case you
could specify --uidl or uidl).

> I see that procmail was originally specified so that if the mail
> server was not responding, mail would be processed by procmail. I
> assume (if I do not need to change anything) that if my local server
> does not respond then the mail will just be queued ?

If your default is to talk to SMTP, it's re-fetch the same message
later, do not delete it.

>
> En passant (testing configure on a desktop without kerberos):
>   CFLAGS:   -g -O2 -I/usr/kerberos/include
> looks a bit odd : /usr/kerberos ?

Yeah, we've had such stuff needed in various circumstances, ./configure
adds it, either because it's one of the search paths you have for a
./configure --with-kerberos like option, or as a leftover workaround
from Red Hat Linux 9 (must have been in the early 2000's) I forgot to
remove.  At that time, some SSL implementations needed such an option to
find krb5.h. This shouldn't be in use today, but also in
/usr/kerberos/include there shouldn't be stuff that disturbs us. Too
late for 6.5.0 now, should've known during the betas then I could have
done something...

We'd need to look at your config.log and/or console output, together
with configure.ac, to see what's there, but if fetchmail behaves
normally and fetchmail -V doesn't emit strange things, you're probably good.

HTH
Matthias