Re: Whats chances of getting libTLSv1.3 for stretch
On Thursday 09 July 2020 08:51:51 tomas@tuxteam.de wrote:
> On Thu, Jul 09, 2020 at 08:21:40AM -0400, Gene Heskett wrote:
>
> [...]
>
> > > All that said, we won't hold the stone age against ya ;)
> >
> > Guilty re the stone age. What I have has been working well for
> > decades.
>
> I think that dismissive, sometimes condescending tone is not
> warranted. Fetchmail is a fine piece of software, albeit perhaps
> not maintained,
Only can say that if you haven't looked at it. It is in fact well
maintained.
> and it might have some tricks up its sleeve
> the others haven't picked up.
That too.
> Arrogance is out of place here.
>
> I used the fetchmail/procmail combo in a specific situation
> for a while (not the stone age, a couple of years between
> 2011 and 2016) and didn't find anything which could have
> taken up this job:
>
> it was in a corporate environment. The server department was
> deeply entrenched in Microsoft, so mail was served by an
> Exchange [1] server, and luckily the admins left the IMAP
> service up. My workstation was Linux, and mutt (my preferred
> mail reader) luckily (again) could cope with the (typically
> Microsoft-y) Rube Goldbergian authentification method which
> is NTLM.
Shudder.
> So I was reading mails fine. Until some day, Corporate
> decided that mails were to be archived after a short period
> (one week or so). Storage shortage (seriously?).
>
> Since a big chunk of my operative memory is searching in
> mail archives this didn't go well for me. And the archive
> was behind one of those crude web interfaces... well, I
> won't try to describe it to avoid putting unnecessary strain
> on the list moderation :-/
>
> So downloading my mailbox from IMAP with NTLM authentication
> was it.
>
> No single program besides fetchmail in the huge Debian distro
> fit the bill besides fetchmail. And of course, if you say
> fetchmail, the other side is procmail [2].
There are other MTA's, but nothing as well developed as procmail, IMO of
course.
> I know that there are other more pleasing alternatives from
> a more "theoretical" POV. Imapsync. Sieve -- to just point
> at alternatives to both above. When it went down to get
> dirty, it was fetchmail/procmail.
>
> So snicker at stone age all you want, but if you haven't
> made your homework, you might look silly ;-)
I personally think other methods are still crude and ungainly. Or are
loaded with bloatware. That of course is my opinion. YMMV.
Cheers
>
> [1] Why do I always read that name as an invitation, like in
> "exchange this server, ASAP"?
>
> [2] Yeah. You can also inject into a local Postfix/Exim/whatnot.
> Since I had already Exim for outgoing... but hey. And good
> luck eliminating duplicates (which I had to!) with an MTA
> setup. Procmail has a recipe for that.
>
> -- tomás
I like the old kmail, which is what TDE gives me. And kmail is quite
capable of going after its own incoming mail, but while its doing that,
the user interface is locked up tight. fetchmail/procmail to the rescue
and to synchronize it all, inotifywait, which when procmail has
delivered the incoming messages to /var/spool/mail/user, sends kmail a
get mail command over dbus, which it can do in milliseconds. The kmail
editor freezes for those same milliseconds, but loses no keystrokes. All
that fetching has become a background process I don't see. Computers are
supposed to do work FOR you, so my method results in far fewer mouse
clicks, one to answer the currently displayed message or go on to the
net unread. Answering of course involves some typing, but one click
sends that message when I've said my piece.
There may be folks who can tie me for the minimum mouse clicks to handle
their email, but I don't believe anyone here can beat me. But all are
perfectly welcome to try, I don't mind a bit.
Cheers Tomas, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
Reply to: