fetchmail-users — User questions and discussion

Re: [Fetchmail-users] IDLE Socket error After IP reconnect

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

Am 01.11.25 um 23:42 schrieb Mailu via Fetchmail-users:
> Oh sorry, trying to do my best on the go with iOS mail :/
> Hope this is better even though not quoting this time anyways...
>   
> I just wanted to ask if the reason can really be the server employing short timeouts.
> Timeouts seem rather reasonable: I noticed that *exactly* every 200mins I receive the socket error (except for the additional errors in the time slots around the IP reconnect).

Hum. 200 min without receiving mail? Can you get me debug logs? See the 
fetchmail FAQ, <https://www.fetchmail.info/fetchmail-FAQ.html#G3>

> I would still say that this is expected as eventually every server will disconnect on their side. Or do you mean that fetchmail should actively reconnect every 30mins by default? If so, this seems not to work for me...

It's certainly so that fetchmail has had support for a long time to deal 
with servers disconnecting anytime - that's just a nearly normal 
situation in networks.

Re: [Fetchmail-users] IDLE Socket error After IP reconnect

[Mailu <lol...@we...>]

Oh sorry, trying to do my best on the go with iOS mail :/
Hope this is better even though not quoting this time anyways...
 
I just wanted to ask if the reason can really be the server employing short timeouts.
Timeouts seem rather reasonable: I noticed that *exactly* every 200mins I receive the socket error (except for the additional errors in the time slots around the IP reconnect).
I would still say that this is expected as eventually every server will disconnect on their side. Or do you mean that fetchmail should actively reconnect every 30mins by default? If so, this seems not to work for me...

> Am 01.11.2025 um 13:14 schrieb Matthias Andree via Fetchmail-users <fet...@li...>:
> 
> Your quoting is extremely broken. Please use a *WORKING* mailer to quote properly and mark quotes.
> 
> Being "professional" (aka paid for what they do) does not mean "free of surprises" or "violations of standards".
> 
> 
>> Am 01.11.25 um 13:04 schrieb Mailu via Fetchmail-users:
>> This would be a server employing short timeouts... you can work around that with idletimeout 280 or similar (in rcfile or command line argument) on supported versions of fetchmail. Check after what time the server gives you a TIMEOUT and then set idletimeout several seconds short of that.
>> 
>> Oh really? Shouldn‘t I receive this Message more often then and Not only 1-2x a times a day?
>> 
>>> Yes, assuming the server is compliant and does _not_ try to be extra smart and delete the message after the first attempt to read it.
>> I Hope it is not. I am Talking about Web.de. A large German mail provider. Basically the Same as GMX. Should be professional, but you never know in the Details…
>> 
>>> The elegant ways are 1. don't use IDLE if the server employs nonconforming timeouts, 2. get a static IP.
>>> 
>>> The practical way is "ignore and move on".
>> Thanks for confirming!
>> 
>> 
>> _______________________________________________
>> Fetchmail-users mailing list
>> Fet...@li...
>> https://lists.sourceforge.net/lists/listinfo/fetchmail-users
> 
> 
> 
> 
> _______________________________________________
> Fetchmail-users mailing list
> Fet...@li...
> https://lists.sourceforge.net/lists/listinfo/fetchmail-users

Re: [Fetchmail-users] IDLE Socket error After IP reconnect

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

Your quoting is extremely broken. Please use a *WORKING* mailer to quote 
properly and mark quotes.

Being "professional" (aka paid for what they do) does not mean "free of 
surprises" or "violations of standards".


Am 01.11.25 um 13:04 schrieb Mailu via Fetchmail-users:
> This would be a server employing short timeouts... you can work around that with idletimeout 280 or similar (in rcfile or command line argument) on supported versions of fetchmail. Check after what time the server gives you a TIMEOUT and then set idletimeout several seconds short of that.
>
> Oh really? Shouldn‘t I receive this Message more often then and Not only 1-2x a times a day?
>
>> Yes, assuming the server is compliant and does _not_ try to be extra smart and delete the message after the first attempt to read it.
> I Hope it is not. I am Talking about Web.de. A large German mail provider. Basically the Same as GMX. Should be professional, but you never know in the Details…
>
>> The elegant ways are 1. don't use IDLE if the server employs nonconforming timeouts, 2. get a static IP.
>>
>> The practical way is "ignore and move on".
> Thanks for confirming!
>
>
> _______________________________________________
> Fetchmail-users mailing list
> Fet...@li...
> https://lists.sourceforge.net/lists/listinfo/fetchmail-users

Re: [Fetchmail-users] IDLE Socket error After IP reconnect

[Mailu <lol...@we...>]

This would be a server employing short timeouts... you can work around that with idletimeout 280 or similar (in rcfile or command line argument) on supported versions of fetchmail. Check after what time the server gives you a TIMEOUT and then set idletimeout several seconds short of that.

Oh really? Shouldn‘t I receive this Message more often then and Not only 1-2x a times a day?

> Yes, assuming the server is compliant and does _not_ try to be extra smart and delete the message after the first attempt to read it.

I Hope it is not. I am Talking about Web.de. A large German mail provider. Basically the Same as GMX. Should be professional, but you never know in the Details…

> The elegant ways are 1. don't use IDLE if the server employs nonconforming timeouts, 2. get a static IP.
> 
> The practical way is "ignore and move on".

Thanks for confirming!

Re: [Fetchmail-users] IDLE Socket error After IP reconnect

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

Am 01.11.25 um 11:44 schrieb LolliPOPsystem--- via Fetchmail-users:
> Hi,
>
> New User here.
>
> Setup: Running a Python script starting one instance for each of multiple mail accounts in IDLE mode leveraging individual $FETCHMAILHOME environment variables like this:
> https://www.linuxquestions.org/questions/linux-software-2/correct-fetchmail-with-idle-and-multiple-servers-config-642089/
>
> Fetchmail runs behind a router with Dynamic IP.
>
> Occationally (and particularly After IP resets), I receive the following error for each instance and the script restarts the fetchmail instances:
>
> Nov 01 08:48:54 fetchmail: Received BYE response from IMAP server:  TIMEOUT

This would be a server employing short timeouts... you can work around 
that with idletimeout 280 or similar (in rcfile or command line 
argument) on supported versions of fetchmail. Check after what time the 
server gives you a TIMEOUT and then set idletimeout several seconds 
short of that.

> Nov 01 08:48:54 fetchmail: re-poll failed
> Nov 01 08:48:54 fetchmail: socket error while fetching from…
>
> I assume this is due to the IP change and the connection cannot be re-established. I think this will Not harm fetchmail’s functionality and I can safely restart it without fearing any mail will be lost or not fetched.

Yes, assuming the server is compliant and does _not_ try to be extra 
smart and delete the message after the first attempt to read it.

Worst case if the IP changes in the middle of a transfer you might end 
up with two copies of a message, one complete and one incomplete.

> Can you confirm this understanding and maybe explain better what is Happening and what an elegant way is to mitigate?

The elegant ways are 1. don't use IDLE if the server employs 
nonconforming timeouts, 2. get a static IP.

The practical way is "ignore and move on".

[Fetchmail-users] IDLE Socket error After IP reconnect

[<Lol...@we...>]

Hi,

New User here.

Setup: Running a Python script starting one instance for each of multiple mail accounts in IDLE mode leveraging individual $FETCHMAILHOME environment variables like this:
https://www.linuxquestions.org/questions/linux-software-2/correct-fetchmail-with-idle-and-multiple-servers-config-642089/

Fetchmail runs behind a router with Dynamic IP.

Occationally (and particularly After IP resets), I receive the following error for each instance and the script restarts the fetchmail instances:

Nov 01 08:48:54 fetchmail: Received BYE response from IMAP server:  TIMEOUT
Nov 01 08:48:54 fetchmail: re-poll failed
Nov 01 08:48:54 fetchmail: socket error while fetching from…

I assume this is due to the IP change and the connection cannot be re-established. I think this will Not harm fetchmail’s functionality and I can safely restart it without fearing any mail will be lost or not fetched.

Can you confirm this understanding and maybe explain better what is Happening and what an elegant way is to mitigate?

Thanks!

[Fetchmail-users] The 6.6.0 release of fetchmail is available (TLS support for SMTP, incl. STARTTLS)

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

The 6.6.0 release of fetchmail is now available at the usual locations,
including <https://downloads.sourceforge.net/project/fetchmail/branch_6.6/>
and <https://gitlab.com/fetchmail/fetchmail/-/releases#6.6.0>


Distributors: please install the revived Italian translation!
=============


The source archive is available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.6/fetchmail-6.6.0.tar.xz/download>
<https://gitlab.com/-/project/188557/uploads/390ec2599b4f1f47bb18f37b7e5b601b/fetchmail-6.6.0.tar.xz>

The detached GnuPG signature is attached and available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.6/fetchmail-6.6.0.tar.xz.asc/download>
<https://gitlab.com/-/project/188557/uploads/5ef2d3ea82be1133e3630ad0d7e789dc/fetchmail-6.6.0.tar.xz.asc>

The SHA256 hashes for the tarballs are:
SHA2-256(fetchmail-6.6.0.tar.xz)= 7b9c19e6683e827d556751aa5db5d44b961e87be8b3087535b4909ba1b59321c


NOTE that fetchmail-6.5.X will go out of support at the end of 2025.

The 6.6.0 release does not intentionally change configuration files,
command line arguments, or behavior, and should therefore be a drop-in
compatible replacement for 6.5.X releases.


Here are the release notes:
--------------------------------------------------------------------------------
fetchmail-6.6.0 (released 2025-10-27, 32381 LoC):

## FEATURE:
* SMTP TLS and STARTTLS support. By default, this works opportunistically,
  attempting to set up a TLS connection to the smtphost if it understands EHLO
  and offers STARTTLS, but will not enforce peer certificate validity for
  compatibility, esp. because "localhost" (the default SMTP host) usually
  isn't listed in the X.509 certificates.
    Behavior can be tweaked by adding /notls (cleartext connection), /tls
  (TLS-wrapped connection, negotiating TLS before conversing otherwise),
  or /starttls (requiring EHLO to offer STARTTLS, requesting the latter and
  requiring the server certificate to validate) to the SMTP host's name.
    Also, you can add /tlsproto=... where ... accepts the same parameters
  as the --sslproto option, which see.
  Ports, if not specified, default to 25 for opportunistic and /notls modes,
  465 for /tls and 587 for /starttls, but can be overridden either by giving,
  say /25 or /smtp for /starttls.

## TRANSLATIONS were updated by these fine people (randomized order):
* it:    Luca Vercelli [Italian]
* pl:    Jakub Bogusz [Polish]
* fr:    Frédéric Marchal [French]
* sv:    Göran Uddeborg [Swedish]
* sq:    Besnik Bleta [Albanian]
* ro:    Remus-Gabriel Chelu [Romanian]
* ja:    Takeshi Hamasaki [Japanese]
* de:    Matthias Andree [German]
* cs:    Petr Pisar [Czech]
* eo:    Keith Bowes [Esperanto]

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

Re: [Fetchmail-users] Migrating from 6.3.24 to 6.4.38

[Dennis P. <da...@be...>]

On 10/26/2025 2:50 PM, Andrew C Aitchison wrote:
> On Sun, 26 Oct 2025, Dennis Putnam via Fetchmail-users wrote:
>
>> I have fetchmail (6.3.24) running on CentOS 7 and am moving it to 
>> Ubuntu fetchmail (6.4.38). I thought the move would be pretty much 
>> seamless but was wrong. Apparently there are differences in the 
>> fetchmailrc file that I am not understanding. I am using it for 
>> gmail. Here is a sanitized portion of my fetchmailrc:
>>
>> *set logfile "/var/log/maillog"
>> set postmaster "mailman"
>> set bouncemail
>> set no spambounce
>> set properties ""
>> defaults:
>>         timeout 240
>> poll pop.gmail.com
>>         proto POP3
>>         user "uuu...@gm..."
>>         is uuuuuuuuu
>>         password 'kkkkkkkkkkkkkkkr'
>>         preconnect "echo `date '+%b %d %H:%M:%S'` uuuuuuuuu"
>>         ssl
>>         nokeep
>>         fetchall
>
>> Trying to connect to 127.0.0.1/25...connected.
>>
>> *At this point it seems to hang and does not proceed to the next 
>> mailbox.
>> Can someone help me fix my fetchmailrc? TIA.
>
> I think (but am not sure) that the problem may be with your local mail
> server (MTA - probably postfix or exim) rather than fetchmail.
> I would look in the logs for that.
>
Hi Andrew,

You were exactly right. I never would have made that connection myself. 
Thanks.

Re: [Fetchmail-users] Migrating from 6.3.24 to 6.4.38

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

On Sun, 26 Oct 2025, Dennis Putnam via Fetchmail-users wrote:

> I have fetchmail (6.3.24) running on CentOS 7 and am moving it to Ubuntu 
> fetchmail (6.4.38). I thought the move would be pretty much seamless but was 
> wrong. Apparently there are differences in the fetchmailrc file that I am not 
> understanding. I am using it for gmail. Here is a sanitized portion of my 
> fetchmailrc:
>
> *set logfile "/var/log/maillog"
> set postmaster "mailman"
> set bouncemail
> set no spambounce
> set properties ""
> defaults:
>         timeout 240
> poll pop.gmail.com
>         proto POP3
>         user "uuu...@gm..."
>         is uuuuuuuuu
>         password 'kkkkkkkkkkkkkkkr'
>         preconnect "echo `date '+%b %d %H:%M:%S'` uuuuuuuuu"
>         ssl
>         nokeep
>         fetchall

> Trying to connect to 127.0.0.1/25...connected.
>
> *At this point it seems to hang and does not proceed to the next mailbox.
> Can someone help me fix my fetchmailrc? TIA.

I think (but am not sure) that the problem may be with your local mail
server (MTA - probably postfix or exim) rather than fetchmail.
I would look in the logs for that.

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

[Fetchmail-users] Migrating from 6.3.24 to 6.4.38

[Dennis P. <da...@be...>]

I have fetchmail (6.3.24) running on CentOS 7 and am moving it to Ubuntu 
fetchmail (6.4.38). I thought the move would be pretty much seamless but 
was wrong. Apparently there are differences in the fetchmailrc file that 
I am not understanding. I am using it for gmail. Here is a sanitized 
portion of my fetchmailrc:

*set logfile "/var/log/maillog"
set postmaster "mailman"
set bouncemail
set no spambounce
set properties ""
defaults:
         timeout 240
poll pop.gmail.com
         proto POP3
         user "uuu...@gm..."
         is uuuuuuuuu
         password 'kkkkkkkkkkkkkkkr'
         preconnect "echo `date '+%b %d %H:%M:%S'` uuuuuuuuu"
         ssl
         nokeep
         fetchall

*Here is the output when I run it:

*Old UID list from pop.gmail.com:
  <empty>

Scratch list of UIDs:
  <empty>

fetchmail: 6.4.38 querying pop.gmail.com (protocol POP3) at Sun 26 Oct 
2025 01:00:02 PM EDT: poll started
Oct 26 13:00:02 uuuuuuuu
Trying to connect to 2607:f8b0:4002:c05::6c/995...connected.
fetchmail: SSL verify callback depth 2: verify_ok == 1, err = 0, ok
fetchmail: Certificate chain, from root to peer, starting at depth 2:
fetchmail: Issuer Organization: Google Trust Services LLC
fetchmail: Issuer CommonName: GTS Root R4
fetchmail: Subject CommonName: GTS Root R4
fetchmail: SSL verify callback depth 1: verify_ok == 1, err = 0, ok
fetchmail: Certificate at depth 1:
fetchmail: Issuer Organization: Google Trust Services LLC
fetchmail: Issuer CommonName: GTS Root R4
fetchmail: Subject CommonName: WE2
fetchmail: SSL verify callback depth 0: verify_ok == 1, err = 0, ok
fetchmail: Server certificate:
fetchmail: Issuer Organization: Google Trust Services
fetchmail: Issuer CommonName: WE2
fetchmail: Subject CommonName: pop.gmail.com
fetchmail: Subject Alternative Name: pop.gmail.com
fetchmail: pop.gmail.com key fingerprint: 
A3:FD:1E:8B:34:9B:B3:89:BF:E9:67:5B:42:DE:4E:8A
fetchmail: SSL/TLS: using protocol TLSv1.3, cipher 
TLS_AES_256_GCM_SHA384, 256/256 secret/processed bits
fetchmail: POP3< +OK Gpop ready for requests from 
2600:1700:5cac:4600:431:e582:3ec6:f485 956f58d0204a3-63e8b2c032
amb144186743d50
fetchmail: POP3> CAPA
fetchmail: POP3< +OK Capability list follows
fetchmail: POP3< USER
fetchmail: POP3< RESP-CODES
fetchmail: POP3< EXPIRE 0
fetchmail: POP3< LOGIN-DELAY 300
fetchmail: POP3< TOP
fetchmail: POP3< UIDL
fetchmail: POP3< X-GOOGLE-RICO
fetchmail: POP3< SASL PLAIN XOAUTH2 OAUTHBEARER
fetchmail: POP3< .
fetchmail: POP3> USER **uuuuuuuu**@gmail.com
fetchmail: POP3< +OK send PASS
fetchmail: POP3> PASS *
fetchmail: POP3< +OK Welcome.
fetchmail: selecting or re-polling default folder
fetchmail: POP3> STAT
fetchmail: POP3< +OK 3 22429
3 messages for **uuuuuuuu**@gmail.com at pop.gmail.com (22429 octets).
fetchmail: POP3> LIST 1
fetchmail: POP3< +OK 1 7418
fetchmail: POP3> RETR 1
fetchmail: POP3< +OK message follows
reading message **uuuuuuuu**@gma...@po...:1 of 3 (7418 
octets) About to rewrite Return-Path: <xx...@dd...>...
...rewritten version is Return-Path: <**xx...@dd...**>.
About to rewrite Cc: **xx...@dd...**...
...rewritten version is Cc: **xx...@dd...**.
About to rewrite To: **uuuuuuuu**@gmail.com...
...rewritten version is To: **uuuuuuuu**@gmail.com.
About to rewrite From: **xx...@dd...**...
...rewritten version is From: **xx...@dd...**.net.

Trying to connect to 127.0.0.1/25...connected.

*At this point it seems to hang and does not proceed to the next 
mailbox. Can someone help me fix my fetchmailrc? TIA.

Re: [Fetchmail-users] Upgrade to fetchmail 6.5.6

[<t_...@ti...>]

On Tue, 21 Oct 2025 19:48:39 +0200
Matthias Andree via Fetchmail-users
<fet...@li...> wrote:


