fetchmail-users — User questions and discussion

Re: [Fetchmail-users] ssl with dslextreme.com attempts to send a spurious email

[jdow <jd...@ds...>]

On 20190429 16:02:24, Matthias Andree wrote:
> Am 27.04.19 um 23:28 schrieb jdow:
>> fetchmaillog per item 5.txt
>>
>> Syslog from:  env LC_ALL=C /usr/bin/fetchmail -d 60 --fetchmailrc
>> /home/jdow/.fetchmailrc
>>
>>
>> Apr 27 13:57:30 thursday fetchmail[31459]: starting fetchmail 6.3.24
>> daemon
>> Apr 27 13:57:32 thursday fetchmail[31459]: 1 message for
>> jd...@ea... at pop.earthlink.net (4706 octets).
>> Apr 27 13:57:32 thursday postfix/smtpd[30762]: connect from
>> localhost[::1]
>> Apr 27 13:57:32 thursday postfix/smtpd[30762]: warning: Illegal
>> address syntax from localhost[::1] in MAIL command:
>> <JkiO@JkiO----------------------.us-west-2.compute.amazonaws.com>
>> Apr 27 13:57:32 thursday fetchmail[31459]: reading message
>> jd...@ea...@pop.earthlink.net:1 of 1 (4706 octets) (log message
>> incomplete)
>> Apr 27 13:57:32 thursday fetchmail[31459]: SMTP error: 501 5.1.7 Bad
>> sender address syntax
>> Apr 27 13:57:32 thursday fetchmail[31459]: not flushed
>> Apr 27 13:57:32 thursday postfix/smtpd[30762]: disconnect from
>> localhost[::1]
> 
> 
> Joanne,
> 
> This pretty much looks like the faulty message is in the
> pop.earthlink.net account rather than the dslextreme.com, and I haven't
> seen configuration or verbose logging of the earthlink polls yet in this
> thread, unless I am overlooking something... and Postfix is right to
> reject the mail address, it is outside the permitted syntax for MAIL
> commands per the BNF syntax in RFC-5321 (page 41 bottom/42 top - in
> prose that specifies that the hyphen cannot be head or tail of a
> sub-domain part, but must be surrounded by "letter or digit").
> 
> The log message incomplete stems from the log "reading message" that
> gets interrupted by the 501 5.1.7 error, logging makes this excursion,
> and finally the "not flushed" concludes the original log message.
> 
> HTH
> 

For testing I disable the Earthlink accounts. That is why you don't see it.

That said I doctored the .fetchmailrc file bringing down to a forced plain text. 
The message persisted. I rewrote the file (cleared it and retyped the text) and 
now the problem seems to have resolved. The data appears to be the same. The 
issue seems to be gone. I REALLY REALLY wish I know what change I made worked. 
But, I suspect it will be a phenomenon with nothing further known about it.

(Yes, it was dumb of me to edit the way I did. I should have saved the old file 
to compare with the new. Ah well. I should know better. At least the log clutter 
is gone. Hm, I ought to play with tcpdump to see if there is an smtp connection 
going outside. I doubt it as that address bounced email from amazonaws with an 
account does not exit error. If there is such a thing you will hear from me again.)

{O.O}   Joanne

Re: [Fetchmail-users] ssl with dslextreme.com attempts to send a spurious email

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

Am 27.04.19 um 23:28 schrieb jdow:
> fetchmaillog per item 5.txt
>
> Syslog from:  env LC_ALL=C /usr/bin/fetchmail -d 60 --fetchmailrc
> /home/jdow/.fetchmailrc
>
>
> Apr 27 13:57:30 thursday fetchmail[31459]: starting fetchmail 6.3.24
> daemon
> Apr 27 13:57:32 thursday fetchmail[31459]: 1 message for
> jd...@ea... at pop.earthlink.net (4706 octets).
> Apr 27 13:57:32 thursday postfix/smtpd[30762]: connect from
> localhost[::1]
> Apr 27 13:57:32 thursday postfix/smtpd[30762]: warning: Illegal
> address syntax from localhost[::1] in MAIL command:
> <JkiO@JkiO----------------------.us-west-2.compute.amazonaws.com>
> Apr 27 13:57:32 thursday fetchmail[31459]: reading message
> jd...@ea...@pop.earthlink.net:1 of 1 (4706 octets) (log message
> incomplete)
> Apr 27 13:57:32 thursday fetchmail[31459]: SMTP error: 501 5.1.7 Bad
> sender address syntax
> Apr 27 13:57:32 thursday fetchmail[31459]: not flushed
> Apr 27 13:57:32 thursday postfix/smtpd[30762]: disconnect from
> localhost[::1] 


Joanne,

This pretty much looks like the faulty message is in the
pop.earthlink.net account rather than the dslextreme.com, and I haven't
seen configuration or verbose logging of the earthlink polls yet in this
thread, unless I am overlooking something... and Postfix is right to
reject the mail address, it is outside the permitted syntax for MAIL
commands per the BNF syntax in RFC-5321 (page 41 bottom/42 top - in
prose that specifies that the hyphen cannot be head or tail of a
sub-domain part, but must be surrounded by "letter or digit").

The log message incomplete stems from the log "reading message" that
gets interrupted by the 501 5.1.7 error, logging makes this excursion,
and finally the "not flushed" concludes the original log message.

HTH

Matthias

Re: [Fetchmail-users] ssl with dslextreme.com attempts to send a spurious email

[jdow <jd...@ds...>]

