fetchmail-users — User questions and discussion

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

[Fetchmail-users] fetchmail-6.5.0 questions

[Ken M. <zar...@nt...>]

Hi,

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

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 ?

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 ?

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

ĸen
-- 
  I saw an eagle fly once.
  Fortunately, I had my eagle fly swatter handy.

[Fetchmail-users] ANNOUNCE: fetchmail 6.5.0 is available (modernization)

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

The 6.5.0 release of fetchmail is now available at the usual locations,
including <https://downloads.sourceforge.net/project/fetchmail/branch_6.5/>.

The source archive is available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.0.tar.xz/download>

The detached GnuPG signature is available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.0.tar.xz.asc/download>

The SHA256 hashes for the tarballs are:
SHA2-256(fetchmail-6.5.0.tar.xz)= 42611aea4861a5311e5116843f01c203dceadf440bf2eb1b4a43a445f2977668

Note that the Sourceforge Git view is quirky,
the preferred Git repository is at 
https://gitlab.com/fetchmail/fetchmail
and mirrored at  
https://sourceforge.net/p/fetchmail/git/ci/legacy_6x/tree/

But it seems that SourceForge's Git web interface isn't fully 
recognizing the latest changes on the "legacy_6x" branch that the 6.5.0 
release was made from, you need to click the 6.5.0 tag on the left to 
see the update version.

Fetchmail 6.4.X and older releases are now unsupported.


DISTRIBUTORS BEWARE: OpenSSL changed license, so you may need to change
your license tags and possibly the license which you invoke to 
redistribute fetchmail.  As an alternative, wolfSSL could be used
to maintain GPL v2 compatibility, but it lacks some features OpenSSL 
offers.


Here are the release notes:
--------------------------------------------------------------------------------
fetchmail-6.5.0 (released 2024-10-29, 31200 LoC):

## SECURITY FIX:
* .netrc now may not have more than 0700 permission if it contains passwords,
  else fetchmail will warn and ignore the file.

## REMOVED FEATURES
* fetchmail no longer supports using an MDA as SMTP fallback. This is required 
  to make deliveries consistent.
  The --enable-fallback configure option is gone.
* fetchmail no longer supports SSLv3. --sslproto ssl3 and ssl3+ options have
  been removed and behave as though "--sslproto auto" had been given.

## INCOMPATIBLE CHANGES
* fetchmail by default only negotiates TLS v1.2 or higher. (RFC-7525)
* fetchmail can auto-negotiate TLS v1.1 through the --sslproto tls1.1+ option.
* fetchmail can auto-negotiate TLS v1.0 through the --sslproto tls1+ option.
* fetchmailconf now requires Python 3.7.0 or newer.
* fetchmail, with --logfile, now logs time stamps into the file, in localtime
  and in the format "Jun 20 23:45:01 fetchmail: ". It will be localized through
  the environment variables LC_TIME (or LC_ALL) and TZ.
  Contributed by Holger Hoffstätte.
* fetchmail sets the OPENSSL security level to 2 by default.
  Override is possible from an environment variable,
  see EXPERIMENTAL CHANGES below.
* The ca, da, en_GB, id, it, nl, ru, zh_CN translations have been disabled,
  they are too far behind.

## CHANGED REQUIREMENTS
* fetchmail 6.5.0 is written in C99 and requires a SUSv3 (Single Unix
  Specification v3, a superset of POSIX.1-2001 aka. IEEE Std 1003.1-2001 with
  XSI extension) compliant system.

  In particular, older fetchmail versions had workarounds or replacement code
  for several functions standardized in the Single Unix Specification v3, these
  have been removed. Hence:
  - The trio/ library has been removed from the distribution.
  - The libesmtp/getaddrinfo.? library has been removed from the distribution.
  - The KAME/getnameinfo.c file has been removed from the distribution.

* fetchmail 6.5.0 requires a TLSv1.3-capable version of OpenSSL or wolfSSL,
  at a minimum OpenSSL v3.0.9 or wolfSSL v5.7.2.

## TRANSLATIONS: fetchmail's messages were translated by these fine people:
* cs:    Petr Pisar [Czech]
* eo:    Keith Bowes [Esperanto]
* es:    Cristian Othón Martínez Vera [Spanish]
* fr:    Frédéric Marchal [French]
* ja:    Takeshi Hamasaki [Japanese]
* ro:    Remus-Gabriel Chelu [Romanian]
* sv:    Göran Uddeborg [Swedish]
* sq:    Besnik Bleta [Albanian]
* pl:    Jakub Bogusz [Polish]

## BUG FIXES
* fetchmail can now report mailbox sizes of 2^31 octets and beyond (2 GibiB).
  This required C99 support (for the long long type).
  Fixes Debian Bug#873668, reported by Andreas Schmidt.
* fetchmail now defines its OpenSSL API level to 3.0.0 so as to expose the
  3.0.0 APIs from OpenSSL.
* The .netrc parser no longer permits "machine" after "default".
* Add manpage info on the .netrc syntax, as ftp(1) is not standardized and
  may not be installed. Fixes Launchpad Bug #1976361 reported by Bill Yikes.
* Received: lines now return GMT time if the tzoffset cannot be represented
  as whole minutes. Reported by @rriddicc via Gitlab #49.
* If fetchmail was running localized, generated an error e-mail message locally,
  and if the selected translation would require the Subject: line to wrap
  inside an RFC-2047 encoded word (=?UTF-8?Q?...?=), the wrapped encoded-word
  was not indented, thus not marked as a continuation line.
* SSL error handling was improved, fetchmail now consistently clears the
  thread/SSL error queue before SSL I/O operations and checks SSL_get_error
  afterwards.  The SSL_connect() error handling has been revised to log more
  consistently.

## CHANGES
* When fetchmail attempts to log out from an IMAP4 server and the server messes
  up its responses (it is supposed to send an untagged * BYE and a tagged
  A4711 OK) and sends a tagged A4711 BYE response, tolerate that, rather than
  reporting a protocol error. We don't intend to chat any more so the protocol
  violation is harmless, and we know the server cannot send more untagged
  status responses.
  Analysis and fix courtesy of Maciej S. Szmigiero, GitLab merge request !20.
* The configure script now spends more effort for getting --with-ssl right, by
  running pkg-config in the right environment, and using the AC_LIB_LINKFLAGS
  macro to obtain run-time library path setting flags.
* For typical POP3/IMAP ports 110, 143, 993, 995, if port and --ssl option
  do not match, emit a warning and continue. Closes Gitlab #31.
* There is now a --idletimeout feature contributed by Eric Durand, to
  permit setting a shorter timeout for the --idle option, because many
  servers violate the protocol (requiring 30 minutes) and hang up sooner than
  the 28 minutes fetchmail waits before refreshing IDLE.
  GitLab merge request !35.
* There is now a --forceidle feature to force idle mode even if not advertised
  in the server capabilities. This is a dangerous option, use it carefully.
  Courtesy of Eric Durand, GitLab merge request !39.
* There is now a --moveto feature (only feasible in IMAP) that, instead of
  flushing mail, moves it to a user-specified folder. This is to assist with
  archiving, or when providers (G...) break the IMAP model.
  Courteously provided by Damjan Jovanovic.
* rcfile parsing errors are now reported in more detail, and with -vv mode,
  also lead to a non-importable Python dump of what was obtained, for debugging.
* fetchmail's --auth option ssh was renamed to implicit, to make clear that it
  does *NOT* imply any particular type or features of the --plugin.  --auth ssh
  will be understood for a while for compatibility but fetchmail will report it
  as implicit.
* fetchmail no longer warns about port/service mismatches with/without ssl
  option when a "plugin" is in use because fetchmail cannot know whether the
  plugin talks SSL or STARTTLS/STLS. Fixes Debian Bug#1076604.
* fetchmail re-executes itself if the .netrc file's modification change
  is found to be newer at the beginning of a new run.
* fetchmail can now use other digest algorithms than MD5 for the
  --sslfingerprint option. To use, specify the algorithm's name in
  curly braces as prefix in the finger print, say,
  --sslfingerprint '{SHA256}00:01:[...]:1F'. This will also switch the
  algorithm for printing. All algorithms supported by the TLS/SSL library
  can be specified. Fixes Gitlab issue #19, Debian Bug#700266.

## EXPERIMENTAL CHANGES - these are not documented anywhere else, only here:
* fetchmail supports a FETCHMAIL_SSL_SECLEVEL environment variable that
  can be used to override the OpenSSL security level. Fetchmail by default
  raises the security level to 2 if lower. This variable can be used to lower it.
  Use with extreme caution. Note that levels 3 or higher will frequently cause
  incompabilities with servers because server-side data sizes are often too low.
  Valid range: 0 to 5 for OpenSSL 1.1.1 and 3.0.
* fetchmail supports a FETCHMAIL_SSL_CIPHERS environment variable that
  sets the cipher string (through two different OpenSSL functions) for SSL and
  TLS versions up to TLSv1.2.
  If setting the ciphers fails, fetchmail will not connect.
  If not given, defaults to Postfix's "medium" list,
  "aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH".
* fetchmail supports a FETCHMAIL_TLS13_CIPHERSUITES environment variable
  that sets the ciphersuites (a colon-separated list, without + ! -) for
  TLSv1.3. If not given, defaults to OpenSSL's built-in list. If setting the
  ciphersuites fails, fetchmail refuses to connect.
* NOTE the features above are simplistic. For instance, even though you
  configure --sslproto tls1.3, a failure to set tls1.2 ciphers could cause
  a connection abort.
* fetchmail can be built with meson 1.30 or newer <https://mesonbuild.com/>.
  fetchmail is not currently written in a way that supports unity
  (amalgamated) builds.

================================================================================

Re: [Fetchmail-users] XOAUTH2 needed for hotmail.com after September 16 2024

[Carlos E. R. <rob...@te...>]

On 2024-10-03 06:30, Ian! D. Allen wrote:
> Yes, but forwarding from hotmail has Spamassassin SPF problems:
> 
>      4.0 SPF_FAIL SPF: sender does not match SPF record (fail)

Perhaps you can add your own rule to add 4 good points to emails coming 
from the hotmail account, to nullify that SPF rule.


-- 
Cheers / Saludos,

		Carlos E. R.
		(from 15.5 x86_64 at Telcontar)

Re: [Fetchmail-users] XOAUTH2 needed for hotmail.com after September 16 2024

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

Am 03.10.24 um 06:30 schrieb Ian! D. Allen:
> On Wed, Sep 25, 2024 at 06:27:27AM -0400, Matthias Andree wrote:
>> App passwords are the sidestep or workaround while they last.
> Yes, app passwords are still working with gmail (October 2 2024):
> -https://support.google.com/accounts/answer/185833
>
> As of September 16, app passwords don't work with hotmail:
> -https://support.microsoft.com/en-us/office/modern-authentication-methods-now-needed-to-continue-syncing-outlook-email-in-non-microsoft-email-apps-c5d65390-9676-4763-b41f-d7986499a90d
> -https://techcommunity.microsoft.com/t5/outlook-blog/keeping-our-outlook-personal-email-users-safe-reinforcing-our/ba-p/4164184
>    "App passwords or Application passwords will be deprecated as part of the Basic Auth deprecation.  You will need to use Modern Auth for all cases."

Hm. App-specific passwords still seem to be advertised under the
condition that 2-factor authentication is enabled and it references
"mail apps on some smartphones" or devices ("f.i., xbox 360") that seem
unable to use "regular security codes" (this is all translated back from
German from the page about 2FA for the account).

I haven't tested this but unless they stop requiring application reviews
for OAuth2 application tokens, if they really turned off application
passwords, then we're done with Microsoft.

fetchmail 7 (currently in development) has rudimentary support for
OAUTH2 but has no application token so that's of limited use.

> I can generate an "app password" for my Microsoft account, but using
> that password in my .fetchmailrc does not work:
>
>      fetchmail: POP3< -ERR Logon failure: unknown user name or bad password.
>      fetchmail: Logon failure: unknown user name or bad password.

Does it have to be a specific application-specific password *for mail*?
I presume these passwords would be limited to one particular service.

> On Tue, Sep 24, 2024 at 03:43:06PM -0400, Lucio Chiappetti wrote:
>> Can you instruct your "legacy proprietaruy service" to FORWARD all mail to
>> another fetchmail-firendly provider?
> Yes, but forwarding from hotmail has Spamassassin SPF problems:
>
>      4.0 SPF_FAIL SPF: sender does not match SPF record (fail)

That's self-inflicted by how SpamAssassin is configured. It doesn't have
to punish SPF forwardings like that. I know SPF is being promoted for
spam defense, but it's broken by design and for many people causes more
trouble than it's worth.


> Also, fetching email via POP kept my hotmail account alive without me
> having to access it in a browser, because POP was treated as a "login".
>
> I've set up hotmail forwarding and have a cron job to remind me to
> use a web browser to log in to hotmail every now and then to keep the
> account alive.
>

Re: [Fetchmail-users] XOAUTH2 needed for hotmail.com after September 16 2024

[Ian! D. A. <id...@id...>]

On Wed, Sep 25, 2024 at 06:27:27AM -0400, Matthias Andree wrote:
> App passwords are the sidestep or workaround while they last.

Yes, app passwords are still working with gmail (October 2 2024):
- https://support.google.com/accounts/answer/185833

As of September 16, app passwords don't work with hotmail:
- https://support.microsoft.com/en-us/office/modern-authentication-methods-now-needed-to-continue-syncing-outlook-email-in-non-microsoft-email-apps-c5d65390-9676-4763-b41f-d7986499a90d
- https://techcommunity.microsoft.com/t5/outlook-blog/keeping-our-outlook-personal-email-users-safe-reinforcing-our/ba-p/4164184
  "App passwords or Application passwords will be deprecated as part of the Basic Auth deprecation.  You will need to use Modern Auth for all cases."

I can generate an "app password" for my Microsoft account, but using
that password in my .fetchmailrc does not work:

    fetchmail: POP3< -ERR Logon failure: unknown user name or bad password.
    fetchmail: Logon failure: unknown user name or bad password.

---

On Tue, Sep 24, 2024 at 03:43:06PM -0400, Lucio Chiappetti wrote:
> Can you instruct your "legacy proprietaruy service" to FORWARD all mail to
> another fetchmail-firendly provider?

Yes, but forwarding from hotmail has Spamassassin SPF problems:

    4.0 SPF_FAIL SPF: sender does not match SPF record (fail)

Also, fetching email via POP kept my hotmail account alive without me
having to access it in a browser, because POP was treated as a "login".

I've set up hotmail forwarding and have a cron job to remind me to
use a web browser to log in to hotmail every now and then to keep the
account alive.

-- 
| Ian! D. Allen, BA-Psych, MMath-CompSci  id...@id... Ottawa CANADA
| Home: www.idallen.com  Contact Improvisation Dance: www.contactimprov.ca
| Former college professor of Free/Libre GNU+Linux @ teaching.idallen.com
| Improve democracy www.fairvote.ca and defend digital freedom www.eff.org

[Fetchmail-users] ANNOUNCE: The 6.5.0.rc2 release candidate of fetchmail is available

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

The 6.5.0.rc2 release of fetchmail is now available at the usual locations,
including <https://downloads.sourceforge.net/project/fetchmail/branch_6.5/>.

It adds seven new translations and fixes a PATH_MAX related mis-merge 
that might break compilation on arcane operating systems.

The source archive is available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.0.rc2.tar.xz/download>

The detached GnuPG signature is available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.0.rc2.tar.xz.asc/download>

The SHA256 hashes for the tarballs are:
SHA2-256(fetchmail-6.5.0.rc2.tar.xz)= 577b4f32b81be2c5ccd4a2ea18131a758f159497b13aba71d8e3a490952914ac


Here are the release notes changes since rc1:
--------------------------------------------------------------------------------
* fetchmail 6.5.0 requires a TLSv1.3-capable version of OpenSSL or wolfSSL,
  at a minimum OpenSSL v3.0.9 or wolfSSL v5.7.2.

## TRANSLATIONS: fetchmail's messages were translated by these fine people:
* cs:    Petr Pisar [Czech]
* eo:    Keith Bowes [Esperanto]
* es:    Cristian Othón Martínez Vera [Spanish]
* fr:    Frédéric Marchal [French]
* ja:    Takeshi Hamasaki [Japanese]
* ro:    Remus-Gabriel Chelu [Romanian]
* sv:    Göran Uddeborg [Swedish]

* fetchmail now defines its OpenSSL API level to 3.0.0 so as to expose the
  3.0.0 APIs from OpenSSL.
* SSL error handling was improved, fetchmail now consistently clears the
  thread/SSL error queue before SSL I/O operations and checks SSL_get_error
  afterwards.  The SSL_connect() error handling has been revised to log more
  consistently.

* fetchmail can be built with meson 1.30 or newer <https://mesonbuild.com/>.
  fetchmail is not currently written in a way that supports unity
  (amalgamated) builds.
================================================================================

Re: [Fetchmail-users] XOAUTH2 needed for hotmail.com after September 16 2024

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

Am 24.09.24 um 20:07 schrieb Ian! D. Allen:
> On Tue, Sep 24, 2024 at 10:21:06AM -0400, Matthias Andree wrote:
> [...]
>> Sorry if this doesn't fit your bill. Talk to those that change
>> authentication schemes that cost you your freedom, not to providers of
>> free software where you enjoy and retain free choice liberties.
> Yes, it is precisely because I use a GNU/Linux desktop exclusively
> that I need a way to fetch messages sent to my legacy accounts on these
> proprietary services that I don't actually use.

App passwords are the sidestep or workaround while they last. More
towards the very end of this message.

Yes. I am sorry for you. But the authors of free and open source
software cannot fix that. You are talking to the wrong people.
Either you manage to change how big business works (quite unlikely), or
you convince your local members of parliament that you need regulatory
means (meaning legislation) to enforce non-discriminatory access to your
e-mail.

Fetchmail is, as you are, a victim of the policy change of big
corporations that choose or chose to not only change the authentication
scheme (which fetchmail could and can do something about).

Internet has always been about "let's adhere to communication protocols
and then we'll be exchanging data". Now some corporations chose to
depart from that point. That's painful. That change for OAUTH2, on
Microsoft and Google's end, however is a trap, and it *also* comes with
a requirement to have the software reviewed, because they will want to
review the software, its privacy policy, its presentation, and whatnot.
That review costs a lot of effort, in some cases, a lot of money (on the
order of an annual gross salary of a software engineer), and that is a
real road block, and also political change.

We never needed that on the Internet before. We looked at IETF RFCs or
standards, wrote our software such that it adhered sufficiently closely
to those protocols, and were allowed to fetch your mail.
Now with OAUTH2 on Google's and Microsoft's end, that no longer
suffices. Only after going through their review labyrinth, they will
give the author of that software a token that identifies the software
and is part of the OAUTH2 schemes these providers require from client
software. Under whatever arbitrary conditions.

Even if that software or, in newspeak, "app" review, were free of
charge, it can never be free of effort for its author, yours truly.
I need to describe the software, put up privacy policies (of course you
configure or enter your password so it's sent to fetch e-mail), put up
review reports, and what not.

If I make that exception once or twice, that opens the floodgate and I
will be drowned in requests to hand fetchmail in for review here, there,
and everywhere.
And I expect every service to have their own review check-lists and most
will have to be done individually.

Then we also need to discuss with distributors to update fetchmail to
support the "app" tokens we receive to keep things going.  We've seen
the fights distributors and Mozilla have had about the quick Firefox
update schedule.

> In keeping with the robustness principle, to paraphrase Jon Postel, I
> try to be "liberal in what services I fetch email from, and conservative
> in using only free/libre software to send email".
>
> I don't own a cell phone, so using phone "apps" isn't an option.
At some point in time, someone started calling desktop or command-line
application software "apps" irrespective that this continues to run on
your GNU/Linux PC of old. fetchmail is an "app" in that sense. I would
not call it that, but well.

The gist of those specific passwords (however qualified) is: Google and
Microsoft, AFAICT, have been offering and continue to do so, a way that
you - under some conditions - can obtain or configure an
application-specific, "app-specific" or I would usually call it
some-or-our-services specific password, to let you fetch your e-mail.  
Those conditions they impose AFAICT have been "you must switch your
account to two-factor authentication". The idea is that the power of
this specific password is limited to fetching and/or sending e-mail and
does not expose your entire Google or Microsoft account. There is some
sense in that: That same password that gives you e-mail is no longer
good to look at your collaborative documents, at your maps or browsing
history, or whatnot.

I do like the idea of limiting the attack surface or power of an exposed
password, but we did not have to invent another hundreds-of-pages
standard which does not only describe authentication scheme with lots of
half-baked and quarter-implemented use patterns for that purpose.


So bottom line: if your mail service provider permits setting specific
passwords, app-specific, application-specific, service-specific, and you
can abide by the rules you need to obtain or set these, go for them, or
else I am afraid you will have to switch service provider sooner or later.

Hope that helps
Matthias

Re: [Fetchmail-users] XOAUTH2 needed for hotmail.com after September 16 2024

[Lucio C. <lu...@la...>]

Not an outlook user but forced to be a gsuite user at work, so I passed 
through this already.

On Tue, 24 Sep 2024, Ian! D. Allen wrote:

> Yes, it is precisely because I use a GNU/Linux desktop exclusively that 
> I need a way to fetch messages sent to my legacy accounts on these 
> proprietary services that I don't actually use.

Can you instruct your "legacy proprietaruy service" to FORWARD all mail to 
another fetchmail-firendly provider ? This is one of the solutions I 
used.

> I don't own a cell phone, so using phone "apps" isn't an option.

I don't have a smartphone as well, but the reference to "app password"
does not imply phone apps. An "app password" (at least as defined by 
google) is just a dedicated password for the e-mail account different 
from the personal one, whjich csn be used by a generic Mail User Agent 
(e.g. alpine or fetchmail). They call "app" what we oldtimers call binary, 
program, executable, piece of software.

I have defined an "app password" for my gsuite account. This is an 
alternative to forwarding. Actually I use app password for occasional IMAP 
access. I could use it with fetchmail as well, but I fetch the bulk from 
the fetchmail-firendly provider where I forward all stuff.

It's a PITA, but it's viable (so far) to overcome the b**y OAUTH.


-- 
Lucio Chiappetti - INAF/IASF - via Corti 12 - I-20133 Milano (Italy)
For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html
------------------------------------------------------------------------
A middle rank researcher at end career is not rich but is in the top 5%
of the Italian income tax taxpayers. Does it not sound strange ?

Re: [Fetchmail-users] XOAUTH2 needed for hotmail.com after September 16 2024

[Ian! D. A. <id...@id...>]

On Tue, Sep 24, 2024 at 10:21:06AM -0400, Matthias Andree wrote:
[...]
> Sorry if this doesn't fit your bill. Talk to those that change
> authentication schemes that cost you your freedom, not to providers of
> free software where you enjoy and retain free choice liberties.

Yes, it is precisely because I use a GNU/Linux desktop exclusively
that I need a way to fetch messages sent to my legacy accounts on these
proprietary services that I don't actually use.

In keeping with the robustness principle, to paraphrase Jon Postel, I
try to be "liberal in what services I fetch email from, and conservative
in using only free/libre software to send email".

I don't own a cell phone, so using phone "apps" isn't an option.

-- 
| Ian! D. Allen, BA-Psych, MMath-CompSci  id...@id... Ottawa CANADA
| Home: www.idallen.com  Contact Improvisation Dance: www.contactimprov.ca
| Former college professor of Free/Libre GNU+Linux @ teaching.idallen.com
| Improve democracy www.fairvote.ca and defend digital freedom www.eff.org

[Fetchmail-users] ANNOUNCE: The 6.5.0.rc1 release candidate of fetchmail is available (translations still incomplete)

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

The 6.5.0.rc1 release of fetchmail is now available at the usual locations,
including <https://downloads.sourceforge.net/project/fetchmail/branch_6.5/>.

The source archive is available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.0.rc1.tar.xz/download>

The detached GnuPG signature is available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.0.rc1.tar.xz.asc/download>

The SHA256 hashes for the tarballs are:
SHA2-256(fetchmail-6.5.0.rc1.tar.xz)= f4c8317bf95477d975c945a5624275729385904a7a2d4931f8098cfd9dddf5d0


Please test this thorougly, report bugs, issues in documentation, 
everything, through issues on <https://gitlab.com/fetchmail/fetchmail>,
and send praise -- and if your translation isn't up to date, consider
joining the <https://translationproject.org> and helping out.

Thank you very much in advance!


Here are the release notes:
--------------------------------------------------------------------------------
fetchmail-6.5.0 (not yet released):

## SECURITY FIX:
* .netrc now may not have more than 0700 permission if it contains passwords,
  else fetchmail will warn and ignore the file.

## REMOVED FEATURES
* fetchmail no longer supports using an MDA as SMTP fallback. This is required 
  to make deliveries consistent.
  The --enable-fallback configure option is gone.
* fetchmail no longer supports SSLv3. --sslproto ssl3 and ssl3+ options have
  been removed and behave as though "--sslproto auto" had been given.

## INCOMPATIBLE CHANGES
* fetchmail by default only negotiates TLS v1.2 or higher. (RFC-7525)
* fetchmail can auto-negotiate TLS v1.1 through the --sslproto tls1.1+ option.
* fetchmail can auto-negotiate TLS v1.0 through the --sslproto tls1+ option.
* fetchmailconf now requires Python 3.7.0 or newer.
* fetchmail, with --logfile, now logs time stamps into the file, in localtime
  and in the format "Jun 20 23:45:01 fetchmail: ". It will be localized through
  the environment variables LC_TIME (or LC_ALL) and TZ.
  Contributed by Holger Hoffstätte.
* fetchmail sets the OPENSSL security level to 2 by default.
  Override is possible from an environment variable,
  see EXPERIMENTAL CHANGES below.
* The ca, da, en_GB, id, it, nl, ru, zh_CN translations have been disabled,
  they are too far behind.

## CHANGED REQUIREMENTS
* fetchmail 6.5.0 is written in C99 and requires a SUSv3 (Single Unix
  Specification v3, a superset of POSIX.1-2001 aka. IEEE Std 1003.1-2001 with
  XSI extension) compliant system.

  In particular, older fetchmail versions had workarounds or replacement code
  for several functions standardized in the Single Unix Specification v3, these 
  have been removed. Hence:
  - The trio/ library has been removed from the distribution.
  - The libesmtp/getaddrinfo.? library has been removed from the distribution.
  - The KAME/getnameinfo.c file has been removed from the distribution.

* fetchmail 6.5.0 requires a TLSv1.3-capable version of OpenSSL or wolfSSL,
  at a minimum OpenSSL v1.1.1 or wolfSSL v5.5.1.

## BUG FIXES
* fetchmail can now report mailbox sizes of 2^31 octets and beyond.
  This required C99 support (for the long long type).
  Fixes Debian Bug#873668, reported by Andreas Schmidt.
* fetchmail now defines its OpenSSL API level (1.1.1, or 10101) so
  as to compile with OpenSSL 3.0. (fetchmail was requesting to hide
  deprecated APIs.)
* The .netrc parser no longer permits "machine" after "default".
* Add manpage info on the .netrc syntax, as ftp(1) is not standardized and
  may not be installed. Fixes Launchpad Bug #1976361 reported by Bill Yikes.
* Received: lines now return GMT time if the tzoffset cannot be represented
  as whole minutes. Reported by @rriddicc via Gitlab #49.
* If fetchmail was running localized, generated an error e-mail message locally,
  and if the selected translation would require the Subject: line to wrap
  inside an RFC-2047 encoded word (=?UTF-8?Q?...?=), the wrapped encoded-word
  was not indented, thus not marked as a continuation line.

## CHANGES
* When fetchmail attempts to log out from an IMAP4 server and the server messes
  up its responses (it is supposed to send an untagged * BYE and a tagged
  A4711 OK) and sends a tagged A4711 BYE response, tolerate that, rather than
  reporting a protocol error. We don't intend to chat any more so the protocol
  violation is harmless, and we know the server cannot send more untagged
  status responses.
  Analysis and fix courtesy of Maciej S. Szmigiero, GitLab merge request !20.
* The configure script now spends more effort for getting --with-ssl right, by 
  running pkg-config in the right environment, and using the AC_LIB_LINKFLAGS 
  macro to obtain run-time library path setting flags.
* For typical POP3/IMAP ports 110, 143, 993, 995, if port and --ssl option
  do not match, emit a warning and continue. Closes Gitlab #31.
* There is now a --idletimeout feature contributed by Eric Durand, to
  permit setting a shorter timeout for the --idle option, because many
  servers violate the protocol (requiring 30 minutes) and hang up sooner than
  the 28 minutes fetchmail waits before refreshing IDLE.
  GitLab merge request !35.
* There is now a --forceidle feature to force idle mode even if not advertised
  in the server capabilities. This is a dangerous option, use it carefully.
  Courtesy of Eric Durand, GitLab merge request !39.
* There is now a --moveto feature (only feasible in IMAP) that, instead of
  flushing mail, moves it to a user-specified folder. This is to assist with
  archiving, or when providers (G...) break the IMAP model.
  Courteously provided by Damjan Jovanovic.
* rcfile parsing errors are now reported in more detail, and with -vv mode,
  also lead to a non-importable Python dump of what was obtained, for debugging.
* fetchmail's --auth option ssh was renamed to implicit, to make clear that it 
  does *NOT* imply any particular type or features of the --plugin.  --auth ssh 
  will be understood for a while for compatibility but fetchmail will report it 
  as implicit.
* fetchmail no longer warns about port/service mismatches with/without ssl
  option when a "plugin" is in use because fetchmail cannot know whether the
  plugin talks SSL or STARTTLS/STLS. Fixes Debian Bug#1076604.
* fetchmail re-executes itself if the .netrc file's modification change
  is found to be newer at the beginning of a new run.
* fetchmail can now use other digest algorithms than MD5 for the 
  --sslfingerprint option. To use, specify the algorithm's name in
  curly braces as prefix in the finger print, say,
  --sslfingerprint '{SHA256}00:01:[...]:1F'. This will also switch the
  algorithm for printing. All algorithms supported by the TLS/SSL library
  can be specified. Fixes Gitlab issue #19, Debian Bug#700266.

## EXPERIMENTAL CHANGES - these are not documented anywhere else, only here:
* fetchmail supports a FETCHMAIL_SSL_SECLEVEL environment variable that
  can be used to override the OpenSSL security level. Fetchmail by default
  raises the security level to 2 if lower. This variable can be used to lower it.
  Use with extreme caution. Note that levels 3 or higher will frequently cause
  incompabilities with servers because server-side data sizes are often too low.
  Valid range: 0 to 5 for OpenSSL 1.1.1 and 3.0.
* fetchmail supports a FETCHMAIL_SSL_CIPHERS environment variable that
  sets the cipher string (through two different OpenSSL functions) for SSL and
  TLS versions up to TLSv1.2.
  If setting the ciphers fails, fetchmail will not connect.
  If not given, defaults to Postfix's "medium" list, 
  "aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH".
* fetchmail supports a FETCHMAIL_TLS13_CIPHERSUITES environment variable
  that sets the ciphersuites (a colon-separated list, without + ! -) for
  TLSv1.3. If not given, defaults to OpenSSL's built-in list. If setting the 
  ciphersuites fails, fetchmail refuses to connect.
* NOTE the features above are simplistic. For instance, even though you 
  configure --sslproto tls1.3, a failure to set tls1.2 ciphers could cause
  a connection abort.
* fetchmail can be built with meson 0.60 or newer <https://mesonbuild.com/>.
  fetchmail is not currently written in a way that supports unity
  (amalgamated) builds.

================================================================================

Re: [Fetchmail-users] XOAUTH2 needed for hotmail.com after September 16 2024

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

Am 20.09.24 um 08:08 schrieb Ian! D. Allen:
> Is fetchmail version 7 with XOAUTH2 stable enough to release?

No it's not. 6.5 is neither, but very close.

>  From Microsoft "POP, IMAP, and SMTP settings for Outlook.com":
>
>       Outlook.com requires the use of Modern Auth / OAuth2.  Basic auth
>       is in the process of being deprecated from the Outlook.com service.
Yeah. Their choice to take away user freedom of choice, and imply to
have software reviewed if they deem it good enough to talk to them.
>  From Microsoft on September 12, 2024:
>
>      Update your sign-in technology before September 16th, 2024 to maintain
>      email access.
>
>      The safety and security of your information is top priority for
>      Microsoft. To help keep your account secure, Microsoft will no longer
>      support the use of third-party email and calendar apps which ask you
>      to sign in with only your Microsoft Account username and password. To
>      keep you safe you will need to use a mail or calendar app which
>      supports Microsoft’s modern authentication methods. If you do not
>      act, your third-party email apps will no longer be able to access
>      your Outlook.com, Hotmail or Live.com email address on September 16th.
Yeah. Their choice to take away user freedom of choice, and imply to
have software reviewed if they deem it good enough to talk to them.

See which of the service permit you to configure app-specific passwords,
and use those, or else choose a different service.

Fetchmail is free and open source software, and free means free choice.

When have we had to fix security issues in fetchmail for the last time?
How many over the decades?

How many weeks ago has your favorite browser that you do need for OAUTH2
schemes fixed security bugs, and how many were they?

Sorry if this doesn't fit your bill. Talk to those that change
authentication schemes that cost you your freedom, not to providers of
free software where you enjoy and retain free choice liberties.

Re: [Fetchmail-users] XOAUTH2 needed for hotmail.com after September 16 2024

[Andrew C A. <fet...@ai...>]

On Fri, 20 Sep 2024, Ian! D. Allen wrote:

> Google is still letting us use USER/PASS authentication.

Google's magic date is the end of this month:
Google discontinuing "Less Secure App" authentication.

https://workspaceupdates.googleblog.com/2023/09/winding-down-google-sync-and-less-secure-apps-support.html

App Passwords will continue to be available.

-- 
Andrew C. Aitchison                      Kendal, UK
                    an...@ai...

Re: [Fetchmail-users] XOAUTH2 needed for hotmail.com after September 162024

[gene h. <ghe...@sh...>]

On 9/20/24 02:26, Ian! D. Allen wrote:
> Is fetchmail version 7 with XOAUTH2 stable enough to release?
> 
>  From Microsoft "POP, IMAP, and SMTP settings for Outlook.com":
> 
>       Outlook.com requires the use of Modern Auth / OAuth2.  Basic auth
>       is in the process of being deprecated from the Outlook.com service.
> 
>  From Microsoft on September 12, 2024:
> 
>      Update your sign-in technology before September 16th, 2024 to maintain
>      email access.
> 
>      The safety and security of your information is top priority for
>      Microsoft. To help keep your account secure, Microsoft will no longer
>      support the use of third-party email and calendar apps which ask you
>      to sign in with only your Microsoft Account username and password. To
>      keep you safe you will need to use a mail or calendar app which
>      supports Microsoft’s modern authentication methods. If you do not
>      act, your third-party email apps will no longer be able to access
>      your Outlook.com, Hotmail or Live.com email address on September 16th.
> 
> Failing excerpt from my "fetchmail -v hotmail" after September 16:
> 
>      fetchmail: POP3< +OK The Microsoft Exchange POP3 service is ready. [...]
>      fetchmail: POP3> CAPA
>      fetchmail: POP3< +OK
>      fetchmail: POP3< TOP
>      fetchmail: POP3< UIDL
>      fetchmail: POP3< SASL PLAIN XOAUTH2
>      fetchmail: POP3< USER
>      fetchmail: POP3< .
>      fetchmail: POP3> USER us...@ho...
>      fetchmail: POP3< +OK
>      fetchmail: POP3> PASS *
>      fetchmail: POP3< -ERR Logon failure: unknown user name or bad password.
>      fetchmail: Logon failure: unknown user name or bad password.
>      fetchmail: Authorization failure [...]
> 
> Google is still letting us use USER/PASS authentication.
Good, but will it reduce the spam and phishing from the first two of 
those sites? For 2 or 3 days maybe...

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

[Fetchmail-users] XOAUTH2 needed for hotmail.com after September 16 2024

[Ian! D. A. <id...@id...>]

Is fetchmail version 7 with XOAUTH2 stable enough to release?

>From Microsoft "POP, IMAP, and SMTP settings for Outlook.com":

     Outlook.com requires the use of Modern Auth / OAuth2.  Basic auth
     is in the process of being deprecated from the Outlook.com service.

>From Microsoft on September 12, 2024:

    Update your sign-in technology before September 16th, 2024 to maintain
    email access.

    The safety and security of your information is top priority for
    Microsoft. To help keep your account secure, Microsoft will no longer
    support the use of third-party email and calendar apps which ask you
    to sign in with only your Microsoft Account username and password. To
    keep you safe you will need to use a mail or calendar app which
    supports Microsoft’s modern authentication methods. If you do not
    act, your third-party email apps will no longer be able to access
    your Outlook.com, Hotmail or Live.com email address on September 16th.

Failing excerpt from my "fetchmail -v hotmail" after September 16:

    fetchmail: POP3< +OK The Microsoft Exchange POP3 service is ready. [...]
    fetchmail: POP3> CAPA
    fetchmail: POP3< +OK
    fetchmail: POP3< TOP
    fetchmail: POP3< UIDL
    fetchmail: POP3< SASL PLAIN XOAUTH2
    fetchmail: POP3< USER
    fetchmail: POP3< .
    fetchmail: POP3> USER us...@ho...
    fetchmail: POP3< +OK
    fetchmail: POP3> PASS *
    fetchmail: POP3< -ERR Logon failure: unknown user name or bad password.
    fetchmail: Logon failure: unknown user name or bad password.
    fetchmail: Authorization failure [...]

Google is still letting us use USER/PASS authentication.

-- 
| Ian! D. Allen, BA-Psych, MMath-CompSci  id...@id... Ottawa CANADA
| Home: www.idallen.com  Contact Improvisation Dance: www.contactimprov.ca
| Former college professor of Free/Libre GNU+Linux @ teaching.idallen.com
| Improve democracy www.fairvote.ca and defend digital freedom www.eff.org

[Fetchmail-users] ANNOUNCE: fetchmail 6.4.39 is available (two bugfixes)

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

The 6.4.39 release of fetchmail is now available at the usual locations,
including <https://sourceforge.net/projects/fetchmail/files/branch_6.4/>.

The source archive is available at:
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.39.tar.xz/download>
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.39.tar.lz/download>

The detached GnuPG signature is available at:
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.39.tar.xz.asc/download>
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.39.tar.lz.asc/download>

The SHA256 hashes for the tarballs are:
SHA2-256(fetchmail-6.4.39.tar.xz)= 75109a1f307b538155fa05f5ef298e8298cb4deae95aed24c16b38d36ff0a186
SHA2-256(fetchmail-6.4.39.tar.lz)= 657ff8655860e649c0863eb942eda1668d4f20f72263129622829e60c018854b


Here are the release notes:
--------------------------------------------------------------------------------
fetchmail-6.4.39 (released 2024-07-20, 31729 LoC):

# BUG FIXES:
* When a server offers STARTTLS although the connection is already wrapped
  in TLS, fetchmail would issue a bogus "WARNING: server offered STARTTLS but 
  sslproto '' given." (or STLS for POP3).  In situations where we wrap the
  connection in TLS, suppress the warning. Reported by Mike Pope.

* If fetchmail was running localized, generate an error e-mail message locally,
  and if the selected translation would require the Subject: line to wrap
  inside an RFC-2047 encoded word (=?UTF-8?Q?...?=), the wrapped encoded-word
  was not indented, thus not marked as a continuation line.

--------------------------------------------------------------------------------

Re: [Fetchmail-users] authentication fail

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

Am 25.06.24 um 19:01 schrieb Matthias Andree via Fetchmail-users:
> Am 25.06.24 um 03:53 schrieb Michael Pope:
>>> 1-  a genuine issue with authentication (did the service change login
>> policies?
>>
>> I fear there may have been a "quiet change" at the provider.  My
>> credentials are correct/unchanged for their webmail.
>
> Yep. I find it most confusing though that the server would offer
> STARTTLS in spite of having already negotiated TLS. This seems to be a
> first to be seen in the wild and reported - and this is what confused
> fetchmail, which simply does not expect to see STARTTLS offered on a TLS
> connection, and also would not use it, nor would that make sense. It
> might be a configuration issue on your provider's servers. None of the
> servers I've read conversations of would offer STARTTLS on a TLS-wrapped
> connection.
>
>>> 2- fetchmail misreporting the authentication failure with that WARNING
>> OK, sslproto is (probably) correct, and that warning is incorrect.  Is
>> there any other logging/warning/error configuration I can try to get
>> better
>> debugging of why authentication is failing?  Does fetchmail only see a
>> success/fail, or is the next step to fire up wireshark:-)?
>
> There isn't anything you can do but checking the provider's help and
> news pages or contacting them.
>
> The very first communication is the successful negotiation of TLS v1.2,
> and after receiving the initial prompt, the first command that fetchmail
> tries is A0001 LOGIN with your user and password, and that fails.
> This is the *entire* conversation after the SSL negotiation, and
> WireShark is not going to give you anything useful because fetchmail has
> the cleartext conversation, but Wireshark only has the encrypted stuff,
> and decoding that would be quite a bit of a hassle and a distraction
> because you already have it...
> https://wiki.wireshark.org/TLS#tls-decryption
>
Oh - and one more thing, since OpenSSL negotiated

> fetchmail: SSL/TLS: using protocol TLSv1.2, cipher
> ECDHE-RSA-AES256-GCM-SHA384, 256/256 secret/processed bits
Wireshark cannot even decrypt that conversation according to the wiki
page I've linked above.

>> fetchmail: IMAP< * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID
>> ENABLE IDLE SPECIAL-USE LITERAL+ STARTTLS AUTH=PLAIN AUTH=LOGIN] imap
>> ready - cma-tmc
>> fetchmail: IMAP> A0001 LOGIN "mpope" *
>> fetchmail: IMAP< A0001 NO [AUTHENTICATIONFAILED] Authentication failed.
> So... your provider will need to support you.
>
> _______________________________________________
> Fetchmail-users mailing list
> Fet...@li...
> https://lists.sourceforge.net/lists/listinfo/fetchmail-users

