Re: [Fetchmail-users] Password length restriction [getting slightly OT]

[Eike L. <zp...@gm...>]

On Wednesday, 15 July 2020 15:57:17 -04 Carlos E. R. wrote:
> On 15/07/2020 19.02, Eike Lantzsch wrote:
> > On Wednesday, 15 July 2020 12:32:49 -04 Matthias Andree wrote:
> >> Am 15.07.20 um 16:42 schrieb Zsolt Barat:
> >>> I'm using following fetchmail version:
> >>>
> >>> 6.3.26+POP2+GSS+RPA+NTLM+SDPS+SSL+OPIE+NLS+KRB5
> >>
> >> 6.3.X is a museum piece from 2013 and unsupported on this list, and
> >> I
> >> don't care to look back to what it might have done for such
> >> questions.
> >>
> >> Password buffers in 6.4.X are allocated dynamically, and there may
> >> be
> >> undocumented limitations on your mail service provider's (MSP's)
> >> end.
> >> 30 certainly does not seem too long to me, but might be for your
> >> MSP.
> >
> > If you don't mind my AOL-post ...
> > There are some distributions which are not including any recent
> > fetchmail version.
> > I really don't get it why e.g. openSuse comes with 6.3.26 fetchmail.
>
> That's intentional and documented policy.
>
> I guess you are talking of openSUSE Leap 15.x, which is an LTS, thus
> it simply can not change the versions of the core packages during the
> long term period (ie, when it goes to Leap 16), unless the commercial
> distribution from which it derives the core (SLE) switches version
> first.

Of course I was referring to the openSUSE distribution, which the OP
mentioned in his post.
Leap 15.1 dates 7 years back? No, there seems to be a gap of fetchmail
development upstream between 2013 and April 2020.
I had the impression that the SuSe-webpage adveritsed it as the latest?
Actually that would be 15.2.
It didn't really say LTS. That detail escaped me. Maybe I perused it
only too cursory.

Whoever might be to blame - putting blame on s/o does not help - users
need to be aware that distributions do not / cannot / don't want to
contain always the most recent upstream products.

OK, whatever, I'm not using SuSe (not anymore since 2001). I won't dive
into their release cycle any deeper. I already need to keep track of
"stable", "testing", "unstable", "experimental", "LTS" and "release",
"stable", "current" and snapshots - that's enough - oh and "rolling
release cycles". Is the release a ball or a steam roller? Not telling
any names SIMS[1]. So the OP may be forgiven to ask for support
on a s/w product of 2013.
Thanks for the clarification.
>
> However, there is the server:mail repository which has 6.4.1
>
> And there is openSUSE Tumbleweed which also has 6.4.1
Tumbleweed hints on a "rolling release cycle" SCNR or is it?
>
> > If mayor producers of Linux Distros are going on with this practice
> > questions like the one of the OP are bound to appear again and
> > again.
> > It seems to be a widely common assumption that the latest distro
> > comes with the latest ports - not at all, not at all.
>
> Of course.
>
> > Not good.
> > Not long ago OpenBsd e.g. was still with 6.3.xx when 6.4.xx was
> > already available upstream. Now OpenBSD 6.7 Release comes with
> > 6.4.3. At least on OpenBSD compiling the latest upstream version fo
> > fetchmail is straight forward and easy.
> > On Linux I don't know but would be worth a try.
> > Anyway, updating to the latest upstream version before asking for
> > help, is always good practice.
> >
> > Anyway I admire your patience giving a helpful answer despite the
> > OP's question based on outdated software.
> > All the best to y'all

Have a nice day

[1] snickering into my sleeve
--
Eike Lantzsch ZP6CGE