On 20190428 12:58:30, jdow wrote:
> On 20190428 11:10:30, jdow wrote:
>> On 20190428 04:28:25, Ralph Corderoy wrote:
>>> Hi Joanne,
>>>
>>>> These look suspicious in the first printout:
>>>> fetchmail: mail.dslextreme.com: WARNING: server offered STLS, but sslproto 
>>>> '' given.
>>>
>>> Is there a reason you have «sslproto ''» somewhere?
>>> fetchmail(1) says
>>>
>>>      To defeat opportunistic TLSv1 negotiation when the server advertises
>>>      STARTTLS or STLS, and use a cleartext connection use ''.
>>
>> Actually I do not have sslproto in there anywhere and I never have. Should I 
>> put it in? And with what value? That is a good reason for some form of 
>> complaint to be issued.
>>
>> I just tried "   sslproto auto" and "   sslproto auto   sslcertck" after the 
>> ssl and got an error line ten at auto. README.SSL is out of date?
>>
>> Hm, I wonder if this is something baked into RedHat fetchmail.... I shall 
>> investigate this.
>>
>>>> poll mail.dslextreme.com with proto pop3 port 995
>>>>       user 'jd...@ds...', with password 'xxxxx' ssl,
>>>>       is 'jdow@lllllll' here pass8bits
>>>> poll mail.dslextreme.com with proto pop3 port 995
>>>>       user 'YY...@ds...', with password 'yyyyyyy' ssl,
>>>>       is 'jdow@lllllll' here pass8bits
>>> ...
>>>> In the current configuration it looks like the YYYY ID was not polled, too.
>>>
>>> I think it is, but it's lllllll not YYYY.
>>
>> Um, yeah. It's a very little used ID and I forgot the real spelling when I 
>> went looking. I used it for setting up TeamViewer so I could help a blind very 
>> nontechnical friend with his computer. It seldom gets used these days. The 
>> state funded nursing assistant who helps him is adept enough now to handle it. 
>> He's 80+ years old.
>>
>>>> fetchmail: mail.dslextreme.com: WARNING: server offered STLS, but sslproto 
>>>> '' given.
>>>> fetchmail: POP3> USER jd...@ds...
>>>> fetchmail: POP3< +OK
>>>> fetchmail: POP3> PASS *
>>>> fetchmail: POP3< +OK server ready
>>> ...
>>>> fetchmail: mail.dslextreme.com: WARNING: server offered STLS, but sslproto 
>>>> '' given.
>>>> fetchmail: POP3> USER ll...@ds...
>>>> fetchmail: POP3< +OK
>>>> fetchmail: POP3> PASS *
>>>> fetchmail: POP3< +OK server ready
>>>
>>> This look significant:
>>>
>>>> Apr 27 13:57:32 thursday postfix/smtpd[30762]: connect from localhost[::1]
>>>> Apr 27 13:57:32 thursday postfix/smtpd[30762]: warning: Illegal address syntax
>>>>      from localhost[::1] in MAIL command:
>>>>      <JkiO@JkiO----------------------.us-west-2.compute.amazonaws.com>
>>>> Apr 27 13:57:32 thursday fetchmail[31459]: reading message
>>>>      jd...@ea...@pop.earthlink.net:1 of 1 (4706 octets) (log message 
>>>> incomplete)
>>>> Apr 27 13:57:32 thursday fetchmail[31459]: SMTP error: 501 5.1.7 Bad sender
>>>>      address syntax
>>>> Apr 27 13:57:32 thursday fetchmail[31459]: not flushed
>>>
>>> The `log message incomplete' is confusing.  It doesn't mean it's logging
>>> that the message was incomplete, as in `reading message' used on the
>>> previous line.  It means `log-message incomplete': the routine to log
>>> one message was called whilst another hadn't been completed.
>>
>> I believe that length might be the length of a message. I don't believe there 
>> is a message waiting on the dslextreme pop3 server. (It will do plain text 
>> logins and I checked in that mode.) I wonder if those octets contained the 
>> message that would have been sent.
>>
>>> If fetchmail isn't flushing (deleting) the message then it's still on
>>> the server, ready to cause problems again.  Have you tried talking POP3
>>> manually?  Something like this should show the top 30 lines of email 1.
>>>
>>>      telnet mail.dslextreme.com 995
>>>      USER ...
>>>      PASS ...
>>>      LIST
>>>      TOP 1 30
>>>      QUIT
>>>
>>> Or is there a web-mail interface that lets one `view full headers',
>>> i.e. gets the web-mail interface out of the way.
>>>
>>
>> Worth a recheck. Nada.
>>
>> $ telnet mail.dslextreme.com pop3
>> Trying 137.118.26.222...
>> Connected to mail.dslextreme.com.
>> Escape character is '^]'.
>> +OK POP3 ready
>> user ll...@ds...
>> +OK
>> pass .........
>> +OK server ready
>> list
>> +OK 0 messages
>> .
>> top 1 30
>> -ERR invalid message
>> quit
>> +OK nvl-mbs53.neonova.net Zimbra POP3 server closing connection
>> Connection closed by foreign host.
>> $ telnet mail.dslextreme.com pop3                             Trying 
>> 137.118.26.222...
>> Connected to mail.dslextreme.com.
>> Escape character is '^]'.
>> +OK POP3 ready
>> user jd...@ds...
>> +OK
>> pass  .........
>> +OK server ready
>> list
>> +OK 0 messages
>> .
>> top 1 30
>> -ERR invalid message
>> quit
>> +OK nvl-mbs50.neonova.net Zimbra POP3 server closing connection
>> Connection closed by foreign host.
>>
>>
>> I think I shall download the source and try to make sense of it. Where might I 
>> find the sslproto "auto" option parsed? That seems like a REALLY good place to 
>> start looking. And I shall recompile it myself as a check. It might even be 
>> worth downloading the latest fetchmail so I can compare.
>>
>> {^_^}
> 
> I obtained the source and....
> I see a pair of places sslproto is set to "" internally. This apparently happens 
> when processing ssl fetches as the --config option reports:  "sslproto":"TLS1+". 
> Both places happen in pop3.c.
> 
> ===8<--- This place, about line 420, looks suspicious to me
> #ifdef SSL_ENABLE
>              if (must_tls(ctl)) {
>              /* fail with mandatory STLS without repoll */
>              report(stderr, GT_("TLS is mandatory for this session, but server 
> refused CAPA command.\n"));
>              report(stderr, GT_("The CAPA command is however necessary for 
> TLS.\n"));
>              return ok;
>              } else if (maybe_tls(ctl)) {
>              /* defeat opportunistic STLS */
>              xfree(ctl->sslproto);
>              ctl->sslproto = xstrdup("");
>              }
> #endif
> ===8<--- = = should that be a !maybe_tls?
> 
> The other is about line 700
> ===8<===
> #ifdef SSL_ENABLE
>      /* this is for servers which claim to support TLS, but actually
>       * don't! */
>      if (connection_may_have_tls_errors
>              && (ok == PS_SOCKET || ok == PS_PROTOCOL))
>      {
>      xfree(ctl->sslproto);
>      ctl->sslproto = xstrdup("");
>      /* repoll immediately without TLS */
>      ok = PS_REPOLL;
>      }
> #endif
> ===8<---
> 
> Neither one seems to be instrumented so I do not know which one it went through.
> 
> {^_^}


So I changed the dslextreme polling to force plain text - nominally:
poll mail.dslextreme.com with proto pop3
    user 'jd...@ds...', with password '......' sslproto ''
    is 'jdow@thursday.wizardess.wiz' here pass8bits
    user 'jdt...@ds...', with password '......' sslproto ''
    is 'jdow@thursday.wizardess.wiz' here pass8bits

It appears that with "set no syslog" and no set daemon the spurious email goes 
away. With syslog and daemon the email is back even though it is nominally 
forced to use plain text. It still appears to be related to the server listing 
the ssl capability rather than the actual use of ssl. I'm getting even more 
confused by this silly effect.

===8<---
fetchmail: 6.3.24 querying mail.dslextreme.com (protocol POP3) at Sun 28 Apr 
2019 03:53:36 PM PDT: poll started
Trying to connect to 137.118.26.222/110...connected.
fetchmail: POP3< +OK POP3 ready
fetchmail: POP3> CAPA
fetchmail: POP3< +OK Capability list follows
fetchmail: POP3< EXPIRE 31 USER
fetchmail: POP3< TOP
fetchmail: POP3< UIDL
fetchmail: POP3< USER
fetchmail: POP3< XOIP
fetchmail: POP3< SASL PLAIN
fetchmail: POP3< STLS
fetchmail: POP3< .
fetchmail: mail.dslextreme.com: WARNING: server offered STLS, but sslproto '' given.
fetchmail: POP3> USER jd...@ds...
fetchmail: POP3< +OK
fetchmail: POP3> PASS *
fetchmail: POP3< +OK server ready
fetchmail: POP3> STAT
fetchmail: POP3< +OK 0 0
fetchmail: No mail for jd...@ds... at mail.dslextreme.com
fetchmail: POP3> QUIT
===8<---
In theory no SSL is being exercised no is there a check for the certificate.

{^_^}

Re: [Fetchmail-users] ssl with dslextreme.com attempts to send a spurious email

[jdow <jd...@ds...>]

On 20190428 11:10:30, jdow wrote:
> On 20190428 04:28:25, Ralph Corderoy wrote:
>> Hi Joanne,
>>
>>> These look suspicious in the first printout:
>>> fetchmail: mail.dslextreme.com: WARNING: server offered STLS, but sslproto '' 
>>> given.
>>
>> Is there a reason you have «sslproto ''» somewhere?
>> fetchmail(1) says
>>
>>      To defeat opportunistic TLSv1 negotiation when the server advertises
>>      STARTTLS or STLS, and use a cleartext connection use ''.
> 
> Actually I do not have sslproto in there anywhere and I never have. Should I put 
> it in? And with what value? That is a good reason for some form of complaint to 
> be issued.
> 
> I just tried "   sslproto auto" and "   sslproto auto   sslcertck" after the ssl 
> and got an error line ten at auto. README.SSL is out of date?
> 
> Hm, I wonder if this is something baked into RedHat fetchmail.... I shall 
> investigate this.
> 
>>> poll mail.dslextreme.com with proto pop3 port 995
>>>       user 'jd...@ds...', with password 'xxxxx' ssl,
>>>       is 'jdow@lllllll' here pass8bits
>>> poll mail.dslextreme.com with proto pop3 port 995
>>>       user 'YY...@ds...', with password 'yyyyyyy' ssl,
>>>       is 'jdow@lllllll' here pass8bits
>> ...
>>> In the current configuration it looks like the YYYY ID was not polled, too.
>>
>> I think it is, but it's lllllll not YYYY.
> 
> Um, yeah. It's a very little used ID and I forgot the real spelling when I went 
> looking. I used it for setting up TeamViewer so I could help a blind very 
> nontechnical friend with his computer. It seldom gets used these days. The state 
> funded nursing assistant who helps him is adept enough now to handle it. He's 
> 80+ years old.
> 
>>> fetchmail: mail.dslextreme.com: WARNING: server offered STLS, but sslproto '' 
>>> given.
>>> fetchmail: POP3> USER jd...@ds...
>>> fetchmail: POP3< +OK
>>> fetchmail: POP3> PASS *
>>> fetchmail: POP3< +OK server ready
>> ...
>>> fetchmail: mail.dslextreme.com: WARNING: server offered STLS, but sslproto '' 
>>> given.
>>> fetchmail: POP3> USER ll...@ds...
>>> fetchmail: POP3< +OK
>>> fetchmail: POP3> PASS *
>>> fetchmail: POP3< +OK server ready
>>
>> This look significant:
>>
>>> Apr 27 13:57:32 thursday postfix/smtpd[30762]: connect from localhost[::1]
>>> Apr 27 13:57:32 thursday postfix/smtpd[30762]: warning: Illegal address syntax
>>>      from localhost[::1] in MAIL command:
>>>      <JkiO@JkiO----------------------.us-west-2.compute.amazonaws.com>
>>> Apr 27 13:57:32 thursday fetchmail[31459]: reading message
>>>      jd...@ea...@pop.earthlink.net:1 of 1 (4706 octets) (log message 
>>> incomplete)
>>> Apr 27 13:57:32 thursday fetchmail[31459]: SMTP error: 501 5.1.7 Bad sender
>>>      address syntax
>>> Apr 27 13:57:32 thursday fetchmail[31459]: not flushed
>>
>> The `log message incomplete' is confusing.  It doesn't mean it's logging
>> that the message was incomplete, as in `reading message' used on the
>> previous line.  It means `log-message incomplete': the routine to log
>> one message was called whilst another hadn't been completed.
> 
> I believe that length might be the length of a message. I don't believe there is 
> a message waiting on the dslextreme pop3 server. (It will do plain text logins 
> and I checked in that mode.) I wonder if those octets contained the message that 
> would have been sent.
> 
>> If fetchmail isn't flushing (deleting) the message then it's still on
>> the server, ready to cause problems again.  Have you tried talking POP3
>> manually?  Something like this should show the top 30 lines of email 1.
>>
>>      telnet mail.dslextreme.com 995
>>      USER ...
>>      PASS ...
>>      LIST
>>      TOP 1 30
>>      QUIT
>>
>> Or is there a web-mail interface that lets one `view full headers',
>> i.e. gets the web-mail interface out of the way.
>>
> 
> Worth a recheck. Nada.
> 
> $ telnet mail.dslextreme.com pop3
> Trying 137.118.26.222...
> Connected to mail.dslextreme.com.
> Escape character is '^]'.
> +OK POP3 ready
> user ll...@ds...
> +OK
> pass .........
> +OK server ready
> list
> +OK 0 messages
> .
> top 1 30
> -ERR invalid message
> quit
> +OK nvl-mbs53.neonova.net Zimbra POP3 server closing connection
> Connection closed by foreign host.
> $ telnet mail.dslextreme.com pop3                             Trying 
> 137.118.26.222...
> Connected to mail.dslextreme.com.
> Escape character is '^]'.
> +OK POP3 ready
> user jd...@ds...
> +OK
> pass  .........
> +OK server ready
> list
> +OK 0 messages
> .
> top 1 30
> -ERR invalid message
> quit
> +OK nvl-mbs50.neonova.net Zimbra POP3 server closing connection
> Connection closed by foreign host.
> 
> 
> I think I shall download the source and try to make sense of it. Where might I 
> find the sslproto "auto" option parsed? That seems like a REALLY good place to 
> start looking. And I shall recompile it myself as a check. It might even be 
> worth downloading the latest fetchmail so I can compare.
> 
> {^_^}

I obtained the source and....
I see a pair of places sslproto is set to "" internally. This apparently happens 
when processing ssl fetches as the --config option reports:  "sslproto":"TLS1+". 
Both places happen in pop3.c.

===8<--- This place, about line 420, looks suspicious to me
#ifdef SSL_ENABLE
		    if (must_tls(ctl)) {
			/* fail with mandatory STLS without repoll */
			report(stderr, GT_("TLS is mandatory for this session, but server refused 
CAPA command.\n"));
			report(stderr, GT_("The CAPA command is however necessary for TLS.\n"));
			return ok;
		    } else if (maybe_tls(ctl)) {
			/* defeat opportunistic STLS */
			xfree(ctl->sslproto);
			ctl->sslproto = xstrdup("");
		    }
#endif
===8<--- = = should that be a !maybe_tls?

The other is about line 700
===8<===
#ifdef SSL_ENABLE
     /* this is for servers which claim to support TLS, but actually
      * don't! */
     if (connection_may_have_tls_errors
		    && (ok == PS_SOCKET || ok == PS_PROTOCOL))
     {
	xfree(ctl->sslproto);
	ctl->sslproto = xstrdup("");
	/* repoll immediately without TLS */
	ok = PS_REPOLL;
     }
#endif
===8<---

Neither one seems to be instrumented so I do not know which one it went through.

{^_^}

Re: [Fetchmail-users] ssl with dslextreme.com attempts to send a spurious email

[jdow <jd...@ds...>]

On 20190428 04:28:25, Ralph Corderoy wrote:
> Hi Joanne,
> 
>> These look suspicious in the first printout:
>> fetchmail: mail.dslextreme.com: WARNING: server offered STLS, but sslproto '' given.
> 
> Is there a reason you have «sslproto ''» somewhere?
> fetchmail(1) says
> 
>      To defeat opportunistic TLSv1 negotiation when the server advertises
>      STARTTLS or STLS, and use a cleartext connection use ''.

Actually I do not have sslproto in there anywhere and I never have. Should I put 
it in? And with what value? That is a good reason for some form of complaint to 
be issued.

I just tried "   sslproto auto" and "   sslproto auto   sslcertck" after the ssl 
and got an error line ten at auto. README.SSL is out of date?

Hm, I wonder if this is something baked into RedHat fetchmail.... I shall 
investigate this.

>> poll mail.dslextreme.com with proto pop3 port 995
>>       user 'jd...@ds...', with password 'xxxxx' ssl,
>>       is 'jdow@lllllll' here pass8bits
>> poll mail.dslextreme.com with proto pop3 port 995
>>       user 'YY...@ds...', with password 'yyyyyyy' ssl,
>>       is 'jdow@lllllll' here pass8bits
> ...
>> In the current configuration it looks like the YYYY ID was not polled, too.
> 
> I think it is, but it's lllllll not YYYY.

Um, yeah. It's a very little used ID and I forgot the real spelling when I went 
looking. I used it for setting up TeamViewer so I could help a blind very 
nontechnical friend with his computer. It seldom gets used these days. The state 
funded nursing assistant who helps him is adept enough now to handle it. He's 
80+ years old.

>> fetchmail: mail.dslextreme.com: WARNING: server offered STLS, but sslproto '' given.
>> fetchmail: POP3> USER jd...@ds...
>> fetchmail: POP3< +OK
>> fetchmail: POP3> PASS *
>> fetchmail: POP3< +OK server ready
> ...
>> fetchmail: mail.dslextreme.com: WARNING: server offered STLS, but sslproto '' given.
>> fetchmail: POP3> USER ll...@ds...
>> fetchmail: POP3< +OK
>> fetchmail: POP3> PASS *
>> fetchmail: POP3< +OK server ready
> 
> This look significant:
> 
>> Apr 27 13:57:32 thursday postfix/smtpd[30762]: connect from localhost[::1]
>> Apr 27 13:57:32 thursday postfix/smtpd[30762]: warning: Illegal address syntax
>>      from localhost[::1] in MAIL command:
>>      <JkiO@JkiO----------------------.us-west-2.compute.amazonaws.com>
>> Apr 27 13:57:32 thursday fetchmail[31459]: reading message
>>      jd...@ea...@pop.earthlink.net:1 of 1 (4706 octets) (log message incomplete)
>> Apr 27 13:57:32 thursday fetchmail[31459]: SMTP error: 501 5.1.7 Bad sender
>>      address syntax
>> Apr 27 13:57:32 thursday fetchmail[31459]: not flushed
> 
> The `log message incomplete' is confusing.  It doesn't mean it's logging
> that the message was incomplete, as in `reading message' used on the
> previous line.  It means `log-message incomplete': the routine to log
> one message was called whilst another hadn't been completed.

I believe that length might be the length of a message. I don't believe there is 
a message waiting on the dslextreme pop3 server. (It will do plain text logins 
and I checked in that mode.) I wonder if those octets contained the message that 
would have been sent.

> If fetchmail isn't flushing (deleting) the message then it's still on
> the server, ready to cause problems again.  Have you tried talking POP3
> manually?  Something like this should show the top 30 lines of email 1.
> 
>      telnet mail.dslextreme.com 995
>      USER ...
>      PASS ...
>      LIST
>      TOP 1 30
>      QUIT
> 
> Or is there a web-mail interface that lets one `view full headers',
> i.e. gets the web-mail interface out of the way.
> 

Worth a recheck. Nada.

$ telnet mail.dslextreme.com pop3
Trying 137.118.26.222...
Connected to mail.dslextreme.com.
Escape character is '^]'.
+OK POP3 ready
user ll...@ds...
+OK
pass .........
+OK server ready
list
+OK 0 messages
.
top 1 30
-ERR invalid message
quit
+OK nvl-mbs53.neonova.net Zimbra POP3 server closing connection
Connection closed by foreign host.
$ telnet mail.dslextreme.com pop3                             Trying 
137.118.26.222...
Connected to mail.dslextreme.com.
Escape character is '^]'.
+OK POP3 ready
user jd...@ds...
+OK
pass  .........
+OK server ready
list
+OK 0 messages
.
top 1 30
-ERR invalid message
quit
+OK nvl-mbs50.neonova.net Zimbra POP3 server closing connection
Connection closed by foreign host.


I think I shall download the source and try to make sense of it. Where might I 
find the sslproto "auto" option parsed? That seems like a REALLY good place to 
start looking. And I shall recompile it myself as a check. It might even be 
worth downloading the latest fetchmail so I can compare.

{^_^}

Re: [Fetchmail-users] ssl with dslextreme.com attempts to send a spurious email

[Ralph C. <ra...@in...>]

Hi Joanne,

> These look suspicious in the first printout:
> fetchmail: mail.dslextreme.com: WARNING: server offered STLS, but sslproto '' given.

Is there a reason you have «sslproto ''» somewhere?
fetchmail(1) says

    To defeat opportunistic TLSv1 negotiation when the server advertises
    STARTTLS or STLS, and use a cleartext connection use ''.

> poll mail.dslextreme.com with proto pop3 port 995
>      user 'jd...@ds...', with password 'xxxxx' ssl,
>      is 'jdow@lllllll' here pass8bits
> poll mail.dslextreme.com with proto pop3 port 995
>      user 'YY...@ds...', with password 'yyyyyyy' ssl,
>      is 'jdow@lllllll' here pass8bits
...
> In the current configuration it looks like the YYYY ID was not polled, too.

I think it is, but it's lllllll not YYYY.

> fetchmail: mail.dslextreme.com: WARNING: server offered STLS, but sslproto '' given.
> fetchmail: POP3> USER jd...@ds...
> fetchmail: POP3< +OK
> fetchmail: POP3> PASS *
> fetchmail: POP3< +OK server ready
...
> fetchmail: mail.dslextreme.com: WARNING: server offered STLS, but sslproto '' given.
> fetchmail: POP3> USER ll...@ds...
> fetchmail: POP3< +OK
> fetchmail: POP3> PASS *
> fetchmail: POP3< +OK server ready

This look significant:

> Apr 27 13:57:32 thursday postfix/smtpd[30762]: connect from localhost[::1]
> Apr 27 13:57:32 thursday postfix/smtpd[30762]: warning: Illegal address syntax 
>     from localhost[::1] in MAIL command: 
>     <JkiO@JkiO----------------------.us-west-2.compute.amazonaws.com>
> Apr 27 13:57:32 thursday fetchmail[31459]: reading message 
>     jd...@ea...@pop.earthlink.net:1 of 1 (4706 octets) (log message incomplete)
> Apr 27 13:57:32 thursday fetchmail[31459]: SMTP error: 501 5.1.7 Bad sender 
>     address syntax
> Apr 27 13:57:32 thursday fetchmail[31459]: not flushed

The `log message incomplete' is confusing.  It doesn't mean it's logging
that the message was incomplete, as in `reading message' used on the
previous line.  It means `log-message incomplete': the routine to log
one message was called whilst another hadn't been completed.

If fetchmail isn't flushing (deleting) the message then it's still on
the server, ready to cause problems again.  Have you tried talking POP3
manually?  Something like this should show the top 30 lines of email 1.

    telnet mail.dslextreme.com 995
    USER ...
    PASS ...
    LIST
    TOP 1 30
    QUIT

Or is there a web-mail interface that lets one `view full headers',
i.e. gets the web-mail interface out of the way.

-- 
Cheers, Ralph.

Re: [Fetchmail-users] ssl with dslextreme.com attempts to send a spurious email

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

On Saturday 27 April 2019 17:28:45 jdow wrote:

> On 20190427 03:11:23, Matthias Andree wrote:
>   > Am 24.04.19 um 18:47 schrieb jdow:
>   >> Fetchmail feeds off to Postfix which runs spamassassin via
>   >> procmail. It is a working configuration from way back so I
>   >> elected to perpetuate it rather than fix it. {^_-}
>   >>
>   >> This (or an older version of it) has been working for a couple
>   >> decades or more.
>   >> Along about 2019-Apr-04 it started to try to send an email to a
>   >> rather enigmatic address,
>   >> JkiO@JkiO----------------------.{MUNG]us-west-2.compute.amazonaws
>   >>.com. Old logwatch reports show a few sporadic "Illegal address
>   >> syntax in SMTP command" errors in the Postfix syslog messages.
>   >> But now I am getting them nearly every poll cycle. Nothing is
>   >> going out because I do not use the local Postfix for sending
>   >> mail. It seems to be an unnecessary step in the sending process.
>   >> I believe I have determined it is fetchmail itself that is
>   >> acquiring the localhost socket to send the mail using the audit
>   >> facility.
>   >>
>   >> What configuration error might I have introduced?
>   >
>   > Joanne,
>   >
>   > you are not using a multi-user mailbox setup unless you stripped
>   > more than the password from the poll mail.dslextreme.com section.
>   > I am however wondering if 6.3.24 is really the latest fetchmail
>   > package for Scientific Linux.
>
> I am fetching from multiple users and ISPs on the source end and
> feeding a single user on the local destination end. The second ISP,
> earthlink, does not use SSL. A second fetchmail is running in another
> user's account that is not showing this problem because it is not
> using SSL, either.
>
Which could be an ssl/tls problem, there have been changes in the last 
year, and maybe your linux hasn't kept itself up to date on that? Just a 
thought but I'd be checking version numbers just in case.  My current 
install on this box is waaaay too old, but I think I have that fix in 
progress finally.

Take care JoAnne.

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)
Genes Web page <http://geneslinuxbox.net:6309/gene>

Re: [Fetchmail-users] ssl with dslextreme.com attempts to send a spurious email

[jdow <jd...@ds...>]

On 20190427 14:51:20, Carlos E. R. wrote:
> On 27/04/2019 23.28, jdow wrote:
> 
>> ...
>> And the second one comments out the second poll line in the above:
>> poll mail.dslextreme.com with proto pop3 port 995
>>      user 'jd...@ds...', with password 'xxxxx' ssl,
>>      is 'jdow@thursday.wizardess.wiz' here pass8bits
>> #poll mail.dslextreme.com with proto pop3 port 995
>>      user 'YY...@ds...', with password 'yyyyyyy' ssl,
>>      is 'jdow@lllllll' here pass8bits
>> poll pop.earthlink.net with proto pop3
> 
> I think that should be:
> 
>   poll mail.dslextreme.com with proto pop3 port 995
>       user 'jd...@ds...', with password 'xxxxx' ssl,
>       is 'jdow@llllllll' here pass8bits
>   #poll mail.dslextreme.com with proto pop3 port 995
>   #    user 'YY...@ds...', with password 'yyyyyyy' ssl,
>   #    is 'jdow@lllllll' here pass8bits
>   poll pop.earthlink.net with proto pop3
>     ...

That locks out the second user id at dslextreme. Incidentally, when I do this I 
still get the spurious email. I can comment out either of the two addresses and 
still get the same number of spurious emails.

> Alternatively:
> 
> poll mail.dslextreme.com with proto pop3 port 995
>      user 'jd...@ds...', with password 'xxxxx' ssl, is 'jdow@llllllll' here pass8bits
>      #user 'YY...@ds...', with password 'yyyyyyy' ssl, is 'jdow@lllllll' here pass8bits
> poll pop.earthlink.net with proto pop3
>    ...
> 

{^_^}

Re: [Fetchmail-users] ssl with dslextreme.com attempts to send a spurious email

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

On 27/04/2019 23.28, jdow wrote:

> ...
> And the second one comments out the second poll line in the above:
> poll mail.dslextreme.com with proto pop3 port 995
>     user 'jd...@ds...', with password 'xxxxx' ssl,
>     is 'jdow@thursday.wizardess.wiz' here pass8bits
> #poll mail.dslextreme.com with proto pop3 port 995
>     user 'YY...@ds...', with password 'yyyyyyy' ssl,
>     is 'jdow@lllllll' here pass8bits
> poll pop.earthlink.net with proto pop3

I think that should be:

 poll mail.dslextreme.com with proto pop3 port 995
     user 'jd...@ds...', with password 'xxxxx' ssl,
     is 'jdow@thursday.wizardess.wiz' here pass8bits
 #poll mail.dslextreme.com with proto pop3 port 995
 #    user 'YY...@ds...', with password 'yyyyyyy' ssl,
 #    is 'jdow@lllllll' here pass8bits
 poll pop.earthlink.net with proto pop3
   ...


Alternatively:

poll mail.dslextreme.com with proto pop3 port 995
    user 'jd...@ds...', with password 'xxxxx' ssl, is 'jdow@thursday.wizardess.wiz' here pass8bits
    #user 'YY...@ds...', with password 'yyyyyyy' ssl, is 'jdow@lllllll' here pass8bits
poll pop.earthlink.net with proto pop3
  ...

-- 
Cheers / Saludos,
               
		Carlos E. R.

  (from openSUSE, Leap 15.1 x86_64 (ssd-test))

Re: [Fetchmail-users] ssl with dslextreme.com attempts to send a spurious email

[jdow <jd...@ds...>]

On 20190427 03:24:33, Ralph Corderoy wrote:
> Hi Joanne,
> 
> Copying back in the list, and quoting verbosely...
> 
>>> I think it would be worthing checking in Centos's package-upgrade
>>> log to see what packages upgraded around 2019-Apr-04 when the
>>> symptom appeared.
>>
>> I started to do that but checked back in logs first. The issue
>> happened intermittently well before it went bad. Clamav was updated on
>> that date. It is used in the spamassassin processing using spamd. So
>> if it was a spamassassin thing spamd would be opening the port or
>> procmail would be opening the port.  Auditd showed it was fetchmail
>> that opened the port.
> 
> I don't think that's true.  I think Clamav/Spamassassin can feed back
> the status to fetchmail that then sends the bounce.

I do have bounces disabled with spamassassin. This is happening on the order of 
900 times a day. I poll fetchmail once a minute, 1440 times a day. I do not get 
900 mails a day. I get on the order of 200 spams a day and about 50 non-spams a 
day. So the numbers do not align.

I consider bounce emails to be exceptionally evil after being stuck on the 
"Bounce" end of several joe jobs before people became aware of the problem.

{^_^}

Re: [Fetchmail-users] ssl with dslextreme.com attempts to send a spurious email

[jdow <jd...@ds...>]

On 20190427 03:11:23, Matthias Andree wrote:
  > Am 24.04.19 um 18:47 schrieb jdow:
  >> Fetchmail feeds off to Postfix which runs spamassassin via procmail.
  >> It is a working configuration from way back so I elected to perpetuate
  >> it rather than fix it. {^_-}
  >>
  >> This (or an older version of it) has been working for a couple decades
  >> or more.
  >> Along about 2019-Apr-04 it started to try to send an email to a rather
  >> enigmatic address,
  >> JkiO@JkiO----------------------.{MUNG]us-west-2.compute.amazonaws.com.
  >> Old logwatch reports show a few sporadic "Illegal address syntax in
  >> SMTP command" errors in the Postfix syslog messages. But now I am
  >> getting them nearly every poll cycle. Nothing is going out because I
  >> do not use the local Postfix for sending mail. It seems to be an
  >> unnecessary step in the sending process. I believe I have determined
  >> it is fetchmail itself that is acquiring the localhost socket to send
  >> the mail using the audit facility.
  >>
  >> What configuration error might I have introduced?
  >
  > Joanne,
  >
  > you are not using a multi-user mailbox setup unless you stripped more
  > than the password from the poll mail.dslextreme.com section. I am
  > however wondering if 6.3.24 is really the latest fetchmail package for
  > Scientific Linux.

I am fetching from multiple users and ISPs on the source end and feeding a 
single user on the local destination end. The second ISP, earthlink, does not 
use SSL. A second fetchmail is running in another user's account that is not 
showing this problem because it is not using SSL, either.

I have tried two configurations:
Originally
poll mail.dslextreme.com with proto pop3 port 995
     user 'jd...@ds...', with password 'xxxxx' ssl,
     is 'jdow@lllllll' here pass8bits
poll mail.dslextreme.com with proto pop3 port 995
     user 'YY...@ds...', with password 'yyyyyyy' ssl,
     is 'jdow@lllllll' here pass8bits
poll pop.earthlink.net with proto pop3
...
And the second one comments out the second poll line in the above:
poll mail.dslextreme.com with proto pop3 port 995
     user 'jd...@ds...', with password 'xxxxx' ssl,
     is 'jdow@thursday.wizardess.wiz' here pass8bits
#poll mail.dslextreme.com with proto pop3 port 995
     user 'YY...@ds...', with password 'yyyyyyy' ssl,
     is 'jdow@lllllll' here pass8bits
poll pop.earthlink.net with proto pop3

Both show the same problem. And the --configuration printout appears to make 
sense to me.

  > Can we look at some logging around the faulty message? Something like:
  >
  > /usr/bin/fetchmail -vv --nosyslog --nodetach --fetchmailrc
  > /home/jdow/.fetchmailrc
  >
  > (along the lines of <http://www.fetchmail.info/fetchmail-FAQ.html#G3>,
  > item 5 would show us how fetchmail sees your configuration)

These look suspicious in the first printout:
fetchmail: mail.dslextreme.com: WARNING: server offered STLS, but sslproto '' given.
fetchmail: POP3> USER jd...@ds...

In the current configuration it looks like the YYYY ID was not polled, too.

The per item 5 log shows the JkiO mail being sent.


  > Has your computer running fetchmail developed hardware troubles? Does it
  > use ECC-protected RAM, and if so, is there relevant EDAC logging? Is
  > other software malfunctioning since c. three weeks? Have there been
  > power brownouts or flukes somehow, and has the computer been rebooted since?
  >
  > Greetings
  > Matthias

No, the computer has not been rebooted.

This MAY be related to the ISP changing over from DHCP connections to PPPOE. But 
I don't see how the MTU change that brings to the table would change things. The 
earliest illegal address log entry I found is more than a year old. So whatever 
triggered it a few times over a couple years is now triggering regularly.

I did go ahead and reinstall fetchmail. And, indeed, that is the version of 
fetchmail that is current in CENTOS and Scientific Linux. (I'll likely be 
gritting my teeth and moving over to CENTOS since SL is not moving on to RHEL8 
clone status.) The version is currently 7.6.

{^_^}

fetchmaillog.txt

   /usr/bin/fetchmail -vv --nosyslog --nodetach --fetchmailrc 
/home/jdow/.fetchmailrc
Old UID list from mail.dslextreme.com: <empty>
Old UID list from mail.dslextreme.com: <empty>
Old UID list from pop.earthlink.net: <empty>
Old UID list from pop.earthlink.net: <empty>
Old UID list from pop.earthlink.net: <empty>
Old UID list from pop.earthlink.net: <empty>
Scratch list of UIDs: <empty>
fetchmail: starting fetchmail 6.3.24 daemon
fetchmail: 6.3.24 querying mail.dslextreme.com (protocol POP3) at Sat 27 Apr 
2019 01:30:49 PM PDT: poll started
Trying to connect to 137.118.26.222/995...connected.
fetchmail: Certificate chain, from root to peer, starting at depth 3:
fetchmail: Issuer Organization: The Go Daddy Group, Inc.
fetchmail: Unknown Issuer CommonName
fetchmail: Certificate at depth 2:
fetchmail: Issuer Organization: The Go Daddy Group, Inc.
fetchmail: Unknown Issuer CommonName
fetchmail: Subject CommonName: Go Daddy Root Certificate Authority - G2
fetchmail: Certificate at depth 1:
fetchmail: Issuer Organization: GoDaddy.com, Inc.
fetchmail: Issuer CommonName: Go Daddy Root Certificate Authority - G2
fetchmail: Subject CommonName: Go Daddy Secure Certificate Authority - G2
fetchmail: Server certificate:
fetchmail: Issuer Organization: GoDaddy.com, Inc.
fetchmail: Issuer CommonName: Go Daddy Secure Certificate Authority - G2
fetchmail: Subject CommonName: *.dslextreme.com
fetchmail: Subject Alternative Name: *.dslextreme.com
fetchmail: Subject Alternative Name: dslextreme.com
fetchmail: mail.dslextreme.com key fingerprint: 
42:1C:EA:3D:8E:FA:ED:F9:B4:90:79:6C:9E:39:BC:7B
fetchmail: SSL/TLS: using protocol TLSv1.2, cipher DHE-RSA-AES256-GCM-SHA384, 
256/256 secret/processed bits
fetchmail: POP3< +OK POP3 ready
fetchmail: POP3> CAPA
fetchmail: POP3< +OK Capability list follows
fetchmail: POP3< EXPIRE 31 USER
fetchmail: POP3< TOP
fetchmail: POP3< UIDL
fetchmail: POP3< USER
fetchmail: POP3< XOIP
fetchmail: POP3< SASL PLAIN
fetchmail: POP3< STLS
fetchmail: POP3< .
fetchmail: mail.dslextreme.com: WARNING: server offered STLS, but sslproto '' given.
fetchmail: POP3> USER jd...@ds...
fetchmail: POP3< +OK
fetchmail: POP3> PASS *
fetchmail: POP3< +OK server ready
fetchmail: selecting or re-polling default folder
fetchmail: POP3> STAT
fetchmail: POP3< +OK 1 1281491
fetchmail: POP3> LAST
fetchmail: POP3< -ERR unknown command
fetchmail: unknown command
fetchmail: POP3> UIDL
fetchmail: POP3< +OK 1 messages
fetchmail: POP3< 1 5928.8p0vRawWBA69Us0DkhdJHmu1RGZ3jq62,Jr1j3KpouQ=
fetchmail: 1 is unseen
fetchmail: POP3< .
1 message for jd...@ds... at mail.dslextreme.com (1281491 octets).
fetchmail: POP3> LIST 1
fetchmail: POP3< +OK 1 1281491
fetchmail: POP3> TOP 1 99999999
fetchmail: POP3< +OK message top follows
reading message jd...@ds...@dslextreme.com.av-mx.com:1 of 1 (1281491 
octets) About to rewrite Return-Path: bou...@gr......
...rewritten version is Return-Path: bou...@gr....
About to rewrite From: "Simon Brown" <****@****.com>...
...rewritten version is From: "Simon Brown" <****@****.com>.
About to rewrite To: <SDR...@gr...>...
...rewritten version is To: <SDR...@gr...>.
About to rewrite Sender: SDR...@gr......
...rewritten version is Sender: SDR...@gr....
About to rewrite Reply-To: SDR...@gr......
...rewritten version is Reply-To: SDR...@gr....

Trying to connect to ::1/25...connected.
fetchmail: SMTP< 220 lllllll ESMTP Postfix
fetchmail: SMTP> EHLO lllllll
fetchmail: SMTP< 250-lllllll
fetchmail: SMTP< 250-PIPELINING
fetchmail: SMTP< 250-SIZE 134217728
fetchmail: SMTP< 250-VRFY
fetchmail: SMTP< 250-ETRN
fetchmail: SMTP< 250-ENHANCEDSTATUSCODES
fetchmail: SMTP< 250-8BITMIME
fetchmail: SMTP< 250 DSN
fetchmail: forwarding to localhost
fetchmail: SMTP> MAIL FROM:<bou...@gr...> 
BODY=8BITMIME SIZE=1281491
fetchmail: SMTP< 250 2.1.0 Ok
fetchmail: SMTP> RCPT TO:<jdow@lllllll>
fetchmail: SMTP< 250 2.1.5 Ok
fetchmail: SMTP> DATA
fetchmail: SMTP< 354 End data with <CR><LF>.<CR><LF>
... Binary removed
fetchmail: SMTP>. (EOM)
fetchmail: SMTP< 250 2.0.0 Ok: queued as B3AB5419923C
   flushed
fetchmail: POP3> DELE 1
fetchmail: POP3< +OK message 1 marked for deletion
fetchmail: POP3> QUIT
fetchmail: POP3< +OK deleted 1 message(s)
fetchmail: SMTP> QUIT
fetchmail: SMTP< 221 2.0.0 Bye
fetchmail: 6.3.24 querying mail.dslextreme.com (protocol POP3) at Sat 27 Apr 
2019 01:30:52 PM PDT: poll completed
New UID list from mail.dslextreme.com: 
5928.8p0vRawWBA69Us0DkhdJHmu1RGZ3jq62,Jr1j3KpouQ= = EXPUNGED
fetchmail: swapping UID lists
fetchmail: 6.3.24 querying mail.dslextreme.com (protocol POP3) at Sat 27 Apr 
2019 01:30:52 PM PDT: poll started
Trying to connect to 137.118.26.222/995...connected.
fetchmail: Certificate chain, from root to peer, starting at depth 3:
fetchmail: Issuer Organization: The Go Daddy Group, Inc.
fetchmail: Unknown Issuer CommonName
fetchmail: Certificate at depth 2:
fetchmail: Issuer Organization: The Go Daddy Group, Inc.
fetchmail: Unknown Issuer CommonName
fetchmail: Subject CommonName: Go Daddy Root Certificate Authority - G2
fetchmail: Certificate at depth 1:
fetchmail: Issuer Organization: GoDaddy.com, Inc.
fetchmail: Issuer CommonName: Go Daddy Root Certificate Authority - G2
fetchmail: Subject CommonName: Go Daddy Secure Certificate Authority - G2
fetchmail: Server certificate:
fetchmail: Issuer Organization: GoDaddy.com, Inc.
fetchmail: Issuer CommonName: Go Daddy Secure Certificate Authority - G2
fetchmail: Subject CommonName: *.dslextreme.com
fetchmail: Subject Alternative Name: *.dslextreme.com
fetchmail: Subject Alternative Name: dslextreme.com
fetchmail: mail.dslextreme.com key fingerprint: 
42:1C:EA:3D:8E:FA:ED:F9:B4:90:79:6C:9E:39:BC:7B
fetchmail: SSL/TLS: using protocol TLSv1.2, cipher DHE-RSA-AES256-GCM-SHA384, 
256/256 secret/processed bits
fetchmail: POP3< +OK POP3 ready
fetchmail: POP3> CAPA
fetchmail: POP3< +OK Capability list follows
fetchmail: POP3< EXPIRE 31 USER
fetchmail: POP3< TOP
fetchmail: POP3< UIDL
fetchmail: POP3< USER
fetchmail: POP3< XOIP
fetchmail: POP3< SASL PLAIN
fetchmail: POP3< STLS
fetchmail: POP3< .
fetchmail: mail.dslextreme.com: WARNING: server offered STLS, but sslproto '' given.
fetchmail: POP3> USER ll...@ds...
fetchmail: POP3< +OK
fetchmail: POP3> PASS *
fetchmail: POP3< +OK server ready
fetchmail: selecting or re-polling default folder
fetchmail: POP3> STAT
fetchmail: POP3< +OK 0 0
fetchmail: No mail for ll...@ds... at mail.dslextreme.com
fetchmail: POP3> QUIT
fetchmail: POP3< +OK nvl-mbs53.neonova.net Zimbra POP3 server closing connection
fetchmail: 6.3.24 querying mail.dslextreme.com (protocol POP3) at Sat 27 Apr 
2019 01:30:53 PM PDT: poll completed
New UID list from mail.dslextreme.com: <empty>
fetchmail: not swapping UID lists, no UIDs seen this query
fetchmail: Query status=1 (NOMAIL)
fetchmail: 6.3.24 querying pop.earthlink.net (protocol POP3) at Sat 27 Apr 2019 
01:30:53 PM PDT: poll started
Trying to connect to 209.86.93.201/110...connected.
fetchmail: POP3< +OK NGPopper vEL_0_1_42_P at earthlink.net ready 
<276...@mp...>
.... 4 earthlink ID transactions removed
fetchmail: sleeping at Sat 27 Apr 2019 01:30:58 PM PDT for 60 seconds


fetchmaillog per item 5.txt

Syslog from:  env LC_ALL=C /usr/bin/fetchmail -d 60 --fetchmailrc 
/home/jdow/.fetchmailrc


Apr 27 13:57:30 thursday fetchmail[31459]: starting fetchmail 6.3.24 daemon
Apr 27 13:57:32 thursday fetchmail[31459]: 1 message for jd...@ea... at 
pop.earthlink.net (4706 octets).
Apr 27 13:57:32 thursday postfix/smtpd[30762]: connect from localhost[::1]
Apr 27 13:57:32 thursday postfix/smtpd[30762]: warning: Illegal address syntax 
from localhost[::1] in MAIL command: 
<JkiO@JkiO----------------------.us-west-2.compute.amazonaws.com>
Apr 27 13:57:32 thursday fetchmail[31459]: reading message 
jd...@ea...@pop.earthlink.net:1 of 1 (4706 octets) (log message incomplete)
Apr 27 13:57:32 thursday fetchmail[31459]: SMTP error: 501 5.1.7 Bad sender 
address syntax
Apr 27 13:57:32 thursday fetchmail[31459]: not flushed
Apr 27 13:57:32 thursday postfix/smtpd[30762]: disconnect from localhost[::1]



On 20190427 03:11:23, Matthias Andree wrote:
> Am 24.04.19 um 18:47 schrieb jdow:
>> Fetchmail feeds off to Postfix which runs spamassassin via procmail.
>> It is a working configuration from way back so I elected to perpetuate
>> it rather than fix it. {^_-}
>>
>> This (or an older version of it) has been working for a couple decades
>> or more.
>> Along about 2019-Apr-04 it started to try to send an email to a rather
>> enigmatic address,
>> JkiO@JkiO----------------------.{MUNG]us-west-2.compute.amazonaws.com.
>> Old logwatch reports show a few sporadic "Illegal address syntax in
>> SMTP command" errors in the Postfix syslog messages. But now I am
>> getting them nearly every poll cycle. Nothing is going out because I
>> do not use the local Postfix for sending mail. It seems to be an
>> unnecessary step in the sending process. I believe I have determined
>> it is fetchmail itself that is acquiring the localhost socket to send
>> the mail using the audit facility.
>>
>> What configuration error might I have introduced?
> 
> Joanne,
> 
> you are not using a multi-user mailbox setup unless you stripped more
> than the password from the poll mail.dslextreme.com section. I am
> however wondering if 6.3.24 is really the latest fetchmail package for
> Scientific Linux.
> 
> Can we look at some logging around the faulty message? Something like:
> 
> /usr/bin/fetchmail -vv --nosyslog --nodetach --fetchmailrc
> /home/jdow/.fetchmailrc
> 
> (along the lines of <http://www.fetchmail.info/fetchmail-FAQ.html#G3>,
> item 5 would show us how fetchmail sees your configuration)
> 
> Has your computer running fetchmail developed hardware troubles? Does it
> use ECC-protected RAM, and if so, is there relevant EDAC logging? Is
> other software malfunctioning since c. three weeks? Have there been
> power brownouts or flukes somehow, and has the computer been rebooted since?
> 
> Greetings
> Matthias
> 
> 
> 
> 
> _______________________________________________
> Fetchmail-users mailing list
> Fet...@li...
> https://lists.sourceforge.net/lists/listinfo/fetchmail-users
> 

Re: [Fetchmail-users] ssl with dslextreme.com attempts to send a spurious email

[Ralph C. <ra...@in...>]

Hi Joanne,

Copying back in the list, and quoting verbosely...

> > I think it would be worthing checking in Centos's package-upgrade
> > log to see what packages upgraded around 2019-Apr-04 when the
> > symptom appeared.
>
> I started to do that but checked back in logs first. The issue
> happened intermittently well before it went bad. Clamav was updated on
> that date. It is used in the spamassassin processing using spamd. So
> if it was a spamassassin thing spamd would be opening the port or
> procmail would be opening the port.  Auditd showed it was fetchmail
> that opened the port.

I don't think that's true.  I think Clamav/Spamassassin can feed back
the status to fetchmail that then sends the bounce.

> > > > JkiO@JkiO----------------------.{MUNG]us-west-2.compute.amazonaws.com.
> > 
> > That looks like an address in an incoming email that's being
> > processed?
>
> That has occurred to me. However there are two SSL accounts with DSL
> Extreme and if either one of them is disabled the emails continue.
> Furthermore, if both are enabled I do not get pairs of emails. So I am
> scratching my head furiously.
>
> > > > set no bouncemail
> > > > set no spambounce
>
> Ayup. And I had been using ONE of the ssl usernames for years with
> only very sporadic events until it became a regular thing about April
> 4th this year. I enabled the second account, though, the better part
> of a year ago.
>
> I played some testing games. The specific address for the email
> bounces. So at least for now it is safe. I think I shall see what
> happens refreshing the install for fetchmail in a day or two.

-- 
Cheers, Ralph.

Re: [Fetchmail-users] ssl with dslextreme.com attempts to send a spurious email

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

Am 24.04.19 um 18:47 schrieb jdow:
> Fetchmail feeds off to Postfix which runs spamassassin via procmail.
> It is a working configuration from way back so I elected to perpetuate
> it rather than fix it. {^_-}
>
> This (or an older version of it) has been working for a couple decades
> or more.
> Along about 2019-Apr-04 it started to try to send an email to a rather
> enigmatic address,
> JkiO@JkiO----------------------.{MUNG]us-west-2.compute.amazonaws.com.
> Old logwatch reports show a few sporadic "Illegal address syntax in
> SMTP command" errors in the Postfix syslog messages. But now I am
> getting them nearly every poll cycle. Nothing is going out because I
> do not use the local Postfix for sending mail. It seems to be an
> unnecessary step in the sending process. I believe I have determined
> it is fetchmail itself that is acquiring the localhost socket to send
> the mail using the audit facility.
>
> What configuration error might I have introduced? 

Joanne,

you are not using a multi-user mailbox setup unless you stripped more
than the password from the poll mail.dslextreme.com section. I am
however wondering if 6.3.24 is really the latest fetchmail package for
Scientific Linux.

Can we look at some logging around the faulty message? Something like:

/usr/bin/fetchmail -vv --nosyslog --nodetach --fetchmailrc
/home/jdow/.fetchmailrc

(along the lines of <http://www.fetchmail.info/fetchmail-FAQ.html#G3>,
item 5 would show us how fetchmail sees your configuration)

Has your computer running fetchmail developed hardware troubles? Does it
use ECC-protected RAM, and if so, is there relevant EDAC logging? Is
other software malfunctioning since c. three weeks? Have there been
power brownouts or flukes somehow, and has the computer been rebooted since?

Greetings
Matthias

Re: [Fetchmail-users] ssl with dslextreme.com attempts to send a spurious email

[Ralph C. <ra...@in...>]

Hi Gene,

> Joanne <jdow> wrote:
> > I am running up to date Scientific Linix 7.x (Centos).
> > The fetchmail version is fetchmail-6.3.24-7.el7.x86_64.

I think it would be worthing checking in Centos's package-upgrade log to
see what packages upgraded around 2019-Apr-04 when the symptom appeared.

> > Along about 2019-Apr-04 it started to try to send an email to a
> > rather enigmatic address,
> > JkiO@JkiO----------------------.{MUNG]us-west-2.compute.amazonaws.com.

That looks like an address in an incoming email that's being processed?

> > I believe I have determined it is fetchmail itself that is acquiring
> > the localhost socket to send the mail using the audit facility.
...
> My first question is, when did fetchmail grow sendmail like legs?

It can originate a bounce email when it finds downstream objects.
Joanne is aware of this, based on her

> > set no bouncemail
> > set no spambounce

-- 
Cheers, Ralph.

Re: [Fetchmail-users] ssl with dslextreme.com attempts to send a spurious email

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

On 24/04/2019 23.43, Gene Heskett wrote:
> My first question is, when did fetchmail grow sendmail like legs?

Since ever :-)

-- 
Cheers / Saludos,

		Carlos E. R.

  (from openSUSE, Leap 15.1 x86_64 (ssd-test))

Re: [Fetchmail-users] ssl with dslextreme.com attempts to send a spurious email

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

On Wednesday 24 April 2019 12:47:14 jdow wrote:

> I am running up to date Scientific Linix 7.x (Centos). The fetchmail
> version is fetchmail-6.3.24-7.el7.x86_64. Openssl is
> openssl-1.0.2k-16.el7_6.1.x86_64. The .fetchmailrc file looks like:
> ===8<---
> set syslog
> set postmaster "jdow"
> set no bouncemail
> set no spambounce
> set properties ""
> set daemon 60
> #set logfile fetchmail_el.log
>
> poll mail.dslextreme.com with proto pop3 port 995
>     user 'AA...@ds...', with password '123456does not work'
> ssl, is 'jdow@...' here pass8bits
>     user BBBwith password '123456does not work' ssl,
>     is 'jdow@...' here pass8bits
> poll pop.earthlink.net with proto pop3
> ....
> ===8<---
> Command line is: /usr/bin/fetchmail -d 60 --fetchmailrc
> /home/jdow/.fetchmailrc (Yes, there is a redundancy there.)
>
> Fetchmail feeds off to Postfix which runs spamassassin via procmail.
> It is a working configuration from way back so I elected to perpetuate
> it rather than fix it. {^_-}
>
> This (or an older version of it) has been working for a couple decades
> or more. Along about 2019-Apr-04 it started to try to send an email to
> a rather enigmatic address,
> JkiO@JkiO----------------------.{MUNG]us-west-2.compute.amazonaws.com.
> Old logwatch reports show a few sporadic "Illegal address syntax in
> SMTP command" errors in the Postfix syslog messages. But now I am
> getting them nearly every poll cycle. Nothing is going out because I
> do not use the local Postfix for sending mail. It seems to be an
> unnecessary step in the sending process. I believe I have determined
> it is fetchmail itself that is acquiring the localhost socket to send
> the mail using the audit facility.
>
> What configuration error might I have introduced?
>
> {^_^}   Joanne
>
Hi Joanne, long time no see you on the net.  I hope you two are well. I'm 
so-so, 84 now and turning bionic with plastic eyes and as of January, a 
pacemaker as my own was slowing down into the 30's. Getting dizzy in 
between heartbeats I was.  Drove myself to th ER and told them I was in 
need of a pacemaker. Not a bunch to miss a paycheck, they agreed.

My first question is, when did fetchmail grow sendmail like legs? I've 
never used it for anything but a sucker, feeding procmail as its MTA 
which in turn runs incoming past clamd and spamd.  Still useing the TDE 
version of KMail, which has its own SMTP built in for sending.

The second munged address echo's sure sounds like a dns screw up, have 
you recently switched dns severs?

Take care now girl.

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)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[Fetchmail-users] ssl with dslextreme.com attempts to send a spurious email

[jdow <jd...@ds...>]

I am running up to date Scientific Linix 7.x (Centos). The fetchmail version is 
fetchmail-6.3.24-7.el7.x86_64. Openssl is openssl-1.0.2k-16.el7_6.1.x86_64. The 
.fetchmailrc file looks like:
===8<---
set syslog
set postmaster "jdow"
set no bouncemail
set no spambounce
set properties ""
set daemon 60
#set logfile fetchmail_el.log

poll mail.dslextreme.com with proto pop3 port 995
    user 'AA...@ds...', with password '123456does not work' ssl,
    is 'jdow@...' here pass8bits
    user BBBwith password '123456does not work' ssl,
    is 'jdow@...' here pass8bits
poll pop.earthlink.net with proto pop3
....
===8<---
Command line is: /usr/bin/fetchmail -d 60 --fetchmailrc /home/jdow/.fetchmailrc
(Yes, there is a redundancy there.)

Fetchmail feeds off to Postfix which runs spamassassin via procmail. It is a 
working configuration from way back so I elected to perpetuate it rather than 
fix it. {^_-}

This (or an older version of it) has been working for a couple decades or more.
Along about 2019-Apr-04 it started to try to send an email to a rather enigmatic 
address, JkiO@JkiO----------------------.{MUNG]us-west-2.compute.amazonaws.com. 
Old logwatch reports show a few sporadic "Illegal address syntax in SMTP 
command" errors in the Postfix syslog messages. But now I am getting them nearly 
every poll cycle. Nothing is going out because I do not use the local Postfix 
for sending mail. It seems to be an unnecessary step in the sending process. I 
believe I have determined it is fetchmail itself that is acquiring the localhost 
socket to send the mail using the audit facility.

What configuration error might I have introduced?

{^_^}   Joanne

Re: [Fetchmail-users] fetchmail and JMAP protocol

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

Am 26.03.19 um 06:24 schrieb Ranjan Maitra:
> On Mon, 25 Mar 2019 11:01:30 +0100 Matthias Andree <mat...@gm...> wrote:
>
>> Am 21.03.19 um 02:28 schrieb Ranjan Maitra:
>>> Hi,
>>>
>>> I apologize if this is an ill-formed question, but I am looking for leads. Outlook's protocol that works with OAUTH2 OTP verification seems to come with e-mails downloaded in json format. Poking around brought me to the JMAP protocol. I was wondering if fetchmail can handle it, or if there are some other ways of processing mail extracted in json format (we have successfully obtained ways to get this).
>> Fetchmail supports the documented IETF protocols for mail retrievals,
>> dominantly POP3 and IMAP. No JMAP, no HTTP-/REST-based stuff, no
>> proprietary protocols.
> Thanks, FWIW, JMAP is IETF protocol as per https://github.com/jmapio/jmap and seeks to replace IMAP+SMTP. I do not know much about it, but at least the spec is published on github.
>
> I did not see this as being a proprietary protocol.

That was just an enumeration since other questions often go towards
supporting Microsoft or whoever else's inventions. The MAPI contribution
was a one-shot from a Google Summer of Code that has fallen to bit-rot
even before being integrated to a release, and I don't intend to make
such a mistake again. PWMD, a side feature to many however, shows an
entirely different model, I receive frequent updates.

JMAP isn't an IETF standard or even in RFC form yet, it's in draft stage
and I don't have a single JMAP server that I could use, let alone two
different implementations to test against. Given the current maintenance
capacity for fetchmail it's no good adding moving targets. Ask again if
it's matured to RFC stage, has a sufficient user base, and there are two
different server-side implementations that I can test against without
paying.

Re: [Fetchmail-users] fetchmail and JMAP protocol

[grarpamp <gra...@gm...>]

On 3/26/19, Ranjan Maitra <ma...@em...> wrote:
>> > Outlook's protocol that works with OAUTH2 OTP verification seems
>> > to come with e-mails downloaded in json format. Poking around brought me
>> > to the JMAP protocol. I was wondering if fetchmail can handle it, or if
>> > there are some other ways of processing mail extracted in json format

> JMAP is IETF protocol as per https://github.com/jmapio/jmap
> I did not see this as being a proprietary protocol.

https://jmap.io/


It seems any variety of "mail" protocols, ie general message
push / pull from servers or networks,  usable with
clients of various sorts, could be supported in some tool
where they are initially likely as contributed software modules
to a much more abstracted fetching ie messaging tool,
A few of those modules also being IMAP, POP, ... .
Fetchmail beginnings rooted in historical email
makes it not necessarily such a tool currently.

As with completely abstracting and splitting
out the config concepts of server from account,
protocol, poll functions, etc mentioned before...

There's probably no reason people could not
put together proposals for themselves to do the
work of adding and supporting new or existing open
message protocols into whatever more capable
fetching, and with JMAP even sending, framework
might be created.
Consideration also need given to if 'fetchmail' is a
right base for such an effort.

As to JMAP, some client / server tools seem
to be on an implementation path. On the user
facing services front...

- Timeframe till standard is usably stable and featured?
- Which / who are using it now until then?
- Which / who are declared and or expected to adopt it after?

And what proposals for contributing what JMAP and
related efforts and support into fetchmail are out there?

Re: [Fetchmail-users] fetchmail and JMAP protocol

[Ranjan M. <ma...@em...>]

On Mon, 25 Mar 2019 11:01:30 +0100 Matthias Andree <mat...@gm...> wrote:

> Am 21.03.19 um 02:28 schrieb Ranjan Maitra:
> > Hi,
> >
> > I apologize if this is an ill-formed question, but I am looking for leads. Outlook's protocol that works with OAUTH2 OTP verification seems to come with e-mails downloaded in json format. Poking around brought me to the JMAP protocol. I was wondering if fetchmail can handle it, or if there are some other ways of processing mail extracted in json format (we have successfully obtained ways to get this).
>
> Fetchmail supports the documented IETF protocols for mail retrievals,
> dominantly POP3 and IMAP. No JMAP, no HTTP-/REST-based stuff, no
> proprietary protocols.

Thanks, FWIW, JMAP is IETF protocol as per https://github.com/jmapio/jmap and seeks to replace IMAP+SMTP. I do not know much about it, but at least the spec is published on github.

I did not see this as being a proprietary protocol.

Thanks,
Ranjan
--
Important Notice: This mailbox is ignored: e-mails are set to be deleted on receipt. Please respond to the mailing list if appropriate. For those needing to send personal or professional e-mail, please use appropriate addresses.

Re: [Fetchmail-users] using fetchmail with content extracted from MS Graph API

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

Am 23.03.19 um 16:05 schrieb Ranjan Maitra:
> Hi,
>
> We are able to write python code to get Outlook e-mail downloaded from MS Graph's API. I was looking into whether fetchmail can be made to be used on the stream from a call to this API. If a patch is needed, I would like some advice on where to start in order to see if this is even possible.

No such support exists in fetchmail, nor would I be interested in adding
proprietary protocols. The maintenance overhead is far too high.

Re: [Fetchmail-users] fetchmail and JMAP protocol

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

Am 21.03.19 um 02:28 schrieb Ranjan Maitra:
> Hi,
>
> I apologize if this is an ill-formed question, but I am looking for leads. Outlook's protocol that works with OAUTH2 OTP verification seems to come with e-mails downloaded in json format. Poking around brought me to the JMAP protocol. I was wondering if fetchmail can handle it, or if there are some other ways of processing mail extracted in json format (we have successfully obtained ways to get this).

Fetchmail supports the documented IETF protocols for mail retrievals,
dominantly POP3 and IMAP. No JMAP, no HTTP-/REST-based stuff, no
proprietary protocols.

[Fetchmail-users] using fetchmail with content extracted from MS Graph API

[Ranjan M. <ma...@em...>]

Hi,

We are able to write python code to get Outlook e-mail downloaded from MS Graph's API. I was looking into whether fetchmail can be made to be used on the stream from a call to this API. If a patch is needed, I would like some advice on where to start in order to see if this is even possible.

Many thanks,
Ranjan

[Fetchmail-users] fetchmail and JMAP protocol

[Ranjan M. <ma...@em...>]

Hi,

I apologize if this is an ill-formed question, but I am looking for leads. Outlook's protocol that works with OAUTH2 OTP verification seems to come with e-mails downloaded in json format. Poking around brought me to the JMAP protocol. I was wondering if fetchmail can handle it, or if there are some other ways of processing mail extracted in json format (we have successfully obtained ways to get this).

Many thanks,
Ranjan

Re: [Fetchmail-users] sslproto "TLS1" Causes Encrypted Alert Packets.

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

Am 12.03.19 um 16:26 schrieb Ralph Corderoy:
> Hi,
>
> I've just added another host and user to my .fetchmailrc.
>
>     poll foo via mail.foo.example proto pop3
>     user "ralph@foo.example" is ralph password "letmein"
>         ssl sslcertck sslproto "TLS1" sslcommonname "bar.foo.example"
>
> `fetchmail -c foo' successfully establishes a TLS1.2 connection, but
> after a flurry of encrypted application data, `Encrypted Alert' packets
> are exchanged and the connection closed.  Dropping the -c gives the same
> behaviour.  If I keep -c and change "TLS1" to "SSL23" then it doesn't
> happen

Ralph,

The thing is "TLS1" means "TLS v1.0 and v1.0 only" and will fail if the
server refuses TLSv1.0. TLS1 triggers a call through the
tls1_client_method() constructor to set up internal TLS structures,
whereas SSL23 uses whatever OpenSSL would auto-negotiate
(SSLv23_client_method() - and is a misnomer), with restrictions (such as
forbidding SSLv2 and possibly SSLv3, depending on version). I suspect
that's that.

If not, can you share details on your setup? Fetchmail version or Git
commit hash, SSL library provider and version?
Note that I neither try nor trust LibreSSL, so if you're using that, see
if the issue reproduces with OpenSSL.


I'd think code and TLS-support-quality wise, the tip of the legacy_64
branch from Git should be the best choice if you would bother with
installing the autotools/gettext and other stuff such as flex and GNU
bison.
(You wouldn't need these when installing from a formal tarball.
Auto-generated tarballs from the Git repo don't count, only those I get
from "make distcheck").
> Using s_client(1), I see the server is Dovecot.

Will s_client work if you restrict it to the same server and -tls1?

HTH

Matthias