Re: [Fetchmail-users] authentication fail

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

Am 25.06.24 um 03:53 schrieb Michael Pope:
>> 1-  a genuine issue with authentication (did the service change login
> policies?
>
> I fear there may have been a "quiet change" at the provider.  My
> credentials are correct/unchanged for their webmail.

Yep. I find it most confusing though that the server would offer
STARTTLS in spite of having already negotiated TLS. This seems to be a
first to be seen in the wild and reported - and this is what confused
fetchmail, which simply does not expect to see STARTTLS offered on a TLS
connection, and also would not use it, nor would that make sense. It
might be a configuration issue on your provider's servers. None of the
servers I've read conversations of would offer STARTTLS on a TLS-wrapped
connection.

>> 2- fetchmail misreporting the authentication failure with that WARNING
> OK, sslproto is (probably) correct, and that warning is incorrect.  Is
> there any other logging/warning/error configuration I can try to get better
> debugging of why authentication is failing?  Does fetchmail only see a
> success/fail, or is the next step to fire up wireshark:-)?

There isn't anything you can do but checking the provider's help and
news pages or contacting them.

The very first communication is the successful negotiation of TLS v1.2,
and after receiving the initial prompt, the first command that fetchmail
tries is A0001 LOGIN with your user and password, and that fails.
This is the *entire* conversation after the SSL negotiation, and
WireShark is not going to give you anything useful because fetchmail has
the cleartext conversation, but Wireshark only has the encrypted stuff,
and decoding that would be quite a bit of a hassle and a distraction
because you already have it...
https://wiki.wireshark.org/TLS#tls-decryption