> Angelo,
> 
> you can either put --syslog on your fetchmail command lines in the 
> fetchmail.service unit files, or you can add
> 
>     set syslog
> 
> early (before skip and poll lines) to your various .fetchmailrc files.
> In that case, fetchmail will send directly to syslog without
> timestamps, and on systemd-based systems, syslog also usually ends up
> where journalctl looks.
> 
> HTH
> 
> Best regards,
> Matthias

OK Matthias,

I'll use --syslog on the command lines

Thanks you all for taking the time to answer my question.

Ciao,
Angelo 

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

Re: [Fetchmail-users] Upgrade to fetchmail 6.5.6

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

Am 21.10.25 um 12:45 schrieb Andrew C Aitchison:
>
> On Mon, 20 Oct 2025, t_...@ti... wrote:
>
>> I've read the FAQ and I have to say that my fetchmail works very fine.
>> I only wonder why it includes timestamps in logs since the last
>> upgrade.
>
> Probably related to this * 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.
> from /home/src/ubuntu/fetchmail/fetchmail-6.5.0/NEWS
>
> I think it is for the benefit of IMAP IDLE.
> In that mode fetchmail keeps an open connection to the server
> and logs whenever the server offers/pushes a new messages.
>
> IMAP IDLE saves fetchmail from starting a new connection (including 
> setting up encryption) every few minutes and allows it to be completely
> idle until there is a new message.
> It doesn't support more than one remote mailbox
> (unless you set up separate fetchmail processes with separate configs).
>
I've received relevant parts of Angelo's configuration directly, and 
part of the .service file is this section:

> [Service]
> Type=oneshot
> StandardOutput=journal
> StandardError=journal
> SyslogIdentifier=fetchmail
> SyslogFacility=mail
> SyslogLevel=warning

According to the .fetchmailrc file, Angelo does not use a logfile, so 
Holger's contribution does not apply;
instead, fetchmail logs to stdout/stderr, adds a timestamp as it would 
when logging to console
-- and systemd captures the output and adds its own timestamp for the 
journal.

Angelo,

you can either put --syslog on your fetchmail command lines in the 
fetchmail.service unit files, or you can add

    set syslog

early (before skip and poll lines) to your various .fetchmailrc files.
In that case, fetchmail will send directly to syslog without timestamps, 
and on systemd-based systems, syslog also usually ends up where 
journalctl looks.

HTH

Best regards,
Matthias

Re: [Fetchmail-users] Upgrade to fetchmail 6.5.6

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

On Mon, 20 Oct 2025, t_...@ti... wrote:

> I've read the FAQ and I have to say that my fetchmail works very fine.
> I only wonder why it includes timestamps in logs since the last
> upgrade.

Probably related to this * 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.
from /home/src/ubuntu/fetchmail/fetchmail-6.5.0/NEWS

I think it is for the benefit of IMAP IDLE.
In that mode fetchmail keeps an open connection to the server
and logs whenever the server offers/pushes a new messages.

IMAP IDLE saves fetchmail from starting a new connection (including 
setting up encryption) every few minutes and allows it to be completely
idle until there is a new message.
It doesn't support more than one remote mailbox
(unless you set up separate fetchmail processes with separate configs).

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

Re: [Fetchmail-users] Upgrade to fetchmail 6.5.6

[<t_...@ti...>]

On Mon, 20 Oct 2025 20:16:34 +0200
Matthias Andree via Fetchmail-users
<fet...@li...> wrote:

> Am 18.10.25 um 22:51 schrieb t_...@ti...:
> > On Sat, 18 Oct 2025 15:01:08 -0500
> > axreios <rp...@am...> wrote:
> >
> >> On Sat, Oct 18, 2025 at 07:36:52PM +0200, t_...@ti... wrote:
> >>> Hi list,
> >>> after upgrading to 6.5.6 I've noticed that syslog messages include
> >>> the timestamp. Since I'm starting fetchmail thru systemd, the
> >>> timestamp is already included in journal. Is it possible to remove
> >>> timestamp from syslog message ?
> >>>
> >>> Here is my uname -a :
> >>>
> >>> Linux agmob3 6.16.12-100.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Sun
> >>> Oct 12 18:44:08 UTC 2025 x86_64 GNU/Linux
> >>>
> >>> Thanks in advance for any answer.
> >>> Ciao
> >>> Angelo
> >>>
> >> Are you getting the timestamp listed twice?  I am not seeing that,
> >> though I am not using systemd.  I do start fetchmail from the
> >> command line with the --syslog option.  FWIW.
> >> 	ax
> >>
> >>
> > Hi,
> > thanks for your answer.
> > here is an example of messages from my journalctl
> >
> > Oct 18 15:03:14 fetchmail[1601465]: Oct 18 15:03:14 fetchmail: 77
> > messages (77 seen) for ...... Oct 18 15:03:14 fetchmail[1601465]:
> > Oct 18 15:03:14 fetchmail: 43 messages (43 seen) for ...... Oct 18
> > 15:03:15 fetchmail[1601825]: Oct 18 15:03:15 fetchmail: No mail for
> > ...... Oct 18 15:03:15 fetchmail[1601825]: Oct 18 15:03:15
> > fetchmail: No mail for ......
> >
> > with previous fetchmail version (6.4) this was not happening.
> 
> 
> Please heed <https://www.fetchmail.info/fetchmail-FAQ.html#G3>
> 
> and please include information on how your systemd file looks like.
> 
> 

Thanks for answering.

I've read the FAQ and I have to say that my fetchmail works very fine.
I only wonder why it includes timestamps in logs since the last
upgrade.


here is my systemd service (triggered by timer)
=======================================================
[Unit]
Description=Fetch My Mails  
Documentation=man:fetchmail(1)
ConditionPathExists=/tmp/XISON

[Service]
Type=oneshot
StandardOutput=journal
StandardError=journal
SyslogIdentifier=fetchmail
SyslogFacility=mail
SyslogLevel=warning

### check for full internet connection
ExecStartPre=/Scripts/ck_full_conn

### fetch mails 
ExecStart=fetchmail -f /home/.MYFMRC
SuccessExitStatus=1

### fetch spam
ExecStart=fetchmail -f /home/.MYFMRC_SPAM
SuccessExitStatus=1

Restart=on-failure
RestartSec=90
=======================================================


On the config files I use the follwing options :
=======================================================
set invisible
set no bouncemail
defaults proto imap timeout 20 bad-header accept
=======================================================

