fetchmail-users — User questions and discussion

Re: [Fetchmail-users] FM v6.4.20 - concatenated log lines

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

Am 08.08.21 um 21:54 schrieb Matthias Andree:
> Am 08.08.21 um 20:07 schrieb J.Edner:
>> Hi,
>> I've just compiled and installed Fetchmail 6.4.20 on my server and found
>> out, that some log lines are missing a new-line at the end, so that they
>> are concatenated as follows:
>>
>> fetchmail: 16 messages for XYZ at SERVERfetchmail: reading message
>> XYZ@SERVER:1 of 16fetchmail: reading message XYZ@SERVER:2 of
>> 16fetchmail: reading message XYZ@SERVER:3 of 16fetchmail: reading
>> message ...
>>
>> I checked the source code and saw that a new-line seems to be missing.
>> After I've applied this small patch all messages are correctly written
>> to the log file again:
>>
>> ----------
>> --- a/driver.c. 2021-08-08 17:06:53.756148421 +0200
>> +++ b/driver.c  2021-08-08 17:09:20.231666827 +0200
>> @@ -629,7 +629,7 @@ static int fetch_messages(int mailserver
>>
>>         if (outlevel > O_SILENT)
>>         {
>> -         report_build(stdout, GT_("reading message %s@%s:%d of %d"),
>> +         report_build(stdout, GT_("reading message %s@%s:%d of %d\n"),
>>                          ctl->remotename, ctl->server.truename,
>>                          num, count);
>> ----------
>>
>> The result looks as follows now again:
>>
>> fetchmail: 16 messages for XYZ at SERVER
>> fetchmail: reading message XYZ@SERVER:1 of 16
>> fetchmail: reading message XYZ@SERVER:2 of 16
>> fetchmail: reading message XYZ@SERVER:3 of 16
>> ...

Got it.

There is one statement in report_build, "if (n > 0)
partial_message_size_used += n;" which slipped outside the #if
defined(VA_START)...#endif block and that causes an excess (double)
increment of the string length; because both report_vbuild() and then
again this cited statement will bump the partial_message_size_used
counter. In effect, the buffer allocation is excessive and, more
importantly, the 2nd and later report_build() before the next report()
or report_complete() write too deep into the buffer. This will not cause
overruns due to the reallocation prior to the vsnprintf/sprintf, but it
write starts behind the '\0' byte, instead of right over it, so the
string also gets truncated to the first fragment written with
report_vbuild().

This does not affect --syslog or console output so, for lack of relevant
test items, escaped my testing. Sorry about that.

This patch fixes the issue (this is for perusal, I am attaching a copy,
or if it doesn't make it through to the list, cherry-pick the report.c
part from Git commit d3db2da1). fetchmail 6.4.21 and revised security
announcement coming up, and 6.5.0-beta5 should not be too far out either.

https://gitlab.com/fetchmail/fetchmail/-/commit/d3db2da1d13bd2419370ad96defb92eecb17064c
https://sourceforge.net/p/fetchmail/git/ci/d3db2da1d13bd2419370ad96defb92eecb17064c/

diff --git a/report.c b/report.c
index aea6b3ea..2db7d0a9 100644
--- a/report.c
+++ b/report.c
@@ -286,10 +286,11 @@ report_build (FILE *errfp, message, va_alist)
     n = snprintf (partial_message + partial_message_size_used,
             partial_message_size - partial_message_size_used,
             message, a1, a2, a3, a4, a5, a6, a7, a8);
-#endif
 
     if (n > 0) partial_message_size_used += n;
 
+#endif
+
     if (unbuffered && partial_message_size_used != 0)
     {
     partial_message_size_used = 0;

Re: [Fetchmail-users] FM v6.4.20 - concatenated log lines

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

Am 08.08.21 um 20:07 schrieb J.Edner:
> Hi,
> I've just compiled and installed Fetchmail 6.4.20 on my server and found
> out, that some log lines are missing a new-line at the end, so that they
> are concatenated as follows:
>
> fetchmail: 16 messages for XYZ at SERVERfetchmail: reading message
> XYZ@SERVER:1 of 16fetchmail: reading message XYZ@SERVER:2 of
> 16fetchmail: reading message XYZ@SERVER:3 of 16fetchmail: reading
> message ...
>
> I checked the source code and saw that a new-line seems to be missing.
> After I've applied this small patch all messages are correctly written
> to the log file again:
>
> ----------
> --- a/driver.c. 2021-08-08 17:06:53.756148421 +0200
> +++ b/driver.c  2021-08-08 17:09:20.231666827 +0200
> @@ -629,7 +629,7 @@ static int fetch_messages(int mailserver
>
>         if (outlevel > O_SILENT)
>         {
> -         report_build(stdout, GT_("reading message %s@%s:%d of %d"),
> +         report_build(stdout, GT_("reading message %s@%s:%d of %d\n"),
>                          ctl->remotename, ctl->server.truename,
>                          num, count);
> ----------
>
> The result looks as follows now again:
>
> fetchmail: 16 messages for XYZ at SERVER
> fetchmail: reading message XYZ@SERVER:1 of 16
> fetchmail: reading message XYZ@SERVER:2 of 16
> fetchmail: reading message XYZ@SERVER:3 of 16
> ...

Hello Jürgen,

Thanks for the report, but the problem seems to be elsewhere, so the fix
consequently does not fit. It may fix your particular configuration, but
break with other configurations or command-line options.

report_build() is meant to "collect" log fragments at first, without
printing them immediately, and then there might be some size ticker
printed as the message is downloaded and forwarded, and ultimately,
there should be some other message (logged/printed with
report_complete()) that completes the log line and causes it to be printed.

I'll have a look - can you get me your configuration without passwords?
And the command line, too? Feel free to also mask the user/server names
in that case, but be sure to let all information about the destination
(mta, SMTP, LMTP, ... whatever) intact except possibly a nondefault
server name.

Thanks again.

Regards,
Matthias

[Fetchmail-users] FM v6.4.20 - concatenated log lines

[J.Edner <fli...@te...>]

Hi,
I've just compiled and installed Fetchmail 6.4.20 on my server and found
out, that some log lines are missing a new-line at the end, so that they
are concatenated as follows:

fetchmail: 16 messages for XYZ at SERVERfetchmail: reading message
XYZ@SERVER:1 of 16fetchmail: reading message XYZ@SERVER:2 of
16fetchmail: reading message XYZ@SERVER:3 of 16fetchmail: reading
message ...

I checked the source code and saw that a new-line seems to be missing.
After I've applied this small patch all messages are correctly written
to the log file again:

----------
--- a/driver.c. 2021-08-08 17:06:53.756148421 +0200
+++ b/driver.c  2021-08-08 17:09:20.231666827 +0200
@@ -629,7 +629,7 @@ static int fetch_messages(int mailserver

        if (outlevel > O_SILENT)
        {
-         report_build(stdout, GT_("reading message %s@%s:%d of %d"),
+         report_build(stdout, GT_("reading message %s@%s:%d of %d\n"),
                         ctl->remotename, ctl->server.truename,
                         num, count);
----------

The result looks as follows now again:

fetchmail: 16 messages for XYZ at SERVER
fetchmail: reading message XYZ@SERVER:1 of 16
fetchmail: reading message XYZ@SERVER:2 of 16
fetchmail: reading message XYZ@SERVER:3 of 16
...

Regards
Juergen

[Fetchmail-users] ANNOUNCE: The 6.5.0.beta4 snapshot of fetchmail is available (security fix for CVE-2021-36386)

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

Greetings,

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

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

This is a deep link to the GnuPG signature:
<https://sourceforge.net/projects/fetchmail/files/branch_6.5/fetchmail-6.5.0.beta4.tar.xz.asc/download>

This merges the recent 6.4.20 security fix for CVE-2021-36386, 
with these additional changes:

* 1c214c45 2021-07-07 | mock POP3 test server updates
* 2cc88ec4 2021-06-26 | GitLab CI
* 462b5c38 2021-05-15 | CMakeLists.txt: only compile getopt* if getopt_long() missing.
* a6f29dc5 2021-05-13 | Rudimentary unusable attempt at a CMakeLists file.
* c7b820b1 2021-04-26 | fetchmail.man: really bump version to beta3 to match release.
* 57bd6a92 2021-04-26 | imap.c: correct EXPUNGE count -> EXPUNGE message no.

Here are the release notes:

--------------------------------------------------------------------------------
fetchmail-6.5.0 (not yet released):

## 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.

## 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,
  at a minimum OpenSSL v1.1.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.0. (fetchmail was requesting to hide
  deprecated APIs.)

## 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.

## 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.0-alpha4.
* 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.
================================================================================

Re: [Fetchmail-users] CVE-2021-36386 and fetchmail 6.5.0-beta3

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

Am 29.07.21 um 13:15 schrieb Andrew C Aitchison:
>
> Does 6.5.0-beta3 suffer from CVE-2021-36386 ?
>
> I have been running 6.5.0-beta3 without problems since April.
>
> Is a beta4 or a release candidate expected soon ?
>
> Thanks,
>
Hi Andrew,

yes it does have the same bug, and in practice it seems to hit rarely
and it is highly dependent on the system and configuration whether it
causes practical issues - this bug has been in the code for many years
and was only recently discovered...

I will merge the fix back and release a new 6.5.0-beta4 the next days.

Regards,

--
Matthias Andree

[Fetchmail-users] CVE-2021-36386 and fetchmail 6.5.0-beta3

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

Does 6.5.0-beta3 suffer from CVE-2021-36386 ?

I have been running 6.5.0-beta3 without problems since April.

Is a beta4 or a release candidate expected soon ?

Thanks,

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

[Fetchmail-users] ANNOUNCE: fetchmail security announcement 2021-01 (CVE-2021-36386) - potential denial of service or information disclosure in some configurations

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

fetchmail-SA-2021-01: DoS or information disclosure logging long messages

Topics:		fetchmail denial of service or information disclosure when logging long messages

Author:		Matthias Andree
Version:	1.1
Announced:	2021-07-28
Type:		missing variable initialization can cause read from bad memory 
		locations
Impact:		fetchmail logs random information, or segfaults and aborts, 
		stalling inbound mail
Danger:		low
Acknowledgment:	Christian Herdtweck, Intra2net AG, Tübingen, Germany
		for analysis and report and a patch suggestion

CVE Name:	CVE-2021-36386
URL:		https://www.fetchmail.info/fetchmail-SA-2021-01.txt
Project URL:	https://www.fetchmail.info/

Affects:	- fetchmail releases up to and including 6.4.19

Not affected:	- fetchmail releases 6.4.20 and newer

Corrected in:	c546c829 Git commit hash

		2021-07-28 fetchmail 6.4.20 release tarball


0. Release history
==================

2021-07-07	initial report to maintainer
2021-07-28 1.0	release
2021-07-28 1.1	update Git commit hash with correction


1. Background
=============

fetchmail is a software package to retrieve mail from remote POP3, IMAP,
ETRN or ODMR servers and forward it to local SMTP, LMTP servers or
message delivery agents. fetchmail supports SSL and TLS security layers
through the OpenSSL library, if enabled at compile time and if also
enabled at run time, in both SSL/TLS-wrapped mode on dedicated ports as
well as in-band-negotiated "STARTTLS" and "STLS" modes through the
regular protocol ports.


2. Problem description and Impact
=================================

Fetchmail has long had support to assemble log/error messages that are 
generated piecemeal, and takes care to reallocate the output buffer as needed.  
In the reallocation case, i. e. when long log messages are assembled that can 
stem from very long headers, and on systems that have a varargs.h/stdarg.h 
interface (all modern systems), fetchmail's code would fail to reinitialize 
the va_list argument to vsnprintf. 

The exact effects depend on the verbose mode (how many -v are given) of 
fetchmail, computer architecture, compiler, operating system and 
configuration.  On some systems, the code just works without ill effects, some 
systems log a garbage message (potentially disclosing sensitive information), 
some systems log literally "(null)", some systems trigger SIGSEGV (signal 
#11), which crashes fetchmail, causing a denial of service on fetchmail's end.


3. Solution
===========

Install fetchmail 6.4.20 or newer.

The fetchmail source code is available from
<https://sourceforge.net/projects/fetchmail/files/>.

Distributors are encouraged to review the NEWS file and move forward to 
6.4.20, rather than backport individual security fixes, because doing so 
routinely misses other fixes crucial to fetchmail's proper operation, 
for which no security announcements are issued, or documentation,
or translation updates.

Fetchmail 6.4.X releases have been made with a focus on unchanged user and 
program interfaces so as to avoid disruptions when upgrading from 6.3.Z or 
6.4.X to 6.4.Y with Y > X.  Care was taken to not change the interface 
incompatibly.


A. Copyright, License and Non-Warranty
======================================

(C) Copyright 2021 by Matthias Andree, <mat...@gm...>.
Some rights reserved.

fetchmail-SA-2021-01 © 2021 by Matthias Andree is licensed under CC 
BY-ND 4.0. To view a copy of this license, visit 
http://creativecommons.org/licenses/by-nd/4.0/

THIS WORK IS PROVIDED FREE OF CHARGE AND WITHOUT ANY WARRANTIES.
Use the information herein at your own risk.

END of fetchmail-SA-2021-01

[Fetchmail-users] ANNOUNCE: The 6.4.20 release of fetchmail is available (security update CVE-2021-36386)

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

Greetings,

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

It contains an LMTP bug fix, updates fetchmailconf and the Serbian 
translation.

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

Detached GnuPG signatures for the respective tarballs are at:
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.20.tar.xz.asc/download>
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.20.tar.lz.asc/download>

SHA256 hash values for the tarballs:
SHA256(fetchmail-6.4.20.tar.lz)= 497973353c0538216e7d7f2289a21d9acc5edd78f06d7ec008001f4f19e91b11
SHA256(fetchmail-6.4.20.tar.xz)= c82141ae2e8f0039ceb0c5c2eda43c5e93ad0bf7f9c6bb628092b3be74386176

Here are the release notes:

---------------------------------------------------------------------------------
fetchmail-6.4.20 (released 2021-07-28, 30042 LoC):

# SECURITY FIX:
* When a log message exceeds c. 2 kByte in size, for instance, with very long 
  header contents, and depending on verbosity option, fetchmail can crash or
  misreport each first log message that requires a buffer reallocation.
  fetchmail then reallocates memory and re-runs vsnprintf() without another 
  call to va_start(), so it reads garbage. The exact impact depends on 
  many factors around the compiler and operating system configurations used and 
  the implementation details of the stdarg.h interfaces of the two functions
  mentioned before. To fix CVE-2021-38386.

  Reported by Christian Herdtweck of Intra2net AG, Tübingen, Germany.
---------------------------------------------------------------------------------

Happy fetches,
Matthias

Re: [Fetchmail-users] Earthlink changed its incoming server names

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

Am 08.06.21 um 02:38 schrieb Gene Heskett:
> On Monday 07 June 2021 20:33:15 Michael Burgoon wrote:
>
>> It appears that EarthLink is having some serious technical problems.
>> I’m getting all sorts of errors from all my devices that, up to now,
>> have had no issues. Everything works fine for a couple days, then it
>> all goes south.
>>
>> I’m thinking that my original problem was related to their issues. I
>> went back and put -U back and it worked fine.  Sorry to bother you
>> with someone else’s problem.
>>
>> However, please tell me how to run fetch mail at startup under an id
>> other than root. There’s not a lot I can do about pop’s lack of
>> security. They support a pop, but that’s it, they want you to use IMAP
>> where they support SSL. Can fetchmail be used with IMAP, and still
>> delete the emails on the server when it retrieves them?
>>
>> Best,
>>
>> Mike B
> In one word, Mike, yes. I am doing it.

Gene, Thanks for that one, had missed it.

Mike, and just one remark to add: this works best if you have no other
client marking the mail as read, or if you use fetchmail with "all" and
"nokeep".

fetchmail's IMAP mode does not have an equivalent of POP3's --uidl yet
(as of 6.4.x and older versions), and it by default only retrieves
unread e-mail in IMAP mode. 

HTH
Matthias

Re: [Fetchmail-users] Earthlink changed its incoming server names

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

Am 08.06.21 um 02:33 schrieb Michael Burgoon:
> It appears that EarthLink is having some serious technical problems. I’m getting all sorts of errors from all my devices that, up to now, have had no issues. Everything works fine for a couple days, then it all goes south.
>
> I’m thinking that my original problem was related to their issues. I went back and put -U back and it worked fine.  Sorry to bother you with someone else’s problem.

No worries, I however found it necessary to not confuse readers of the
mailing list archives with debugging that went into a dead end because
the real cause was a server-side issue - and the -U or --uidl thing
can't manifest if you have login troubles because fetchmail does not get
to the point where it might probe LAST, UIDL, or thereabouts, at all.

> However, please tell me how to run fetch mail at startup under an id other than root. There’s not a lot I can do about pop’s lack of security. They support a pop, but that’s it, they want you to use IMAP where they support SSL. Can fetchmail be used with IMAP, and still delete the emails on the server when it retrieves them?

I recall this was some embedded system, NAS or thereabouts? I am
unfamiliar with their operating systems.

How you do what you want depends a bit on the operating system
facilities and how you forward mail to your regular user.

If you have regular user accounts such as mike, michael or mburgoon on
your system running fetchmail, and you have an SMTP or LMTP setup to
inject mail into, just set fetchmail up for the user by means of
.fetchmailrc and possibly copy the root user's .fetchids to the user and
change ownership of the file, and make sure you have something that
starts fetchmail on boot or after crashes. Since you use daemon mode, a
cronjob would be fine, since if fetchmail were already running you'd
just wake the existing instance and otherwise launch a new one.

Regards,
Matthias

Re: [Fetchmail-users] Earthlink changed its incoming server names

[Gene H. <ghe...@sh...>]

On Monday 07 June 2021 20:33:15 Michael Burgoon wrote:

> It appears that EarthLink is having some serious technical problems.
> I’m getting all sorts of errors from all my devices that, up to now,
> have had no issues. Everything works fine for a couple days, then it
> all goes south.
>
> I’m thinking that my original problem was related to their issues. I
> went back and put -U back and it worked fine.  Sorry to bother you
> with someone else’s problem.
>
> However, please tell me how to run fetch mail at startup under an id
> other than root. There’s not a lot I can do about pop’s lack of
> security. They support a pop, but that’s it, they want you to use IMAP
> where they support SSL. Can fetchmail be used with IMAP, and still
> delete the emails on the server when it retrieves them?
>
> Best,
>
> Mike B

In one word, Mike, yes. I am doing it.

>
> On Jun 7, 2021, at 1:35 PM, Matthias Andree <mat...@gm...>
> wrote:
>
> Am 06.06.21 um 21:53 schrieb Michael Burgoon:
> > Hi Matthias,
> >
> > Sorry for the late reply, I did not have access to my server last
> > week.  I have it running finally.  Simple fix, I had to remove the
> > -U parameter from the ARGS list in S52fetchmail:
> >
> > *ARGS*="-d 60 -f /opt/etc/fetchmailrc -v —syslog"
> >
> > which now accesses the account mburgoon.with.mainspring.com
> > <http://mburgoon.with.mainspring.com> on server pop.earthlink.net
> > <http://pop.earthlink.net> properly.
> >
> > Mike B
>
> Hi Mike,
>
> no worries about the reply timing, but you've got me confused now with
> /what/ you are writing.
>
> Your logs clearly showed login issues, i. e. user and password worng,
> and now you are reporting that removing the "-U" or "--uidl" option
> fixes things.
>
> It seems you did more than what was reported, or I missed it.
>
> Did you also change your username or password? Because without that
> you would not ever get to a point where adding or omitting -U (or
> --uidl or uidl in the rcfile for that matter) could have made a
> difference.
>
> Also, Earthlink's CAPA replies *does* include UIDL and UIDL is the
> reliable "have I downloaded message 12345" tracker... so what was
> *really* going on?
>
> Regards,
> Matthias
>
> > On Jun 1, 2021, at 1:03 PM, Matthias Andree <mat...@gm...
> > <mailto:mat...@gm...>> wrote:
> >
> > Am 29.05.21 um 09:01 schrieb Matthias Andree:
> >> Am 26.05.21 um 20:29 schrieb Matthias Andree:
> >>> Michael,
> >>>
> >>> please do provide logs from a "fetchmail -Nvvd0" run, the
> >>> authorization error mailed to you by the daemon is pretty generic,
> >>> the verbose log may indeed provide more details.
> >>> Also if possible don't post HTML and/or with a mailer that
> >>> converts the server names to would-be links...
> >>
> >> I've received Michael's logs off-list, and some remarks:
> >>
> >> - it is really the username/password combination that gets refused
> >>
> >> - it would however seem that with a mindspring.com
> >> <http://mindspring.com> address the earthlink
> >> server should be used, but a mindspring server, and the network
> >> configuration and also server identifications are different, see
> >> https://help.earthlink.net/portal/en/kb/articles/email-server-setti
> >>ngs
> >> <https://help.earthlink.net/portal/en/kb/articles/email-server-sett
> >>ings> -
> >> so try that first.
> >>
> >> And more observations:
> >>
> >> - pop.earthlink.net <http://pop.earthlink.net> seems to be pretty
> >> antediluvian with respect to
> >> protecting passwords over the wire. No SSL service, no STLS, only
> >> APOP as a very mild means to mitigate password theft.
> >>
> >> - fetchmail 6.3.26 is eight years old. Was this shipped by Synology
> >> or is that third-party?
> >> We have 6.4.19... and it shows fetchmail running as root, which is
> >> not how it should be.
> >>
> >> Hope that helps.
> >>
> >> Regards,
> >> Matthias
> >
> > Hi Michael,
> >
> > Judging from further off-list logs that I've received and that show
> > a telnet console log chatting POP3, I suggest to change the
> > configuration from ... user mburgoon... to user
> > "mburgoon.with.mindspring.com <http://mburgoon.with.mindspring.com>"
> > (replace the .with. by @, I just don't want to feed archive address
> > harvesters).
> >
> > This will likely then cause some strange-looking logging around
> > you...@mi...
> > <mailto:you...@mi...>@earthlink.net, but might actually
> > work.   If you
> > can establish that, you might want to experiment with APOP and see
> > if Earthlink support that and in that case switch to it, as that's
> > the minimal projection against sending passwords as cleartext
> > through unencrypted links.
> >
> > My concerns around not providing any sort of TLS stand. Everyone
> > working off some sort of internet service provider who does not
> > support TLS for mail retrieval might want to consider contacting
> > their support about TLS and if that's fruitless, consider switching
> > provider.
> >
> > HTH
> > Matthias
> >
> >
> > _______________________________________________
> > Fetchmail-users mailing list
> > Fet...@li...
> > <mailto:Fet...@li...>
> > https://lists.sourceforge.net/lists/listinfo/fetchmail-users
>
> _______________________________________________
> Fetchmail-users mailing list
> Fet...@li...
> https://lists.sourceforge.net/lists/listinfo/fetchmail-users


Cheers, 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>

Re: [Fetchmail-users] Earthlink changed its incoming server names

[Michael B. <mbu...@mi...>]

It appears that EarthLink is having some serious technical problems. I’m getting all sorts of errors from all my devices that, up to now, have had no issues. Everything works fine for a couple days, then it all goes south.

I’m thinking that my original problem was related to their issues. I went back and put -U back and it worked fine.  Sorry to bother you with someone else’s problem.

However, please tell me how to run fetch mail at startup under an id other than root. There’s not a lot I can do about pop’s lack of security. They support a pop, but that’s it, they want you to use IMAP where they support SSL. Can fetchmail be used with IMAP, and still delete the emails on the server when it retrieves them?

Best,

Mike B

On Jun 7, 2021, at 1:35 PM, Matthias Andree <mat...@gm...> wrote:

Am 06.06.21 um 21:53 schrieb Michael Burgoon:
> Hi Matthias,
> 
> Sorry for the late reply, I did not have access to my server last
> week.  I have it running finally.  Simple fix, I had to remove the -U
> parameter from the ARGS list in S52fetchmail:
> 
> *ARGS*="-d 60 -f /opt/etc/fetchmailrc -v —syslog"
> 
> which now accesses the account mburgoon.with.mainspring.com
> <http://mburgoon.with.mainspring.com> on server pop.earthlink.net
> <http://pop.earthlink.net> properly.
> 
> Mike B
> 
> 
Hi Mike,

no worries about the reply timing, but you've got me confused now with
/what/ you are writing.

Your logs clearly showed login issues, i. e. user and password worng,
and now you are reporting that removing the "-U" or "--uidl" option
fixes things.

It seems you did more than what was reported, or I missed it.

Did you also change your username or password? Because without that you
would not ever get to a point where adding or omitting -U (or --uidl or
uidl in the rcfile for that matter) could have made a difference.

Also, Earthlink's CAPA replies *does* include UIDL and UIDL is the
reliable "have I downloaded message 12345" tracker... so what was
*really* going on?

Regards,
Matthias


> On Jun 1, 2021, at 1:03 PM, Matthias Andree <mat...@gm...
> <mailto:mat...@gm...>> wrote:
> 
> Am 29.05.21 um 09:01 schrieb Matthias Andree:
>> Am 26.05.21 um 20:29 schrieb Matthias Andree:
>>> Michael,
>>> 
>>> please do provide logs from a "fetchmail -Nvvd0" run, the authorization
>>> error mailed to you by the daemon is pretty generic, the verbose log may
>>> indeed provide more details.
>>> Also if possible don't post HTML and/or with a mailer that converts the
>>> server names to would-be links...
>>> 
>> I've received Michael's logs off-list, and some remarks:
>> 
>> - it is really the username/password combination that gets refused
>> 
>> - it would however seem that with a mindspring.com
>> <http://mindspring.com> address the earthlink
>> server should be used, but a mindspring server, and the network
>> configuration and also server identifications are different, see
>> https://help.earthlink.net/portal/en/kb/articles/email-server-settings
>> <https://help.earthlink.net/portal/en/kb/articles/email-server-settings>
>> -
>> so try that first.
>> 
>> And more observations:
>> 
>> - pop.earthlink.net <http://pop.earthlink.net> seems to be pretty
>> antediluvian with respect to
>> protecting passwords over the wire. No SSL service, no STLS, only APOP
>> as a very mild means to mitigate password theft.
>> 
>> - fetchmail 6.3.26 is eight years old. Was this shipped by Synology or
>> is that third-party?
>> We have 6.4.19... and it shows fetchmail running as root, which is not
>> how it should be.
>> 
>> Hope that helps.
>> 
>> Regards,
>> Matthias
> 
> Hi Michael,
> 
> Judging from further off-list logs that I've received and that show a
> telnet console log chatting POP3, I suggest to change the configuration
> from ... user mburgoon... to user "mburgoon.with.mindspring.com
> <http://mburgoon.with.mindspring.com>" 
> (replace the .with. by @, I just don't want to feed archive address
> harvesters).
> 
> This will likely then cause some strange-looking logging around
> you...@mi...
> <mailto:you...@mi...>@earthlink.net, but might actually
> work.   If you
> can establish that, you might want to experiment with APOP and see if
> Earthlink support that and in that case switch to it, as that's the
> minimal projection against sending passwords as cleartext through
> unencrypted links.
> 
> My concerns around not providing any sort of TLS stand. Everyone working
> off some sort of internet service provider who does not support TLS for
> mail retrieval might want to consider contacting their support about TLS
> and if that's fruitless, consider switching provider.
> 
> HTH
> Matthias
> 
> 
> _______________________________________________
> Fetchmail-users mailing list
> Fet...@li...
> <mailto:Fet...@li...>
> https://lists.sourceforge.net/lists/listinfo/fetchmail-users
> 

Re: [Fetchmail-users] Earthlink changed its incoming server names

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

Am 06.06.21 um 21:53 schrieb Michael Burgoon:
> Hi Matthias,
>
> Sorry for the late reply, I did not have access to my server last
> week.  I have it running finally.  Simple fix, I had to remove the -U
> parameter from the ARGS list in S52fetchmail:
>
> *ARGS*="-d 60 -f /opt/etc/fetchmailrc -v —syslog"
>
> which now accesses the account mburgoon.with.mainspring.com
> <http://mburgoon.with.mainspring.com> on server pop.earthlink.net
> <http://pop.earthlink.net> properly.
>
> Mike B
>
>
Hi Mike,

no worries about the reply timing, but you've got me confused now with
/what/ you are writing.

Your logs clearly showed login issues, i. e. user and password worng,
and now you are reporting that removing the "-U" or "--uidl" option
fixes things.

It seems you did more than what was reported, or I missed it.

Did you also change your username or password? Because without that you
would not ever get to a point where adding or omitting -U (or --uidl or
uidl in the rcfile for that matter) could have made a difference.

Also, Earthlink's CAPA replies *does* include UIDL and UIDL is the
reliable "have I downloaded message 12345" tracker... so what was
*really* going on?

Regards,
Matthias


> On Jun 1, 2021, at 1:03 PM, Matthias Andree <mat...@gm...
> <mailto:mat...@gm...>> wrote:
>
> Am 29.05.21 um 09:01 schrieb Matthias Andree:
>> Am 26.05.21 um 20:29 schrieb Matthias Andree:
>>> Michael,
>>>
>>> please do provide logs from a "fetchmail -Nvvd0" run, the authorization
>>> error mailed to you by the daemon is pretty generic, the verbose log may
>>> indeed provide more details.
>>> Also if possible don't post HTML and/or with a mailer that converts the
>>> server names to would-be links...
>>>
>> I've received Michael's logs off-list, and some remarks:
>>
>> - it is really the username/password combination that gets refused
>>
>> - it would however seem that with a mindspring.com
>> <http://mindspring.com> address the earthlink
>> server should be used, but a mindspring server, and the network
>> configuration and also server identifications are different, see
>> https://help.earthlink.net/portal/en/kb/articles/email-server-settings
>> <https://help.earthlink.net/portal/en/kb/articles/email-server-settings>
>> -
>> so try that first.
>>
>> And more observations:
>>
>> - pop.earthlink.net <http://pop.earthlink.net> seems to be pretty
>> antediluvian with respect to
>> protecting passwords over the wire. No SSL service, no STLS, only APOP
>> as a very mild means to mitigate password theft.
>>
>> - fetchmail 6.3.26 is eight years old. Was this shipped by Synology or
>> is that third-party?
>> We have 6.4.19... and it shows fetchmail running as root, which is not
>> how it should be.
>>
>> Hope that helps.
>>
>> Regards,
>> Matthias
>
> Hi Michael,
>
> Judging from further off-list logs that I've received and that show a
> telnet console log chatting POP3, I suggest to change the configuration
> from ... user mburgoon... to user "mburgoon.with.mindspring.com
> <http://mburgoon.with.mindspring.com>" 
> (replace the .with. by @, I just don't want to feed archive address
> harvesters).
>
> This will likely then cause some strange-looking logging around
> you...@mi...
> <mailto:you...@mi...>@earthlink.net, but might actually
> work.   If you
> can establish that, you might want to experiment with APOP and see if
> Earthlink support that and in that case switch to it, as that's the
> minimal projection against sending passwords as cleartext through
> unencrypted links.
>
> My concerns around not providing any sort of TLS stand. Everyone working
> off some sort of internet service provider who does not support TLS for
> mail retrieval might want to consider contacting their support about TLS
> and if that's fruitless, consider switching provider.
>
> HTH
> Matthias
>
>
> _______________________________________________
> Fetchmail-users mailing list
> Fet...@li...
> <mailto:Fet...@li...>
> https://lists.sourceforge.net/lists/listinfo/fetchmail-users
>

Re: [Fetchmail-users] Earthlink changed its incoming server names

[Michael B. <mbu...@mi...>]

Hi Matthias,

Sorry for the late reply, I did not have access to my server last week.  I have it running finally.  Simple fix, I had to remove the -U parameter from the ARGS list in S52fetchmail:

ARGS="-d 60 -f /opt/etc/fetchmailrc -v —syslog"

which now accesses the account mburgoon.with.mainspring.com on server pop.earthlink.net properly.

Mike B


On Jun 1, 2021, at 1:03 PM, Matthias Andree <mat...@gm...> wrote:

Am 29.05.21 um 09:01 schrieb Matthias Andree:
> Am 26.05.21 um 20:29 schrieb Matthias Andree:
>> Michael,
>> 
>> please do provide logs from a "fetchmail -Nvvd0" run, the authorization
>> error mailed to you by the daemon is pretty generic, the verbose log may
>> indeed provide more details.
>> Also if possible don't post HTML and/or with a mailer that converts the
>> server names to would-be links...
>> 
> I've received Michael's logs off-list, and some remarks:
> 
> - it is really the username/password combination that gets refused
> 
> - it would however seem that with a mindspring.com address the earthlink
> server should be used, but a mindspring server, and the network
> configuration and also server identifications are different, see
> https://help.earthlink.net/portal/en/kb/articles/email-server-settings -
> so try that first.
> 
> And more observations:
> 
> - pop.earthlink.net seems to be pretty antediluvian with respect to
> protecting passwords over the wire. No SSL service, no STLS, only APOP
> as a very mild means to mitigate password theft.
> 
> - fetchmail 6.3.26 is eight years old. Was this shipped by Synology or
> is that third-party?
> We have 6.4.19... and it shows fetchmail running as root, which is not
> how it should be.
> 
> Hope that helps.
> 
> Regards,
> Matthias

Hi Michael,

Judging from further off-list logs that I've received and that show a
telnet console log chatting POP3, I suggest to change the configuration
from ... user mburgoon... to user "mburgoon.with.mindspring.com" 
(replace the .with. by @, I just don't want to feed archive address
harvesters).

This will likely then cause some strange-looking logging around
you...@mi...@earthlink.net, but might actually work.   If you
can establish that, you might want to experiment with APOP and see if
Earthlink support that and in that case switch to it, as that's the
minimal projection against sending passwords as cleartext through
unencrypted links.

My concerns around not providing any sort of TLS stand. Everyone working
off some sort of internet service provider who does not support TLS for
mail retrieval might want to consider contacting their support about TLS
and if that's fruitless, consider switching provider.

HTH
Matthias


_______________________________________________
Fetchmail-users mailing list
Fet...@li...
https://lists.sourceforge.net/lists/listinfo/fetchmail-users

Re: [Fetchmail-users] Earthlink changed its incoming server names

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

Am 29.05.21 um 09:01 schrieb Matthias Andree:
> Am 26.05.21 um 20:29 schrieb Matthias Andree:
>> Michael,
>>
>> please do provide logs from a "fetchmail -Nvvd0" run, the authorization
>> error mailed to you by the daemon is pretty generic, the verbose log may
>> indeed provide more details.
>> Also if possible don't post HTML and/or with a mailer that converts the
>> server names to would-be links...
>>
> I've received Michael's logs off-list, and some remarks:
>
> - it is really the username/password combination that gets refused
>
> - it would however seem that with a mindspring.com address the earthlink
> server should be used, but a mindspring server, and the network
> configuration and also server identifications are different, see
> https://help.earthlink.net/portal/en/kb/articles/email-server-settings -
> so try that first.
>
> And more observations:
>
> - pop.earthlink.net seems to be pretty antediluvian with respect to
> protecting passwords over the wire. No SSL service, no STLS, only APOP
> as a very mild means to mitigate password theft.
>
> - fetchmail 6.3.26 is eight years old. Was this shipped by Synology or
> is that third-party?
> We have 6.4.19... and it shows fetchmail running as root, which is not
> how it should be.
>
> Hope that helps.
>
> Regards,
> Matthias

Hi Michael,

Judging from further off-list logs that I've received and that show a
telnet console log chatting POP3, I suggest to change the configuration
from ... user mburgoon... to user "mburgoon.with.mindspring.com" 
(replace the .with. by @, I just don't want to feed archive address
harvesters).

This will likely then cause some strange-looking logging around
you...@mi...@earthlink.net, but might actually work.   If you
can establish that, you might want to experiment with APOP and see if
Earthlink support that and in that case switch to it, as that's the
minimal projection against sending passwords as cleartext through
unencrypted links.

My concerns around not providing any sort of TLS stand. Everyone working
off some sort of internet service provider who does not support TLS for
mail retrieval might want to consider contacting their support about TLS
and if that's fruitless, consider switching provider.

HTH
Matthias

Re: [Fetchmail-users] Earthlink changed its incoming server names

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

Am 26.05.21 um 20:29 schrieb Matthias Andree:
> Michael,
>
> please do provide logs from a "fetchmail -Nvvd0" run, the authorization
> error mailed to you by the daemon is pretty generic, the verbose log may
> indeed provide more details.
> Also if possible don't post HTML and/or with a mailer that converts the
> server names to would-be links...
>
I've received Michael's logs off-list, and some remarks:

- it is really the username/password combination that gets refused

- it would however seem that with a mindspring.com address the earthlink
server should be used, but a mindspring server, and the network
configuration and also server identifications are different, see
https://help.earthlink.net/portal/en/kb/articles/email-server-settings -
so try that first.

And more observations:

- pop.earthlink.net seems to be pretty antediluvian with respect to
protecting passwords over the wire. No SSL service, no STLS, only APOP
as a very mild means to mitigate password theft.

- fetchmail 6.3.26 is eight years old. Was this shipped by Synology or
is that third-party?
We have 6.4.19... and it shows fetchmail running as root, which is not
how it should be.

Hope that helps.

Regards,
Matthias

Re: [Fetchmail-users] Earthlink changed its incoming server names

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

Michael,

please do provide logs from a "fetchmail -Nvvd0" run, the authorization
error mailed to you by the daemon is pretty generic, the verbose log may
indeed provide more details.
Also if possible don't post HTML and/or with a mailer that converts the
server names to would-be links...

Thanks.

Regards,
Matthias

[Fetchmail-users] Earthlink changed its incoming server names

[Michael B. <mbu...@mi...>]

Hi,

This isn’t a bug report but a configuration question:

I’m using fetchmail on a Synology DSM server running DSM 6.2.3. 
My email address is mbu...@Mi... <mailto:mbu...@Mi...>
My old fetchmailrc file, below, worked until Earthlink changed their server locations:

# Edit carefully, see the fetchmail(1) manual page, section "THE RUN CONTROL FILE".

poll pop.mindspring.com <http://pop.mindspring.com/> proto pop3 user "mburgoon" password “*", is "mbu...@mb... <mailto:mbu...@mb...>” here

recently Earthlink disabled the pop.mindspring.com <http://pop.mindspring.com/> domain and made me change to pop.earthlink.net <http://pop.earthlink.net/>,  I changed my fetchmailrc file to the following below with the error messages I received:

# Edit carefully, see the fetchmail(1) manual page, section "THE RUN CONTROL FILE".

poll  pop.earthlink.net <http://pop.earthlink.net/> proto pop3 user "mburgoon" password “*", is "mbu...@mb... <mailto:mbu...@mb...>” here

Error from fetcmail:
Fetchmail could not get mail from mbu...@po... <mailto:mbu...@po...>.

The attempt to get authorization failed.
This probably means your password is invalid, but some servers have
other failure modes that fetchmail cannot distinguish from this
because they don't send useful error messages on login failure.

The fetchmail daemon will continue running and attempt to connect
at each cycle.  No future notifications will be sent until service
is restored.
-- 
The Fetchmail Daemon


So I tried the following:

# Edit carefully, see the fetchmail(1) manual page, section "THE RUN CONTROL FILE".

poll  pop.earthlink.net <http://pop.earthlink.net/> proto pop3 user “mbu...@mi... <mailto:mbu...@mi...>" password “*", is "mbu...@mb... <mailto:mbu...@mb...>” here

Error from fetchmail:
Fetchmail could not get mail from mbu...@po... <mailto:mbu...@po...>.

The attempt to get authorization failed.
This probably means your password is invalid, but some servers have
other failure modes that fetchmail cannot distinguish from this
because they don't send useful error messages on login failure.

The fetchmail daemon will continue running and attempt to connect
at each cycle.  No future notifications will be sent until service
is restored.
-- 
The Fetchmail Daemon

I tried one more time with the following:

# Edit carefully, see the fetchmail(1) manual page, section "THE RUN CONTROL FILE".

poll ppop.earthlink.net <http://ppop.earthlink.net/> proto pop3 localdomains mindspring.com <http://mindspring.com/> user "mburgoon" password “*", is "mbu...@mb... <mailto:mbu...@mb...>” here

and got the following error from fetchmail:
Fetchmail could not get mail from mbu...@po... <mailto:mbu...@po...>.

The attempt to get authorization failed.
This probably means your password is invalid, but some servers have
other failure modes that fetchmail cannot distinguish from this
because they don't send useful error messages on login failure.

The fetchmail daemon will continue running and attempt to connect
at each cycle.  No future notifications will be sent until service
is restored.
-- 
The Fetchmail Daemon

I can send the log file, but it just says pretty much the same thing.  I don’t know how to tell pop.earthlink.net <http://pop.earthlink.net/> that it should be looking for mbu...@mi... <mailto:mbu...@mi...>.  Can you tell me what I’m doing wrong? I’m sure its a simple configuration parameter, but I can’t find it.

Thanks!

Mike Burgoon
mbu...@Mi... <mailto:mbu...@Mi...>

Re: [Fetchmail-users] fetchmail expunge error

[Alan D. S. <sal...@at...>]

On 2021-04-26 19:31:23, Matthias Andree <mat...@gm...> spake thus:
>Am 26.04.21 um 14:46 schrieb Leslie Rhorer:
>>
>> On 4/25/2021 9:15 PM, Alan D. Salewski wrote:
[...]

>>> Yes, the below fetchmail config line is what I use to pull mail from
>>> AT&T via
>>> POP3, but I am doing it from 'inbound.att.net':
>>>
>>>     poll inbound.att.net port 995 protocol pop3 timeout 120 uidl
>>> username "my-...@at..." ssl sslcertck password
>>> "MY-SECURE-MAIL-KEY-VALUE" expunge 10 fetchall
>>>
>>     Yep, you bet.  Thanks!  I am not even using the "expunge" verb,
>> and it still seems to work so far.
>
>Just to shed some light on this expunging:

[ All good stuff related to protocol-level DELE/QUIT, EXPUNGE/CLOSE. ]

Since we're talking about it, though, I'll note that in the particular config
above, the 'expunge 10' clause is primarily serving as a throttle for message
delivery to the local MTA. It is a minor abuse of the 'expunge' "end the
session" behavior documented in fetchmail(1) for POP2 and POP3:

        -e <count> | --expunge <count>
               (Keyword: expunge)
               Arrange  for  deletions to be made final after a given number of
               messages.  Under POP2 or POP3, fetchmail cannot  make  deletions
               final  without  sending QUIT and ending the session -- with this
               option on, fetchmail will break a long  mail  retrieval  session
               into multiple sub-sessions, sending QUIT after each sub-session.
               ...

I say "minor abuse" because the feature is documented as a tool to help cope
with flakey connections to the maildrop server, which is not the intent of my
use.

The local MTA happens to be configured to only attempt immediate delivery of
up to ten messages from a given SMTP session (the rest get queued for later
delivery whenever the mail queue delivery runner wakes up to do its
thing). The effect of using the 'expunge 10' clause is that fetchmail will
only hand off ten messages at a time to the local MTA, so all will enjoy
immediate delivery (since fetchmail only attempts delivery within the ten
message limit).  However, a (hypothetical) runaway process on the machine
attempting to send out a gazillion email messages all at once would land (
gazillion minus ten ) messages in the mail queue (hopefully with enough time
for somebody to notice and purge them before attempting delivery either
locally or remote).

-Al

-- 
a l a n   d.   s a l e w s k i
ads@salewski.email
sal...@at...
https://github.com/salewski

Re: [Fetchmail-users] fetchmail expunge error

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

Am 26.04.21 um 14:46 schrieb Leslie Rhorer:
>
> On 4/25/2021 9:15 PM, Alan D. Salewski wrote:
>> Hi Leslie,
>>
>> On 2021-04-25 12:24:06, Leslie Rhorer <les...@si...>
>> spake thus:
>> [...]
>>
>>
>>> I was
>>> also informed the old server (inbound.att.net) is no longer active.
>>
>> I think the person who provided that information was misinformed. The
>> 'inbound.att.net' address is still active -- I am successfully using
>> it with
>> POP3. Also, it is still listed in the AT&T online help articles. E.g.,
>
>     Ha!  That's what I get for believing a corporate tech support
> weenie.  I should have known better.  I made the rather stupid mistake
> of believing him, and made the change without really checking.  Pfft! 
> I went back to the old server (with the new secure mail key, of
> course), and it all seems to be working.
>
>> Yes, the below fetchmail config line is what I use to pull mail from
>> AT&T via
>> POP3, but I am doing it from 'inbound.att.net':
>>
>>     poll inbound.att.net port 995 protocol pop3 timeout 120 uidl
>> username "my-...@at..." ssl sslcertck password
>> "MY-SECURE-MAIL-KEY-VALUE" expunge 10 fetchall
>>
>     Yep, you bet.  Thanks!  I am not even using the "expunge" verb,
> and it still seems to work so far.

Just to shed some light on this expunging:

* POP3 and IMAP separate "mark for deletion" and actual erasing of
deleted messages.

For POP3, it's simplistic, the server must remember all the "DELE 1234"
"DELE 1235" etc. These are only to execute when the client (fetchmail
for instance) sends "QUIT". Some servers are known to malfunction and
also execute stored DELE on loss of connection, which is a violation of
the protocol.

For IMAP4rev.1, the client can set \Deleted flags on mesages, and these
take effect by "EXPUNGE" or "CLOSE" commands. Fetchmail only uses
EXPUNGE, unless you either only check for mail, or set the --keep option.


And WRT a similar issue, also see
<https://sourceforge.net/p/fetchmail/mailman/fetchmail-users/thread/alpine.LFD.2.02.2005041620590.1519%40xippy/#msg37004069>
- not sure how much of that holds today, it's nearly a year old.

Re: [Fetchmail-users] fetchmail 7.0.0.alpha7 oauth authentication failure to outlook.office365.com

[David T. <dav...@wi...>]

Hi Matthias, thanks for the reply. The access token was/is 2411 bytes.  I get the same result with alpha8. (Note: the alpha8 sources still identify themselves as alpha7).

Sincerely,

David

Apr 26 08:22:15 fetchmail: SSL/TLS: using protocol TLSv1.2, cipher ECDHE-RSA-AES256-GCM-SHA384, 256/256 secret/processed bits
Apr 26 08:22:16 fetchmail: POP3< +OK The Microsoft Exchange POP3 service is ready. [QwBIADIAUABSADEANwBDAEEAMAAwADIAOQAuAG4AYQBtAHAAcgBkADEANwAuAHAAcgBvAGQALgBvAHUAdABsAG8AbwBrAC4AYwBvAG0A]
Apr 26 08:22:16 fetchmail: POP3> CAPA
Apr 26 08:22:16 fetchmail: POP3< +OK
Apr 26 08:22:16 fetchmail: POP3< TOP
Apr 26 08:22:16 fetchmail: POP3< UIDL
Apr 26 08:22:16 fetchmail: POP3< SASL PLAIN XOAUTH2
Apr 26 08:22:16 fetchmail: POP3< USER
Apr 26 08:22:16 fetchmail: POP3< .
Apr 26 08:22:16 fetchmail: POP3> AUTH XOAUTH2
Apr 26 08:22:16 fetchmail: POP3< + 
Apr 26 08:22:16 fetchmail: POP3> [SHROUDED]
Apr 26 08:22:16 fetchmail: POP3< -ERR Authentication failure: unknown user name or bad password.
Apr 26 08:22:16 fetchmail: Authentication failure: unknown user name or bad password.
Apr 26 08:22:16 fetchmail: POP3> USER fet...@wi...
Apr 26 08:22:16 fetchmail: POP3< +OK
Apr 26 08:22:16 fetchmail: We've run out of allowed authenticators and cannot continue.
Apr 26 08:22:16 fetchmail: Authorization failure on fet...@wi...@MDW-efz.ms-acdc.office.com
Apr 26 08:22:16 fetchmail: POP3> QUIT
Apr 26 08:22:16 fetchmail: POP3< +OK Microsoft Exchange Server POP3 server signing off.
Apr 26 08:22:16 fetchmail: 7.0.0-alpha7 querying outlook.office365.com (protocol POP3) at Mon 26 Apr 2021 08:22:16 AM CDT: poll completed
Apr 26 08:22:16 fetchmail: Query status=3 (AUTHFAIL)
Apr 26 08:22:16 fetchmail: normal termination, status 3

-----Original Message-----
From: mat...@gm... <mat...@gm...> 
Sent: Sunday, April 25, 2021 4:10 AM
To: fet...@li...
Cc: David Thompson <dav...@wi...>
Subject: Re: [Fetchmail-users] fetchmail 7.0.0.alpha7 oauth authentication failure to outlook.office365.com

Am 12.04.21 um 16:19 schrieb David Thompson via Fetchmail-users:
> I'm trying to get the latest fetchmail alpha to pop mail from Microsoft. I'm using the python O365 module to get an access token, and then using fetchmail's passwordfile option to pop the messages. I can access the email account fine using the O365 python module, but if I extract the access token from the FileSystemTokenBackend file for use with fetchmail, I get an authentication error. I've also verified that the extracted access token is good using Microsoft's tool (https://jwt.ms/). Here are my specifics (per the FAQ G3):
>
> Os: CentOS 7 (CentOS Linux release 7.9.2009 (Core))
> Compiler: gcc-4.8.5-44.el7.x86_64
> Command: fetchmail -v -f fetchmailrc
>
> My fetchmailrc is:
> poll outlook.office365.com proto pop3 auth oauthbearer
>         user 'fet...@wi...' passwordfile '/opt/rt-oauth/fet...@wi...cess' sslmode wrapped
>
> fetchmail -V ... and fetchmail -vvv... outputs are attached.
>
> Any thoughts or suggestions are greatly appreciated.

David, how long is the "password" token?

ls -l /opt/rt-oauth/fet...@wi...cess

I have recently released fetchmail 7.0.0-alpha8 with an increased maximum password length of 10,000 bytes net, but the announcement hasn't made it through to the list yet, for reasons unknown (no bounce received yet), hence I am Cc:ing you (out of the ordinary).

Re: [Fetchmail-users] fetchmail expunge error

[Leslie R. <les...@si...>]

On 4/25/2021 9:15 PM, Alan D. Salewski wrote:
> Hi Leslie,
>
> On 2021-04-25 12:24:06, Leslie Rhorer <les...@si...> 
> spake thus:
> [...]
>
>
>> I was
>> also informed the old server (inbound.att.net) is no longer active.
>
> I think the person who provided that information was misinformed. The
> 'inbound.att.net' address is still active -- I am successfully using 
> it with
> POP3. Also, it is still listed in the AT&T online help articles. E.g.,

     Ha!  That's what I get for believing a corporate tech support 
weenie.  I should have known better.  I made the rather stupid mistake 
of believing him, and made the change without really checking.  Pfft!  I 
went back to the old server (with the new secure mail key, of course), 
and it all seems to be working.

> Yes, the below fetchmail config line is what I use to pull mail from 
> AT&T via
> POP3, but I am doing it from 'inbound.att.net':
>
>     poll inbound.att.net port 995 protocol pop3 timeout 120 uidl 
> username "my-...@at..." ssl sslcertck password 
> "MY-SECURE-MAIL-KEY-VALUE" expunge 10 fetchall
>
     Yep, you bet.  Thanks!  I am not even using the "expunge" verb, and 
it still seems to work so far.

Re: [Fetchmail-users] fetchmail expunge error

[Alan D. S. <sal...@at...>]

Hi Leslie,

On 2021-04-25 12:24:06, Leslie Rhorer <les...@si...> spake thus:
[...]
>I called the ISP (AT&T) and
>they informed me users could no longer access mail from a client using
>their password. Instead, the user has to create a secure keyword.

For other AT&T/Yahoo customers, the specific terminology used by the company
for those new passwords (in case you need to google it) is "secure mail
keys". They seem to have been rolling them out for a while; I needed to make
the change (I think) in fall 2020, but the effort seems to have started at
least as far back as 2019:

   • "Use OAuth or secure mail key for email apps"
     https://www.att.com/support/article/email-support/KM1240462

   • "Create a secure mail key"
     https://www.att.com/support/article/email-support/KM1240308


>I was
>also informed the old server (inbound.att.net) is no longer active.

I think the person who provided that information was misinformed. The
'inbound.att.net' address is still active -- I am successfully using it with
POP3. Also, it is still listed in the AT&T online help articles. E.g.,

   • "Get AT&T email server settings"
     https://www.att.com/support/article/email-support/KM1010523

   • "Set Up or Update AT&T Email - Apple Mail (OS X)"
     https://www.att.com/support/article/email-support/KM1010489

There are relatively frequent availability issues with 'inbound.att.net', but
that is a long-standing problem unrelated to the password changes, AFAICT.


>Instead, users must download from imap.mail.att.net.  The tech claimed
>POP3 downloads would still work, but I was not able to get fetchmail to
>login to the server with the POP3 protocol.  I would be interested to
>know if anyone is still able to login to the new server using the POP3
>protocol.
[...]

Yes, the below fetchmail config line is what I use to pull mail from AT&T via
POP3, but I am doing it from 'inbound.att.net':

     poll inbound.att.net port 995 protocol pop3 timeout 120 uidl username "my-...@at..." ssl sslcertck password "MY-SECURE-MAIL-KEY-VALUE" expunge 10 fetchall

For other AT&T users that have (or had) a working POP3/inbound.att.net
configuration: Note that when switching from legacy passwords to "secure mail
keys", the only value that needed to change was the password. You have to use
their clunky webapp to create the "secure mail key", and then use that
generated value as the password in your fetchmail config.

HTH,
-Al

-- 
a l a n   d.   s a l e w s k i
ads@salewski.email
sal...@at...
https://github.com/salewski

Re: [Fetchmail-users] fetchmail expunge error

[Hans C. <fo...@gm...>]

On Sun, 25 Apr 2021, Gerard E. Seibert wrote:

> On Sun, 25 Apr 2021 12:24:06 -0500, Leslie Rhorer stated:
>
>>     In any case, I can now login using the IMAP protocol, but fetchmail 
>> can only download a single message at a time, producing a mail expunge 
>> mismatch error (0 actual != 1 expected) and exiting after each message. 
>> Eventually, it does manage to get all the messages, but typically only 
>> after a very long time, whenever several messages come in over a short 
>> time frame.  While not quite critical, this is definitely not good.
>>
>> Is anyone else having this issue with AT&T?  How can I fix it?
>
> Both YAHOO and AOL exhibit the same problem. Most MUAs simply ignore the
> problem. Fetchmail has taken a more stringent approach.

Yup... same problem here with YAHOO.  I asked the same question about a 
year ago and Matthias said this is due to a broken server.  See thread 
here:

   https://sourceforge.net/p/fetchmail/mailman/fetchmail-users/thread/alpine.LFD.2.02.2005041620590.1519%40xippy/#msg37003167

Unfortunately, getting someone like YAHOO to fix their server is next to 
impossible.  Calling "support" results in clueless (fictionalized) 
exchanges like the following:

   Me: <DIAL>...<LONG WAIT ON HOLD>

   Support: YAHOO tech support. How can I help?

   Me: It looks like the YAHOO mail server isn't behaving correctly to the IMAP STORE command.

   Support: <PAUSE> Have you tried to reboot Windows?

   Me: I'm not using Windows, I'm using Linux.

   Support: Linux?  I don't know what that is.  We only support Windows.

   Me: It shouldn't matter, the problem is with the mail server.

   Support: <LONG PAUSE> Have you tried to reboot Windows?

   Me: <SIGH> Never Mind.

   Support: Is there anything else I can help you with?

   Me: Nope. Thanks. <CLICK>

To be clear... I don't recall if I actually called YAHOO support last year 
or not.  I may have.  But based on previous calls to support, I suspect 
this was the type of exchange I would have had.  It might be possible to 
eventually get to someone with enough knowledge to at least understand the 
problem, but getting them to fix it would probably be a different story.

Actually, I wonder if it might be the case that YAHOO (et al) is unwilling 
to fix their servers because so many (major) MUAs depend on the current 
broken behavior.  I have no idea if that's the true or not, just 
speculating.

Re: [Fetchmail-users] fetchmail expunge error

[Leslie R. <les...@si...>]

On 4/25/2021 2:43 PM, Gerard E. Seibert wrote:
> On Sun, 25 Apr 2021 12:24:06 -0500, Leslie Rhorer stated:
>>      In any case, I can now login using the IMAP protocol, but
>> fetchmail
>> can only download a single message at a time, producing a mail expunge
>> mismatch error (0 actual != 1 expected) and exiting after each
>> message. Eventually, it does manage to get all the messages, but
>> typically only after a very long time, whenever several messages come
>> in over a short time frame.  While not quite critical, this is
>> definitely not good.
>>
>> Is anyone else having this issue with AT&T?  How can I fix it?
> Both YAHOO and AOL exhibit the same problem. Most MUAs simply ignore the
> problem. Fetchmail has taken a more stringent approach.

     Yahoo and AT&T are one and the same, and apparently have been for 
quite a while.  Both the old and the new DNS entries redirect to 
addresses on yahoo.com.   The question is, "How do I get fetchmail to 
ignore or work around the issue?"  Regardless of how obtuse the ISP's 
IMAP server may be, I should be able to download messages without any 
issue.  Downloading one message every N seconds is not an answer.

     I am also getting errors like:

fetchmail: Received BYE response from IMAP server:  IMAP4REV1 SERVER 
LOGGING OUTfetchmail: mailbox selection failed
fetchmail: client/server synchronization error while fetching from 
yy...@at...@imap.mail.att.net
fetchmail: Query status=7 (ERROR)