> fetchmail: IMAP< * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID
> ENABLE IDLE SPECIAL-USE LITERAL+ STARTTLS AUTH=PLAIN AUTH=LOGIN] imap
> ready - cma-tmc
> fetchmail: IMAP> A0001 LOGIN "mpope" *
> fetchmail: IMAP< A0001 NO [AUTHENTICATIONFAILED] Authentication failed.
So... your provider will need to support you.

Re: [Fetchmail-users] Automatically decrypt fetched PGP/Mime mail?

[Peter P. <ro...@ri...>]

On Tue, Jun 25, 2024 at 11:10:31AM +0200, Carlos E. R. wrote:
> On 2024-06-25 03:55, q17nsisr--- via Fetchmail-users wrote:
> > Greetings fetchmail-users mailing list!!
> > 
> > My mail fetching setup currently looks like this:
> > remote mail server <-> fetch <-> local maildir <-> local mail server <-> local e-mail client
> > 
> > Where email on the remote mail server is pgp/mime encrypted with the subject header hidden or replaced as supported by several of the email services listed below:
> > https://www.privacyguides.org/en/email/ - Encrypted Private Email Recommendations - Privacy Guides
> > https://www.privacyguides.org/en/email-aliasing/ - Email Aliasing - Privacy Guides
> > 
> > I would like to alter the "... <-> fetch <-> local maildir <-> ..." part of my mail fetching setup so that the fetched email is automatically decrypted during or after the fetching process and before this mail is seen by the local mail server or email client.
> > Does anyone on this mailing list have any advice or tips for doing this?
> 
> Probably adding procmail and maybe formail.