Should I provide any other info ?

Thanks again.
Regards
Angelo


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

Re: [Fetchmail-users] Upgrade to fetchmail 6.5.6

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

Am 18.10.25 um 22:51 schrieb t_...@ti...:
> On Sat, 18 Oct 2025 15:01:08 -0500
> axreios <rp...@am...> wrote:
>
>> On Sat, Oct 18, 2025 at 07:36:52PM +0200, t_...@ti... wrote:
>>> Hi list,
>>> after upgrading to 6.5.6 I've noticed that syslog messages include
>>> the timestamp. Since I'm starting fetchmail thru systemd, the
>>> timestamp is already included in journal. Is it possible to remove
>>> timestamp from syslog message ?
>>>
>>> Here is my uname -a :
>>>
>>> Linux agmob3 6.16.12-100.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Sun Oct
>>> 12 18:44:08 UTC 2025 x86_64 GNU/Linux
>>>
>>> Thanks in advance for any answer.
>>> Ciao
>>> Angelo
>>>
>> Are you getting the timestamp listed twice?  I am not seeing that,
>> though I am not using systemd.  I do start fetchmail from the command
>> line with the --syslog option.  FWIW.
>> 	ax
>>
>>
> Hi,
> thanks for your answer.
> here is an example of messages from my journalctl
>
> Oct 18 15:03:14 fetchmail[1601465]: Oct 18 15:03:14 fetchmail: 77 messages (77 seen) for ......
> Oct 18 15:03:14 fetchmail[1601465]: Oct 18 15:03:14 fetchmail: 43 messages (43 seen) for ......
> Oct 18 15:03:15 fetchmail[1601825]: Oct 18 15:03:15 fetchmail: No mail for ......
> Oct 18 15:03:15 fetchmail[1601825]: Oct 18 15:03:15 fetchmail: No mail for ......
>
> with previous fetchmail version (6.4) this was not happening.


Please heed <https://www.fetchmail.info/fetchmail-FAQ.html#G3>

and please include information on how your systemd file looks like.

Re: [Fetchmail-users] Upgrade to fetchmail 6.5.6

[<t_...@ti...>]

On Sat, 18 Oct 2025 15:01:08 -0500
axreios <rp...@am...> wrote:

> On Sat, Oct 18, 2025 at 07:36:52PM +0200, t_...@ti... wrote:
> >Hi list,
> >after upgrading to 6.5.6 I've noticed that syslog messages include
> >the timestamp. Since I'm starting fetchmail thru systemd, the
> >timestamp is already included in journal. Is it possible to remove
> >timestamp from syslog message ?
> >
> >Here is my uname -a :
> >
> >Linux agmob3 6.16.12-100.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Sun Oct
> >12 18:44:08 UTC 2025 x86_64 GNU/Linux
> >
> >Thanks in advance for any answer.
> >Ciao
> >Angelo
> >
> 
> Are you getting the timestamp listed twice?  I am not seeing that,
> though I am not using systemd.  I do start fetchmail from the command
> line with the --syslog option.  FWIW.
> 	ax
> 
>

Hi,
thanks for your answer.
here is an example of messages from my journalctl

Oct 18 15:03:14 fetchmail[1601465]: Oct 18 15:03:14 fetchmail: 77 messages (77 seen) for ......
Oct 18 15:03:14 fetchmail[1601465]: Oct 18 15:03:14 fetchmail: 43 messages (43 seen) for ......
Oct 18 15:03:15 fetchmail[1601825]: Oct 18 15:03:15 fetchmail: No mail for ......
Oct 18 15:03:15 fetchmail[1601825]: Oct 18 15:03:15 fetchmail: No mail for ......

with previous fetchmail version (6.4) this was not happening.

Thanks again.
Ciao,

Angelo

Re: [Fetchmail-users] Upgrade to fetchmail 6.5.6

[axreios <rp...@am...>]

On Sat, Oct 18, 2025 at 07:36:52PM +0200, t_...@ti... wrote:
>Hi list,
>after upgrading to 6.5.6 I've noticed that syslog messages include the timestamp.
>Since I'm starting fetchmail thru systemd, the timestamp is already included in journal.
>Is it possible to remove timestamp from syslog message ?
>
>Here is my uname -a :
>
>Linux agmob3 6.16.12-100.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Sun Oct 12 18:44:08 UTC 2025 x86_64 GNU/Linux
>
>Thanks in advance for any answer.
>Ciao
>Angelo
>

Are you getting the timestamp listed twice?  I am not seeing that,
though I am not using systemd.  I do start fetchmail from the command
line with the --syslog option.  FWIW.
	ax

[Fetchmail-users] Upgrade to fetchmail 6.5.6

[<t_...@ti...>]

Hi list,
after upgrading to 6.5.6 I've noticed that syslog messages include the timestamp.
Since I'm starting fetchmail thru systemd, the timestamp is already included in journal.
Is it possible to remove timestamp from syslog message ?

Here is my uname -a :

Linux agmob3 6.16.12-100.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Sun Oct 12 18:44:08 UTC 2025 x86_64 GNU/Linux

Thanks in advance for any answer.
Ciao
Angelo

[Fetchmail-users] ANNOUNCE: The 6.5.7 release of fetchmail is available (new Italian translation, SMTP AUTH fixes/.netrc support)

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

The 6.5.7 release of fetchmail is now available at the usual locations,
including <https://downloads.sourceforge.net/project/fetchmail/branch_6.5/>
and <https://gitlab.com/fetchmail/fetchmail/-/releases/6.5.7>


Distributors: please install the revived Italian translation!
=============


The source archive is available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.7.tar.xz/download>
<https://gitlab.com/-/project/188557/uploads/a152d9fb1d4384e5fda24411b4eea87c/fetchmail-6.5.7.tar.xz>

The detached GnuPG signature is available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.7.tar.xz.asc/download>
<https://gitlab.com/-/project/188557/uploads/b659d45e268a7142833a6eefc0c5aa4d/fetchmail-6.5.7.tar.xz.asc>

The SHA256 hashes for the tarballs are:
SHA2-256(fetchmail-6.5.7.tar.xz)= 73eb6b1d421b5986866ad4a6b777c1140a39005298c63bf847de537976cbfbdb


Here are the release notes:
--------------------------------------------------------------------------------
fetchmail-6.5.7 (released 2025-10-18, 32215 LoC):

