Menu
▾
▴
Re: [Fetchmail-users] ssl with dslextreme.com attempts to send a spurious email
|
From: jdow <jd...@ds...> - 2019-04-28 23:11:10
|
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. {^_^} |