SCNR, but I would really, really, really strongly recommend against using procmail
in the year 2024. Maildrop has a clear, easy to learn syntax, and it makes it much
harder to make a mistake writing a rule or to forget about any kind of unspecified
default behavior.

Also, I think the real issue here would be the fact that unattended decryption
would mean that there is a copy of the OpenPGP key that is either stored somewhere
unprotected (no passphrase), or is loaded into some kind of agent, again,
unprotected in memory. In either case this opens an avenue of attack for
Somebody(tm) to use that unprotected copy of the key, either for decrypting
other encrypted material they have obtained, or, if the key has multiple
capabilities, even for signing things.

Once that is dealt with (and "I don't care" is a way to deal with it, albeit
one that I would very strong discourage), there is also the interesting aspect of
making sure that the decrypted messages do NOT go into the same maildir or
IMAP folder or whatever as any unencrypted messages received, because then
there would be no way to tell if a certain message was encrypted and decrypted or
just looks like one. There is also an additional interesting aspect that
OpenPGP messages have more data in the OpenPGP structure, such as integrity
hashes, possibly a signature from the sender, etc, and some of that data may
be lost if only the decrypted copy is saved.

G'luck,
Peter

-- 
Peter Pentchev  ro...@ri... ro...@de... pe...@mo...
PGP key:        https://www.ringlet.net/roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

Re: [Fetchmail-users] Automatically decrypt fetched PGP/Mime mail?

[Carlos E. R. <rob...@te...>]

On 2024-06-25 03:55, q17nsisr--- via Fetchmail-users wrote:
> Greetings fetchmail-users mailing list!!
> 
> My mail fetching setup currently looks like this:
> remote mail server <-> fetch <-> local maildir <-> local mail server <-> local e-mail client
> 
> Where email on the remote mail server is pgp/mime encrypted with the subject header hidden or replaced as supported by several of the email services listed below:
> https://www.privacyguides.org/en/email/ - Encrypted Private Email Recommendations - Privacy Guides
> https://www.privacyguides.org/en/email-aliasing/ - Email Aliasing - Privacy Guides
> 
> I would like to alter the "... <-> fetch <-> local maildir <-> ..." part of my mail fetching setup so that the fetched email is automatically decrypted during or after the fetching process and before this mail is seen by the local mail server or email client.
> Does anyone on this mailing list have any advice or tips for doing this?

Probably adding procmail and maybe formail.

-- 
Cheers / Saludos,

		Carlos E. R.
		(from 15.5 x86_64 at Telcontar)