## BUGFIXES:
* When authenticating to an SMTP server, the AUTH LOGIN method (which didn't
  become a proposed standard, and is only the third method fetchmail would try,
  if CRAM-MD5 and PLAIN weren't offered) required that the server returned
  a 334 code followed by a blank and by a decodable base64 challenge we ignored
  anyways.  This is in line with RFC 4952.
    However, to improve compatibility, fetchmail now accepts anything that
  starts with "334 " and disregards the remainder of the line.
  At the same time, AUTH LOGIN was deprecated. AUTH PLAIN should be available
  everywhere AUTH LOGIN is, and is specified in IETF RFC 4616.
* When authenticating to an SMTP server, i. e. esmtpname/esmtppassword are
  defined, check for errors, and skip servers that do not understand EHLO,
  because we cannot negotiate supported authentication schemes with them.
  This should avoid attempting to send a lot of messages and see them rejected.
* When authenticating to an SMTP server, do not send client abort "*" when
  we receive any other server reply but 334.
* Extend 6.5.6's RFC-5321 address-literal fix to MAIL FROM. This might
  apply when we only have a server's IP address and need to quality
  addresses without domain. Fixes Debian Bug#1080025.
* SMTP AUTH can now look up passwords from the .netrc file - for that,
  fetchmail's esmtpname setting must match the login for the given host in
  .netrc. Fixes Debian Bug#1056651 by Ticker Berkin.
* Improve the GSSAPI (Kerberos V) build, which was pretty hard to get working.
  This was improved. Recommendation:
  - For autoconf builds (./configure), be sure to have the desired krb5-config
  executable early on $PATH before running ./configure.
  - For meson builds, be sure to list the path to your krb5-gssapi.pc file on
  PKG_CONFIG_PATH.  (meson will fall back to krb5-config, so if that's on PATH,
  that should also work.)

## TRANSLATION UPDATES were contributed by these fine people - thank you!
* The Italian translation is back - it had been missing from earlier 6.5.X
  since it had fallen too far behind with the last update in 2010.
* cs:    Petr Pisar [Czech]
* eo:    Keith Bowes [Esperanto]
* es:    Cristian Othón Martínez Vera [Spanish]
* fr:    Frédéric Marchal [French]
* it:    Luca Vercelli [Italian]
* ja:    Takeshi Hamasaki [Japanese]
* pl:    Jakub Bogusz [Polish]
* ro:    Remus-Gabriel Chelu [Romanian]
* sq:    Besnik Bleta [Albanian]
* sv:    Göran Uddeborg [Swedish]

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

[Fetchmail-users] ANNOUNCE: The 6.5.7.rc3 release candiate of fetchmail is available (new Italian translation, SMTP AUTH fixes/.netrc support)

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

The 6.5.7.rc3 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.7.rc3.tar.xz/download>

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

The SHA256 hashes for the tarballs are:
SHA2-256(fetchmail-6.5.7.rc3.tar.xz)= 73ca795b69980bb61ee9c64b4bdb88b1839a72f51ba087dcefe31c7892c5a2a8

Changes since rc2:

* 9a73ab16 2025-10-14 | Bump version to 6.5.7.rc3. (tag: 6.5.7.rc3) [Matthias Andree]
* e790d834 2025-10-14 | Re-enable Italian translation, thanks to Luca Vercelli.  [Matthias Andree]
* 1cb17f9e 2025-10-10 | Update <it> Italian translation to fetchmail 6.5.6 [Luca Vercelli]
* 5bbc044e 2025-10-14 | GSSAPI: improve GSSAPI build experience [Matthias Andree]
* 7042e30f 2025-10-14 | OpenBSD: work around htmldoc bug [Matthias Andree]



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

## BUGFIXES:
* When authenticating to an SMTP server, the AUTH LOGIN method (which didn't
  become a proposed standard, and is only the third method fetchmail would try,
  if CRAM-MD5 and PLAIN weren't offered) required that the server returned
  a 334 code followed by a blank and by a decodable base64 challenge we ignored
  anyways.  This is in line with RFC 4952.
    However, to improve compatibility, fetchmail now accepts anything that
  starts with "334 " and disregards the remainder of the line.
  At the same time, AUTH LOGIN was deprecated. AUTH PLAIN should be available
  everywhere AUTH LOGIN is, and is specified in IETF RFC 4616.
* When authenticating to an SMTP server, i. e. esmtpname/esmtppassword are
  defined, check for errors, and skip servers that do not understand EHLO,
  because we cannot negotiate supported authentication schemes with them.
  This should avoid attempting to send a lot of messages and see them rejected.
* When authenticating to an SMTP server, do not send client abort "*" when
  we receive any other server reply but 334.
* Extend 6.5.6's RFC-5321 address-literal fix to MAIL FROM. This might
  apply when we only have a server's IP address and need to quality
  addresses without domain. Fixes Debian Bug#1080025.
* SMTP AUTH can now look up passwords from the .netrc file - for that,
  fetchmail's esmtpname setting must match the login for the given host in
  .netrc. Fixes Debian Bug#1056651 by Ticker Berkin.
* Improve the GSSAPI (Kerberos V) build, which was pretty hard to get working.
  This was improved. Recommendation:
  - For autoconf builds (./configure), be sure to have the desired krb5-config
  executable early on $PATH before running ./configure.
  - For meson builds, be sure to list the path to your krb5-gssapi.pc file on
  PKG_CONFIG_PATH.  (meson will fall back to krb5-config, so if that's on PATH,
  that should also work.)

## TRANSLATION UPDATES were contributed by these fine people - thank you!
* The Italian translation is back - it had been missing from earlier 6.5.X
  since it had fallen too far behind with the last update in 2010.
* cs:    Petr Pisar [Czech]
* eo:    Keith Bowes [Esperanto]
* es:    Cristian Othón Martínez Vera [Spanish]
* fr:    Frédéric Marchal [French]
* it:    Luca Vercelli [Italian]
* ja:    Takeshi Hamasaki [Japanese]
* pl:    Jakub Bogusz [Polish]
* ro:    Remus-Gabriel Chelu [Romanian]
* sq:    Besnik Bleta [Albanian]
* sv:    Göran Uddeborg [Swedish]

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

[Fetchmail-users] ANNOUNCE: The 6.6.0.rc2 release candidate of fetchmail is available (TLS/STARTTLS support for SMTP)

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

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

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

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

The SHA256 hashes for the tarballs are:
SHA2-256(fetchmail-6.6.0.rc2.tar.xz)= e86fb99ff97398bedab92fe6e24bb5d7253363f7ba61d0915666caf6763742a4

Changes since rc1:
------------------
* ee3eb70f 2025-10-13 | Bump version to 6.6.0.rc2. (tag: 6.6.0.rc2)
* 560d636e 2025-10-12 | Support GSSAPI in meson builds.
* c32bb1e7 2025-10-11 | Fix/reformat meson build instructions.
* 7d6b903a 2025-10-11 | Fix LOCALEDIR for meson builds.
* 521d0607 2025-10-11 | Update German translation.
* 3038cdf0 2025-10-11 | Support wolfSSL in meson builds.
* bc09484d 2025-10-11 | Strip OPIE, add meson instructions
* dc490e4c 2025-10-11 | SMTP: also default-/notls 127.0.0.1/::1 and some variants
* a7861fa1 2025-10-11 | Rename match_regex -> regex_ere_search
* 41874f11 2025-10-11 | options.c: Add --esmtp* opts to --help.
* c80bcc5e 2025-10-10 | Set folders and tags to 6.6.0
* f44d0e6e 2025-10-10 | NEWS: remove angle brackets from MAIL FROM:<>


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

## FEATURE:
* SMTP TLS and STARTTLS support. By default, this works opportunistically,
  attempting to set up a TLS connection to the smtphost if it understands EHLO
  and offers STARTTLS, but will not enforce peer certificate validity for
  compatibility, esp. because "localhost" (the default SMTP host) usually
  isn't listed in the X.509 certificates.
    Behavior can be tweaked by adding /notls (cleartext connection), /tls
  (TLS-wrapped connection, negotiating TLS before conversing otherwise),
  or /starttls (requiring EHLO to offer STARTTLS, requesting the latter and
  requiring the server certificate to validate) to the SMTP host's name.
    Also, you can add /tlsproto=... where ... accepts the same parameters
  as the --sslproto option, which see.
  Ports, if not specified, default to 25 for opportunistic and /notls modes,
  465 for /tls and 587 for /starttls, but can be overridden either by giving,
  say /25 or /smtp for /starttls.

## TRANSLATIONS:
These will be requested only after fetchmail 6.5.7 will have been released.

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

[Fetchmail-users] ANNOUNCE: The 6.5.7.rc2 release candiate of fetchmail is available (SMTP AUTH fixes & .netrc support - NO (START)TLS yet)

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

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


Changes are listed below, but I have added wolfSSL and GSSAPI support to
meson-based builds.  I'd be happy to receive reports from people building with
meson if that works for you or if not, where not, how not.

I have not added all the tiny disable options to meson we used to have in
configure.ac, the POP3/IMAP features take 10...12 kByte on AMD64, and the
ETRN/ODMR less than 3 kByte each, in a 280 kByte sized executable.


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

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

The SHA256 hashes for the tarballs are:
SHA2-256(fetchmail-6.5.7.rc2.tar.xz)= 6b0a5aa50316b894b493c69e9c7c9ad5d8047df4703f483e97ed0a22a509172d

Note I have moved the tag after pushing it for the first time; it was on 686b6 first where I hadn't
committed the NEWS, configure.ac and meson.build file's bump to rc2 and crediting Besnik for the Shqip
(Albanian) translation, but the tarballs had already been built with the contents of what's now fd34e417.

Log since rc1: (newest first)
--------------
* fd34e417 2025-10-13 | Prepare 6.5.7.rc2. (tag: 6.5.7.rc2) [Matthias Andree]
* 686b6f64 2025-10-12 | Update <sq> Albanian translation to fetchmail-6.5.6 [Besnik Bleta]
* a46c2f3f 2025-10-12 | Support GSSAPI in meson builds. [Matthias Andree]
* 9dec1279 2025-10-11 | Support wolfSSL in meson builds. [Matthias Andree]
* 0ca08c94 2025-10-11 | Strip OPIE, add meson instructions [Matthias Andree]
* 29195d28 2025-10-11 | Fix LOCALEDIR for meson builds. [Matthias Andree]
* d9d4235a 2025-10-10 | NEWS: remove angle brackets from MAIL FROM:<> [Matthias Andree]
* 97765dff 2025-10-10 | Fix GNU tar --mtime argument when SOURCE_DATE_EPOCH is set. [Matthias Andree]


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

## BUGFIX:
* When authenticating to an SMTP server, the AUTH LOGIN method (which didn't
  become a proposed standard, and is only the third method fetchmail would try,
  if CRAM-MD5 and PLAIN weren't offered) required that the server returned
  a 334 code followed by a blank and by a decodable base64 challenge we ignored
  anyways.  This is in line with RFC 4952.
    However, to improve compatibility, fetchmail now accepts anything that
  starts with "334 " and disregards the remainder of the line.
  At the same time, AUTH LOGIN was deprecated. AUTH PLAIN should be available
  everywhere AUTH LOGIN is, and is specified in IETF RFC 4616.
* When authenticating to an SMTP server, i. e. esmtpname/esmtppassword are
  defined, check for errors, and skip servers that do not understand EHLO,
  because we cannot negotiate supported authentication schemes with them.
  This should avoid attempting to send a lot of messages and see them rejected.
* When authenticating to an SMTP server, do not send client abort "*" when
  we receive any other server reply but 334.
* Extend 6.5.6's RFC-5321 address-literal fix to MAIL FROM. This might
  apply when we only have a server's IP address and need to quality
  addresses without domain. Fixes Debian Bug#1080025.
* SMTP AUTH can now look up passwords from the .netrc file - for that,
  fetchmail's esmtpname setting must match the login for the given host in
  .netrc. Fixes Debian Bug#1056651 by Ticker Berkin.

## TRANSLATION UPDATES were contributed by these fine people - thank you!
* 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]
* pl:    Jakub Bogusz [Polish]
* ro:    Remus-Gabriel Chelu [Romanian]
* sq:    Besnik Bleta [Albanian]
* sv:    Göran Uddeborg [Swedish]

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

Re: [Fetchmail-users] ANNOUNCE: The 6.6.0.rc1 release of fetchmail is available (TLS/STARTTLS support for SMTP)

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

Am 11.10.25 um 17:11 schrieb axreios:
>
> Matthias: Fetchmail 6.6.0.rc1 connects to the ISP's mail server, 
> protocol imap4 rev 1,
> at port 143.  Starttls begins tls negotiation and ends up using tls 1.3
> openssl builtin ciphersuites.  I do not use netrc; passwords are in my
> ~/.fetchmailrc.  Fetchmail then passes off emails to opensmtpd that is
> running on my localhost.  Hope this helps.


Thanks, so the normal way still works, that's good.

Now I am still looking for someone else to report how SMTP to some 
"non-localhost" machine goes with TLS, STARTLS and/or SMTP AUTH with 
passwords.


Thanks
Matthias

Re: [Fetchmail-users] ANNOUNCE: The 6.6.0.rc1 release of fetchmail is available (TLS/STARTTLS support for SMTP)

[axreios <rp...@am...>]

On Sat, Oct 11, 2025 at 09:47:59AM +0200, Matthias Andree via Fetchmail-users wrote:
>Am 11.10.25 um 03:01 schrieb axreios:
>>Compiled this one without a problem on up-to-date Artix Linux and it is
>>working well for my little system.  Thanks again for your good efforts!
>
>Thanks. Do you use SMTP AUTH (esmtppassword and maybe esmtpname) there 
>or on the void linux you've tested 6.5.7.rc1 on at all, or an smtp 
>server that isn't named "localhost" (its default)?
>
>The SMTP AUTH and TLS stuff including netrc attempts is the only 
>user-facing feature (meaning non-detail) that changed in the recent 
>release candidates or 6.5.6 for that matter (yes it did touch a few 
>other files such as sink.c and options.c but that's minor detail), and 
>TLS is deliberately disabled for the default "localhost" because 
>certificates can't usefully mention that name and because it's 
>normally mapped to the loopback address and those spying SMTP there 
>(aka people with physical access) already have privileged access and 
>can just as well directly read password files or attach debuggers to 
>your process.  You can use 
>localhost/tls/servername=realname.example.org or 
>localhost/starttls/servername=realname.example.org (for smtphost, 
>respectively) though.
>
>You can of course try to authenticate to your SMTP server on localhost 
>if that supports it, and you could also force TLS or STARTTLS for 
>localhost, but the latter will usually lead to certificate validation 
>or "connection" or "SMTP" issues.
>
>So while the test is still valuable in that the new code doesn't seem 
>to cause nasty surprises, I'd also be happy to hear from anyone 
>fetching mail on one host and forwarding it to another. Please share 
>some details on fetchmail version and what's used - and you may want 
>to look at a -vv verbose output to see if fetchmail tries logging in 
>and/or uses TLS or STARTTLS at all. TLS needs to be added as /tls to 
>the smtphost's name. STARTTLS may work on port 25 but if it's only on 
>offer on port 587 you also need to configure either /starttls in 
>smtphost, or port /587 or service /smtps.    Say, myhost1.example.org 
>fetching mail and injecting on mailhost.example.com would use 
>--smtphost mailhost.example.com/tls or --smtphost 
>mailhost.example.com/starttls/25. Or /25/starttls. (Order of smtphost 
>/xxx options doesn't matter except that the hostname must come first. 
>Fetchmail calculates the default port from the seen or missing /*tls 
>options first and then overrides it with a portname or service name 
>even if that's before the /*tls options.)
>
>Thanks again!
>
>Happy fetching,
>Matthias
>
>
>
>_______________________________________________
>Fetchmail-users mailing list
>Fet...@li...
>https://lists.sourceforge.net/lists/listinfo/fetchmail-users

Matthias: Fetchmail 6.6.0.rc1 connects to the ISP's mail server, protocol imap4 rev 1,
at port 143.  Starttls begins tls negotiation and ends up using tls 1.3
openssl builtin ciphersuites.  I do not use netrc; passwords are in my
~/.fetchmailrc.  Fetchmail then passes off emails to opensmtpd that is
running on my localhost.  Hope this helps.
	ax

Re: [Fetchmail-users] ANNOUNCE: The 6.6.0.rc1 release of fetchmail is available (TLS/STARTTLS support for SMTP)

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

Am 11.10.25 um 03:01 schrieb axreios:
> Compiled this one without a problem on up-to-date Artix Linux and it is
> working well for my little system.  Thanks again for your good efforts!

Thanks. Do you use SMTP AUTH (esmtppassword and maybe esmtpname) there 
or on the void linux you've tested 6.5.7.rc1 on at all, or an smtp 
server that isn't named "localhost" (its default)?

The SMTP AUTH and TLS stuff including netrc attempts is the only 
user-facing feature (meaning non-detail) that changed in the recent 
release candidates or 6.5.6 for that matter (yes it did touch a few 
other files such as sink.c and options.c but that's minor detail), and 
TLS is deliberately disabled for the default "localhost" because 
certificates can't usefully mention that name and because it's normally 
mapped to the loopback address and those spying SMTP there (aka people 
with physical access) already have privileged access and can just as 
well directly read password files or attach debuggers to your process.  
You can use localhost/tls/servername=realname.example.org or 
localhost/starttls/servername=realname.example.org (for smtphost, 
respectively) though.

You can of course try to authenticate to your SMTP server on localhost 
if that supports it, and you could also force TLS or STARTTLS for 
localhost, but the latter will usually lead to certificate validation or 
"connection" or "SMTP" issues.

So while the test is still valuable in that the new code doesn't seem to 
cause nasty surprises, I'd also be happy to hear from anyone fetching 
mail on one host and forwarding it to another. Please share some details 
on fetchmail version and what's used - and you may want to look at a -vv 
verbose output to see if fetchmail tries logging in and/or uses TLS or 
STARTTLS at all. TLS needs to be added as /tls to the smtphost's name. 
STARTTLS may work on port 25 but if it's only on offer on port 587 you 
also need to configure either /starttls in smtphost, or port /587 or 
service /smtps.    Say, myhost1.example.org fetching mail and injecting 
on mailhost.example.com would use --smtphost mailhost.example.com/tls or 
--smtphost mailhost.example.com/starttls/25. Or /25/starttls. (Order of 
smtphost /xxx options doesn't matter except that the hostname must come 
first. Fetchmail calculates the default port from the seen or missing 
/*tls options first and then overrides it with a portname or service 
name even if that's before the /*tls options.)

Thanks again!

Happy fetching,
Matthias