[Fetchmail-users] Automatically decrypt fetched PGP/Mime mail?

[<q17...@du...>]

Greetings fetchmail-users mailing list!!

My mail fetching setup currently looks like this:
remote mail server <-> fetch <-> local maildir <-> local mail server <-> local e-mail client

Where email on the remote mail server is pgp/mime encrypted with the subject header hidden or replaced as supported by several of the email services listed below:
https://www.privacyguides.org/en/email/ - Encrypted Private Email Recommendations - Privacy Guides
https://www.privacyguides.org/en/email-aliasing/ - Email Aliasing - Privacy Guides

I would like to alter the "... <-> fetch <-> local maildir <-> ..." part of my mail fetching setup so that the fetched email is automatically decrypted during or after the fetching process and before this mail is seen by the local mail server or email client.
Does anyone on this mailing list have any advice or tips for doing this?

Re: [Fetchmail-users] authentication fail

[Michael P. <mpo...@gm...>]

> 1-  a genuine issue with authentication (did the service change login
policies?

I fear there may have been a "quiet change" at the provider.  My
credentials are correct/unchanged for their webmail.

> 2- fetchmail misreporting the authentication failure with that WARNING

OK, sslproto is (probably) correct, and that warning is incorrect.  Is
there any other logging/warning/error configuration I can try to get better
debugging of why authentication is failing?  Does fetchmail only see a
success/fail, or is the next step to fire up wireshark:-)?

Cheers,
Mike Pope

Re: [Fetchmail-users] Fwd: authentication fail

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

Am 23.06.24 um 08:56 schrieb Michael Pope:
> I am currently unable to collect mail from a mail provider.  This has
> worked in the past.  The line in the logs:
>     fetchmail: imap.themessagingco.com.au: WARNING: server offered STARTTLS
> but sslproto '' given.
> looks pretty suspicious.
>
> OS: Fedora 40 Linux
> Package: fetchmail-6.4.38-1.fc40.x86_64
> MDA: procmail, though it never gets called
> Command line: just "fetchmail", however .fetchmailrc is:
>
> poll imap.themessagingco.com.au protocol IMAP port 993
>    auth password
>    user "mpope" password "*********"
>    ssl sslproto tls1.2+ sslcertck
>    mda "/usr/bin/procmail -o -d mpope"
>
> LC_ALL=C fetchmail -V: attached as fet1.log
> LC_ALL=C fetchmail --nodetach -vvv --nosyslog: attached as fet2.log

I have received the logs off-list, and the crucial part is:

> fetchmail: SSL/TLS: using protocol TLSv1.2, cipher
> ECDHE-RSA-AES256-GCM-SHA384, 256/256 secret/processed bits
> fetchmail: IMAP< * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID
> ENABLE IDLE SPECIAL-USE LITERAL+ STARTTLS AUTH=PLAIN AUTH=LOGIN] imap
> ready - cma-tmc
> fetchmail: Protocol identified as IMAP4 rev 1
> fetchmail: will idle after poll
> fetchmail: found updated capabilities list
> fetchmail: imap.themessagingco.com.au: WARNING: server offered
> STARTTLS but sslproto '' given.
> fetchmail: IMAP> A0001 LOGIN "mpope" *
> fetchmail: IMAP< A0001 NO [AUTHENTICATIONFAILED] Authentication failed.
> fetchmail: IMAP> A0002 LOGOUT
> fetchmail: IMAP< * BYE Logging out
> fetchmail: IMAP< A0002 OK Logout completed.
> fetchmail: 6.4.38 querying imap.themessagingco.com.au (protocol IMAP)
> at Sun Jun 23 16:16:45 2024: poll completed

Meaning there is

1-  a genuine issue with authentication (did the service change login
policies? Did someone or something change your password without your
knowing? Opt in to two-factor authentication or app passwords? In such a
case, you should create that app password for your IMAP clients and use
the app password in fetchmail), this is something you need to actively
sort out.  It seems the starting point for your mail service provider
would be
https://support.themessaging.co/hc/en-au/categories/21520592100633-How-do-I
and then read through the pages linked underneath "Password and Security
Management".

This is unrelated to the warning you are seeing.


2- fetchmail misreporting the authentication failure with that WARNING
and confusing you.
The program behaves correctly and aborts the poll after authentication
failure, but the warning you've seen clearly is a bug.
I need to fix that for a future release. That's not just a five-minute
thing though because the authentication driver is a touch nontrivial for
a code - with a few more ifs and thens.

Thanks for taking the time to report this, I've made a Gitlab issue from it:
https://gitlab.com/fetchmail/fetchmail/-/issues/64

Best regards,
Matthias

Re: [Fetchmail-users] Fwd: authentication fail

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

Am 23.06.24 um 08:56 schrieb Michael Pope:
> I am currently unable to collect mail from a mail provider.  This has
> worked in the past.  The line in the logs:
>     fetchmail: imap.themessagingco.com.au: WARNING: server offered STARTTLS
> but sslproto '' given.
> looks pretty suspicious.
>
> OS: Fedora 40 Linux
> Package: fetchmail-6.4.38-1.fc40.x86_64
> MDA: procmail, though it never gets called
> Command line: just "fetchmail", however .fetchmailrc is:
>
> poll imap.themessagingco.com.au protocol IMAP port 993
>    auth password
>    user "mpope" password "*********"
>    ssl sslproto tls1.2+ sslcertck
>    mda "/usr/bin/procmail -o -d mpope"
>
> LC_ALL=C fetchmail -V: attached as fet1.log
> LC_ALL=C fetchmail --nodetach -vvv --nosyslog: attached as fet2.log

Mike,

the list appears to strip off binary attachments, and many mailers
declare attachments as binary regardless of the content.

Sorry for the inconvenience - but please send the logs to me
off-list/directly and I'll have a look and see if I can do something (at
least fixing the error message to match the situation, which it clearly
does not in your case).

Seems there is one corner case in the imap.c code that might be a logic
bug. A log would help identifying this.

Sorry again.

Best regards,
Matthias

--
Matthias Andree

[Fetchmail-users] Fwd: authentication fail

[Michael P. <mpo...@gm...>]

I am currently unable to collect mail from a mail provider.  This has
worked in the past.  The line in the logs:
   fetchmail: imap.themessagingco.com.au: WARNING: server offered STARTTLS
but sslproto '' given.
looks pretty suspicious.

OS: Fedora 40 Linux
Package: fetchmail-6.4.38-1.fc40.x86_64
MDA: procmail, though it never gets called
Command line: just "fetchmail", however .fetchmailrc is:

poll imap.themessagingco.com.au protocol IMAP port 993
  auth password
  user "mpope" password "*********"
  ssl sslproto tls1.2+ sslcertck
  mda "/usr/bin/procmail -o -d mpope"

LC_ALL=C fetchmail -V: attached as fet1.log
LC_ALL=C fetchmail --nodetach -vvv --nosyslog: attached as fet2.log

Cheers,
Mike Pope