fetchmail-users — User questions and discussion

[Fetchmail-users] Installing 6.4.0beta2 on Ubuntu Zesty Beta2

[Chris <cpo...@em...>]

I've been testing 17.04 Gnome in a VM and wanted to get Fetchmail
setup. According to the config.log - https://pastebin.com/42B61zxE I
don't have OpenSSL installed however this seems to show that it is:

sudo apt list OpenSSL
[sudo] password for chris: 
Listing... Done
openssl/zesty,now 1.0.2g-1ubuntu11 amd64 [installed]

My configure command is $ ./configure --with-ssl.

Anyone with ideas? I may not reply immediately since I'll be out of
town tomorrow through sometime Friday.

Chris
-- 
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
20:53:13 up 23:35, 1 user, load average: 3.00, 4.05, 3.23
Description:	Ubuntu 16.04.2 LTS, kernel 4.4.0-71-generic
-- 
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
21:41:33 up 1 day, 23 min, 1 user, load average: 0.26, 0.35, 0.51
Description:	Ubuntu 16.04.2 LTS, kernel 4.4.0-71-generic

Re: [Fetchmail-users] Frontier (Yahoo) OAuth

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

>>> Can anyone list services that require this?
>>
>> Gmail does, but can be disabled.

Then it is not *required*.

If people know of services actually starting to
*refuse* AUTH=PLAIN LOGIN, then the various
OAuth forms might be useful to look into.

>> You can look at Thunderbird code to
>> find out what they do. I don't remember what the dialogue said, though,
>> it pops up rarely. I think it is done in javascript, maybe they have a
>> document on it.

> Guys, of course it is technically doable [... not gonna happen]

I can't see any problem with fetchmail providing a shellout
to the operations, users providing that, patches, whatever.
Especially since I suspect it is not actually dependant on human
brainpower interaction, but I'd have to look further to know that.

Efforts there would also depend on prevalance and impact
of any *required*'s that may exist as above.

> Frontier

If reading right, maybe frontier is farming as proxy out to yahoo as
virtualhost,
so try connecting with PLAIN LOGIN directly to yahoo's imap/pop/submission
servers specifying whatever your "frontier mail" user@dom:pass is. Unless
yahoo has firewalled off their virtual to only frontier's proxy, it should work
and you can bypass frontier as middleman.
Or try logging into 'frontier.yahoo.com' as they say, whatever that is.

What you say 'expires in 2018' could be frontier generating
that app specfic from yahoo on your behalf using your user:pass
to do it until yahoo bans that.

I've really not looked at this so don't read much in me yet.

You probably don't want to put much dependancy on your
ISP provided email, you could move residence where they
do not exist, they could be bought, stop service, etc.
Best is your own portable domain housed with email
literally anywhere on the net for under $25 or so per yr.

Re: [Fetchmail-users] Frontier (Yahoo) OAuth

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

On Wed, 22 Feb 2017, Matthias Andree wrote:

> Find a switch in your account settings that will let you use some more 
> traditional authentication scheme directly, or find a switch they'll 
> perfidiously have mislabelled "allow insecure authentication methods" or 
> such in a similar scary wording (Google and Yahoo provide it and name it 
> so) and set it so you can log in with passwords.

I can't find any switch like that.  The Yahoo "Account Settings" link 
takes me to a Frontier specific page with very few options.  BUT, 
there does appear to be another option....

> Alternatively, perhaps Frontier permit you to set application-specific
> passwords for mail, which might work along the lines laid out in
> <https://johnlane.ie/gmail-fetchmail-is-a-less-secure-app.html>.

THIS ONE.  Thank you for the suggestion and that link.

When I originally saw the "App Password" option on the Frontier page, I 
thought it was somehow related to OAuth. In other words, I thought you had 
to obtain an "App Password" in order to use OAuth.  But I guess that's not 
the case.

The downside to this option (assuming I can get it to work) is it also 
appears to be a temporary solution.  There's a note on the Frontier page 
where I request the "App Password" that says:

   ... this option is subject to expire in 2018.

So, I guess that will help for now, but I'll still need to come up with an 
alternate solution eventually.

And just to clarify.   All I need to do from a fetchmail perspective is 
replace the current entry in my .fetchmailrc:

   ... user 'us...@fr...' there with password 'XXXXXXXXX' ...

with the newly generated "App Password":

   ... user 'us...@fr...' there with password 'APP PASSWORD' ...

Re: [Fetchmail-users] Frontier (Yahoo) OAuth

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

Am 22. Februar 2017 20:20:33 MEZ schrieb "Carlos E. R." <rob...@te...>:
>On 2017-02-22 18:59, grarpamp wrote:
>> On Wed, Feb 22, 2017 at 7:13 AM, Carlos E. R. <> wrote:
>>> How do you prompt the human for response on a daemon?
>
>
>> What exactly are the nature of the prompts... captcha,
>> user / pass?
>> 
>> Can anyone list services that require this?
>
>Gmail does, but can be disabled. You can look at Thunderbird code to
>find out what they do. I don't remember what the dialogue said, though,
>it pops up rarely. I think it is done in javascript, maybe they have a
>document on it.
>
>
>IMHO, if they want to secure email, then they should use certificates.
>
>-- 
>Cheers / Saludos,
>
>		Carlos E. R.
>
>  (from 42.2 x86_64 "Malachite" (Minas Tirith))

Guys, of course it is technically doable, and you can discuss the 'how' all you want, but it is just not gonna happen for fetchmail, my decision stands.

Re: [Fetchmail-users] Frontier (Yahoo) OAuth

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

On 2017-02-22 18:59, grarpamp wrote:
> On Wed, Feb 22, 2017 at 7:13 AM, Carlos E. R. <> wrote:
>> How do you prompt the human for response on a daemon?


> What exactly are the nature of the prompts... captcha,
> user / pass?
> 
> Can anyone list services that require this?

Gmail does, but can be disabled. You can look at Thunderbird code to
find out what they do. I don't remember what the dialogue said, though,
it pops up rarely. I think it is done in javascript, maybe they have a
document on it.


IMHO, if they want to secure email, then they should use certificates.

-- 
Cheers / Saludos,

		Carlos E. R.

  (from 42.2 x86_64 "Malachite" (Minas Tirith))

Re: [Fetchmail-users] Frontier (Yahoo) OAuth

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

On Wed, Feb 22, 2017 at 7:13 AM, Carlos E. R.
<rob...@te...> wrote:
> How do you prompt the human for response on a daemon?

Having spent only a few minutes looking at rfc,
did I miss that / is it a required element of all
implementations? What section of what doc
is it in?

> OAUTH support means asking the user for some response in a web dialog.
> Once that is done, it will work silently for several/many times, till
> one day it fails and again it prompts the user.
>
> That's how it works in Thunderbird.
>
> I don't see a daemon like fetchmail doing all that. It doesn't have
> access to X, for starters...

Well if a response is required that a script
cannot see and calculate, then some more
layers would need done. Or at least import
the resulting tokens from your own gui response
into fetchmail... like stealing cookies from browser
and loading them into wget.

What exactly are the nature of the prompts... captcha,
user / pass?

Can anyone list services that require this?

Re: [Fetchmail-users] Frontier (Yahoo) OAuth

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

On 2017-02-22 09:33, grarpamp wrote:
>> https://sourceforge.net/p/fetchmail/mailman/message/34628292/
>>>    https://frontier.com/helpcenter/categories/internet/email/email-security-upgrade
>> https://johnlane.ie/gmail-fetchmail-is-a-less-secure-app.html
> 
> OAuth2
> https://tools.ietf.org/html/rfc6749
> OAuth2 Bearer
> https://tools.ietf.org/html/rfc6750
> SASL-IR
> http://tools.ietf.org/html/rfc4959
> https://developers.google.com/gmail/xoauth2_protocol
> 
> If there's no suitable library [search / github?] it should be possible
> to pass the preliminary bits out to a user program that returns
> the needed token bits. Probably with env vars carrying
> the name of a just then created mkstemp(3) file for the
> return purpose. Vars for user / pass / authtype / server...
> whatever fetchmail has for that particular session / connection.
> Some users could write program scripts for contrib.
> It's uglier than a library, and leaves a lot to the user,
> but seems doable even in /bin/sh, wget, openssl base64,
> etc... common system tools.

How do you prompt the human for response on a daemon?

OAUTH support means asking the user for some response in a web dialog.
Once that is done, it will work silently for several/many times, till
one day it fails and again it prompts the user.

That's how it works in Thunderbird.

I don't see a daemon like fetchmail doing all that. It doesn't have
access to X, for starters...

-- 
Cheers / Saludos,

		Carlos E. R.

  (from 42.2 x86_64 "Malachite" (Minas Tirith))

Re: [Fetchmail-users] Frontier (Yahoo) OAuth

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

> https://sourceforge.net/p/fetchmail/mailman/message/34628292/
>>    https://frontier.com/helpcenter/categories/internet/email/email-security-upgrade
> https://johnlane.ie/gmail-fetchmail-is-a-less-secure-app.html

OAuth2
https://tools.ietf.org/html/rfc6749
OAuth2 Bearer
https://tools.ietf.org/html/rfc6750
SASL-IR
http://tools.ietf.org/html/rfc4959
https://developers.google.com/gmail/xoauth2_protocol

If there's no suitable library [search / github?] it should be possible
to pass the preliminary bits out to a user program that returns
the needed token bits. Probably with env vars carrying
the name of a just then created mkstemp(3) file for the
return purpose. Vars for user / pass / authtype / server...
whatever fetchmail has for that particular session / connection.
Some users could write program scripts for contrib.
It's uglier than a library, and leaves a lot to the user,
but seems doable even in /bin/sh, wget, openssl base64,
etc... common system tools.

Re: [Fetchmail-users] Frontier (Yahoo) OAuth

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

Am 21.02.2017 um 23:36 schrieb Hans Carlson:
> Is there any chance fetchmail supports OAuth now or in the very (very) 
> near future?

Not the faintest.
https://sourceforge.net/p/fetchmail/mailman/message/34628292/

> Frontier, which uses Yahoo mail is apparently disabling all 
> authentication methods except OAuth (presumably OAuth2).  At least that 
> appears to be the case based on this message I received:
>
>    https://frontier.com/helpcenter/categories/internet/email/email-security-upgrade
>
> I've been using fetchmail for more years than I can remember and I'd 
> prefer to keep using it, but this message from Frontier/Yahoo appears to 
> indicate I'll no longer be able to use fetchmail if it doesn't support 
> OAuth.
Find a switch in your account settings that will let you use some more
traditional authentication scheme directly,
or find a switch they'll perfidiously have mislabelled "allow insecure
authentication methods" or such in a similar scary wording (Google and
Yahoo provide it and name it so) and set it so you can log in with
passwords.

Alternatively, perhaps Frontier permit you to set application-specific
passwords for mail, which might work along the lines laid out in
<https://johnlane.ie/gmail-fetchmail-is-a-less-secure-app.html>.

If there is no such switch, and you lose access to your mail, decide for
yourself on the consequences. Might have to do with changing e-mail
provider, or access provider.

[Fetchmail-users] Frontier (Yahoo) OAuth

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

Is there any chance fetchmail supports OAuth now or in the very (very) 
near future?

Frontier, which uses Yahoo mail is apparently disabling all 
authentication methods except OAuth (presumably OAuth2).  At least that 
appears to be the case based on this message I received:

   https://frontier.com/helpcenter/categories/internet/email/email-security-upgrade

I've been using fetchmail for more years than I can remember and I'd 
prefer to keep using it, but this message from Frontier/Yahoo appears to 
indicate I'll no longer be able to use fetchmail if it doesn't support 
OAuth.

Re: [Fetchmail-users] IMAP< A0002 NO LOGIN failed

[Axel J. <axe...@tu...>]

I want to report back to this list about the problem I had with
accessing my account via fetchmail and IMAP.

It had nothing to do with fetchmail, and after many emails and countless
attempts to login to the mail server with different username
combinations I received this email from the KTH IT Support today:

>>>>> From KTH IT Support:
     You should not use any other settings then in the manual.
     ...
     When I think of it we have from time to time had problem with one or 2 users on mailboxserver level.
     What we then have done is to restart the imap service on a specific server. 
     I have tried this on the server where your mailbox is placed exdb06.
     I hope this will work.

And it worked. So restarting the server solved the issue.

Thanks to all who have tried to help me!

--Axel


>>>>> On Fri, 10 Feb 2017 12:21:54 -0500, grarpamp <gra...@gm...> said:

    > On Fri, Feb 10, 2017 at 5:32 AM, Axel Jantsch <axe...@tu...> wrote:
    >> So somehow I use the wrong username or password. I suspect the username
    >> because the error message says
    >> 
    >>>> fetchmail: Authorization failure on ax...@we...
    >> 
    >> but my email address and account is really ax...@kt...
    >> 
    >> But I do not know how I could use that name because then I get the error
    >> for ax...@kt...@webmail.kth.se
    >> 
    >> Maybe I should use some Exchange specific format like
    >> ug.kth.se\axel  ???
    >> 
    >> I tried that but it still appends @webmail.kth.se with the corresponding
    >> error message.
    >> 
    >> Is there a way to have fetchmail use "ax...@kt..." ?

    >> > https://www.kth.se/en/student/kth-it-support/work-online/email/settings-and-config/installningar-for-thunderbird-1.282051
    >> > https://www.kth.se/en/student/kth-it-support/work-online/email/settings-and-config/imap-installningar-for-kth-e-post-1.3887
    >> >> fetchmail: IMAP< * CAPABILITY IMAP4 IMAP4rev1 AUTH=PLAIN

    > First, test this by reading the RFC spec for IMAP4 auth, which people
    > have posted links to or search, then login to the mail server
    > manually using openssl / gnutls command, to confirm your
    > username and password are exactly what you think they are.

    > openssl s_client -connect server:port [-starttls imap]

    >> >> fetchmail: IMAP> A0002 LOGIN "axel" *
    >> >> fetchmail: IMAP< A0002 NO LOGIN failed.

    > It is extremely unlikely these days that your usename is not
    > required by the server to be qualified with the @fqdn. Fix that and retry.


    >> >> my .fetchmailrc file looks like this:
    >> >>
    >> >> poll webmail.kth.se protocol imap
    >> >> port 993
    >> >> authenticate password
    >> >> user 'axel'
    >> >> password 'topsecret'
    >> >> #     ssl sslproto 'auto'
    >> >> ssl sslproto tls1 sslcertck
    >> >> mda "/usr/bin/procmail -f sendmail"

    > Break all these multiple config statements into one per line.
    > 'user' is 'username' then lines up nicely with 'password'.
    > 'poll' is nothing more than a nop config stanza label string,
    > when you add a proper 'via' statement. I've talked / ticketed
    > about this regarding fetchmail-7 full config flexibility.

    > Today, you can have nonideal part of it with 6, and I do have,
    >  poll blah2
    >  via <fqdn9>
    >  username <user3@fqdn7>
    > and then fetchmail "blah2".

    > I say all this because your unqualified 'axel' username is being appended
    > by silly 'poll' mashup of concept to submit LOGIN 'axel@poll'.

    > I'm guessing kth changed to require @fqdn to support virtuals,
    > so you would have to test and change your config to match.

    >> >> My email address there is ax...@kt..., but the IMAP server is webmail.kth.se

    > ------------------------------------------------------------------------------
    > Check out the vibrant tech community on one of the world's most
    > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
    > _______________________________________________
    > Fetchmail-users mailing list
    > Fet...@li...
    > https://lists.sourceforge.net/lists/listinfo/fetchmail-users


-- 
Axel Jantsch, Prof. of Systems on Chip
TU Wien
Gusshausstrasse 27-29/384, 1040 Vienna, Austria
Phone: +43 1 58801 38415
Email: axe...@tu...
Web: www.ict.tuwien.ac.at

Re: [Fetchmail-users] Query status=3 (AUTHFAIL)

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

Am 20.02.2017 um 20:47 schrieb co...@sh...:
> My problem is i cannot receive emails.I have checked the mail.log have
> error:
>  
>
> Warning: the connection is insecure, continuing anyways. (Better use
> --sslcertck!)
> Feb 20 17:41:41 server4 fetchmail[3020]: Authorization failure on
> test@MYdomain@Mydomain
> Feb 20 17:41:41 server4 fetchmail[3020]: For help, see
> <http://www.fetchmail.info/fetchmail-FAQ.html#R15>
> http://www.fetchmail.info/fetchmail-FAQ.html#R15
> Feb 20 17:41:42 server4 fetchmail[3020]: Query status=3 (AUTHFAIL)
>
> The fetchmail.rc content is:
[snip] It certainly is not. Of course you can't show passwords here, but
this was made up beyond all recognition.

Also see <http://www.fetchmail.info/fetchmail-FAQ.html#G3>

> Can anyone help Please?

Be sure not to mistype the password with respect to case, or
similarly-looking characters such as 0 o O, or 1 I l.

Then check if you need to login with your full e-mail address or just
the login.
Check your provider's help pages, or contact their support to ask.

[Fetchmail-users] Query status=3 (AUTHFAIL)

[<co...@sh...>]

My problem is i cannot receive emails.I have checked the mail.log have
error:
 

Warning: the connection is insecure, continuing anyways. (Better use
--sslcertck!)
Feb 20 17:41:41 server4 fetchmail[3020]: Authorization failure on
test@MYdomain@Mydomain
Feb 20 17:41:41 server4 fetchmail[3020]: For help, see
<http://www.fetchmail.info/fetchmail-FAQ.html#R15>
http://www.fetchmail.info/fetchmail-FAQ.html#R15
Feb 20 17:41:42 server4 fetchmail[3020]: Query status=3 (AUTHFAIL)

The fetchmail.rc content is:

poll mydomain proto imap  port 993:
   user myemail, with password 'password', is Myemail here ssl
dropdelivered;
poll mydomin proto imap  port 993:
   user test email, with password 'password', is myemail here ssl
dropdelivered;

 

Can anyone help Please?

Re: [Fetchmail-users] sslfingerprint: needs to match any of multiple listed fingerprints

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

Am 20.02.2017 um 20:49 schrieb grarpamp:
>
> I'm not familiar with use of 23 for that in sysexits(3) or intro(2),
> of course people often use locally defined codes as relavant to them.
23 was just an arbitrarily selected prime number without my knowing it
from any sysexits.h that I had seen.
>> Only their names suck. --sslcert vs. --sslcertfile? Uh. Not easily
>> changed unless you want to have duplicate names for the same option for
>> compatibility.
> I don't mind breaking backward compatibility in order to move
> forward with something better.

You don't, and breaking the many secondary crap literature that explains
in lengths how to extract the server's certificate and trust it when one
could instead just look at -v output to get the sslfingerprint might
have some value, but it's a radical step.

Re: [Fetchmail-users] sslfingerprint: needs to match any of multiple listed fingerprints

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

On Mon, Feb 20, 2017 at 3:40 AM, Matthias Andree <mat...@gm...> wrote:

> I will not support "old" libraries that have gone out of their
> respective vendor's support (the 6.4.x branch refuses to build against

I wouldn't either, it just holds you back. Though I meant 'designs / api
of old libraries' can be hard to deal with.

> as long as OpenSSL is alive.

As long as any particular library is leading in use, well maintained,
etc, and expected to continue that way. LibreSSL hasn't been
around long enough compared to others to establish that.
The OpenBSD spinoff projects are interesting though...
smtp, bgp, ntp, ssl, ssh, ike, mandoc, etc.

> https://blog.cloudflare.com/ietf-hackathon-getting-tls-1-3-working-in-the-browser-2/

I see, ok.

https://github.com/bifurcation/mint
https://tls13.cloudflare.com/

> https://www.wolfssl.com/wolfSSL/Docs-wolfssl-changelog.html

Looks like it's just a WIP at the moment...
https://github.com/wolfSSL/wolfssl/pull/661

> value, 0 "OK", 23 for "REJECT", anything else for "ERROR=DUNNO", or
> possibly sysexits.

I'm not familiar with use of 23 for that in sysexits(3) or intro(2),
of course people often use locally defined codes as relavant to them.

> Only their names suck. --sslcert vs. --sslcertfile? Uh. Not easily
> changed unless you want to have duplicate names for the same option for
> compatibility.

I don't mind breaking backward compatibility in order to move
forward with something better.

Re: [Fetchmail-users] sslfingerprint: needs to match any of multiple listed fingerprints

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

Am 20.02.2017 um 06:36 schrieb grarpamp:
> On Sun, Feb 19, 2017 at 8:31 PM, Matthias Andree <mat...@gm...> wrote:
> It's rather having the TLS 1.3 bits in place on the assumption that
>> OpenSSL's API remains in line
>> Am 19.02.2017 um 21:45 schrieb grarpamp:
> Don't know, maybe they will adopt some reform notions
> from libressl. Old libraries can be hard to deal with.

I will not support "old" libraries that have gone out of their
respective vendor's support (the 6.4.x branch refuses to build against
OpenSSL 1.0.1), and I'm not sure what level of "support" I will provide
to LibreSSL either - the former is a matter for the paid backporters of
enterprise distros, not for spare-time projects, and LibreSSL's
appearance was good to get some pressure on and funding for the OpenSSL
project, but AFAICS it's currently causing more pain than what it's
worth because it misrepresents the OpenSSL API level in its header files
and needs explicit LibreSSL checks. I will not guarantee LibreSSL
compatibility as long as OpenSSL is alive.

>> I can negotiate TLS v1.3 connections to a web server, but am not aware of
>> any IMAP or POP3 server that talks TLSv1.3 yet.
> Unlikely in production. There's always './openssl s_server' to
> just check the connection. Maybe ssllabs has some other tests.

That just not useful because it connects a developer OpenSSL library to
itself. It would have to be another major software on the server end
(GnuTLS, Mozilla NSS) to be useful, and that's why I've tested talking
to a cloudflare web server. ->
https://blog.cloudflare.com/ietf-hackathon-getting-tls-1-3-working-in-the-browser-2/amp/

> At least on this page, WolfSSL claims draft 1.3 support...
> https://en.wikipedia.org/wiki/Transport_Layer_Security
>
> So servers should be coming before long.

Nothing on https://www.wolfssl.com/wolfSSL/Docs-wolfssl-changelog.html
though.

>
>>> Then you have the cert observatory projects.
>> None of which is used by fetchmail, and if I need to implement or link a
>> web browser to fetch that information, (or to log in anywhere, OAuth was
>> proposed but servers a different purpose), it's rather unlikely to happen.
> Those services are too new and changing to bother implementing
> or linking anything.
> But as with 'mda' option, maybe shelling out via some new
> 'sslfpcheck' option that passes the fingerprint out environment
> and accepts exit of 0 or 1 back. That way users can do
> whatever they want with it.

Now there's a thought worth consideration, thanks for the idea, I'll
roll it forth and back a bit. Only it might need a tri-state return
value, 0 "OK", 23 for "REJECT", anything else for "ERROR=DUNNO", or
possibly sysexits.

>> directive in the manual page, fixed in Git (but upload to sourceforge
>> https://gitlab.com/fetchmail/fetchmail/commits/legacy_64
> You've had the cool options more than any other fetching project
> out there so no worries, I know they're there :)

Only their names suck. --sslcert vs. --sslcertfile? Uh. Not easily
changed unless you want to have duplicate names for the same option for
compatibility.

Re: [Fetchmail-users] sslfingerprint: needs to match any of multiple listed fingerprints

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

On Sun, Feb 19, 2017 at 8:31 PM, Matthias Andree <mat...@gm...> wrote:
> Am 19.02.2017 um 21:45 schrieb grarpamp:

> It's rather having the TLS 1.3 bits in place on the assumption that
> OpenSSL's API remains in line

Don't know, maybe they will adopt some reform notions
from libressl. Old libraries can be hard to deal with.

> I can negotiate TLS v1.3 connections to a web server, but am not aware of
> any IMAP or POP3 server that talks TLSv1.3 yet.

Unlikely in production. There's always './openssl s_server' to
just check the connection. Maybe ssllabs has some other tests.

At least on this page, WolfSSL claims draft 1.3 support...
https://en.wikipedia.org/wiki/Transport_Layer_Security

So servers should be coming before long.

> So bottom line it's TOFU

After rejecting CA's, yes the world is mostly tofu. Though I give
some additional 'trust' if the org documents the cert on a server
separate from the service, and the org seems to doing most
other things 'right'.

>> Then you have the cert observatory projects.

> None of which is used by fetchmail, and if I need to implement or link a
> web browser to fetch that information, (or to log in anywhere, OAuth was
> proposed but servers a different purpose), it's rather unlikely to happen.

Those services are too new and changing to bother implementing
or linking anything.
But as with 'mda' option, maybe shelling out via some new
'sslfpcheck' option that passes the fingerprint out environment
and accepts exit of 0 or 1 back. That way users can do
whatever they want with it.

> directive in the manual page, fixed in Git (but upload to sourceforge
> https://gitlab.com/fetchmail/fetchmail/commits/legacy_64

You've had the cool options more than any other fetching project
out there so no worries, I know they're there :)

Re: [Fetchmail-users] sslfingerprint: needs to match any of multiple listed fingerprints

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

Am 19.02.2017 um 21:45 schrieb grarpamp:
> On Sun, Feb 19, 2017 at 2:36 PM, Matthias Andree <mat...@gm...> wrote:
>> TLS1.2 into a formal release that won't hicc-up the day TLS1.3 appears,
> If the client is speaking 1.2 to a 1.3 capable server that
> still offers 1.2 (or below), is any hiccup expected to happen?
It's rather having the TLS 1.3 bits in place on the assumption that
OpenSSL's API remains in line, and I have written code that works with
OpenSSL's Git master branch as of a few days ago. With what I have, I
can negotiate TLS v1.3 connections to a web server, but am not aware of
any IMAP or POP3 server that talks TLSv1.3 yet.

>> authoritative. Are your ISP faxing their finger prints to you?
> Out of band could happen in relatively unchanging deployments,
> perhaps corporate environments. Also rare would be pgp
> signed cert statements that web of trust back to you.
> I've seen some services that post them on a
> webserver for download, like the CA's do with their roots.
> It's not exactly out of band, but is better than only
> receiving them via each TLS connection itself.
So bottom line it's TOFU = trust-on-first-use, possibly aided by
certificate verification, your manual implementation of certificate
pinning.
> Then you have the cert observatory projects.
None of which is used by fetchmail, and if I need to implement or link a
web browser to fetch that information, (or to log in anywhere, OAuth was
proposed but servers a different purpose), it's rather unlikely to happen.

> Google for example is notorious for server cert churn,
> under three months. However it has it's own long term
> intermediate CA signed by a root, and that int-CA is
> reasonably verifiable. Users could just trust those
> int-CA fingerprints and let all the server certs they sign
> pass as ok, which is what browsers do.
> Don't know if fetchmail supports that mode of checking
> but it would be useful (in sslfingerprint and in cert file).
Fingerprint checking in fetchmail only applies to the server
certificate, not to the intermediate signers' certificates.

You can use fetchmail with an isolated "trusted roots" store (see the
manual page, --sslcertfile, --sslcertpath) if you want to limit what
signers to trust, so that you could only put the intermediate CA if you
don't want to trust the root, and only deal with it as that expires,
usually on the scale of years. The latest 6.4.0 betas may "hide" the
sslcertfile documentation under --nosslcertck due to a forgotten .TP
directive in the manual page, fixed in Git (but upload to sourceforge
doesn't work currently, see Gitlab
<https://gitlab.com/fetchmail/fetchmail/commits/legacy_64> instead).

Re: [Fetchmail-users] sslfingerprint: needs to match any of multiple listed fingerprints

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

On Sun, Feb 19, 2017 at 2:36 PM, Matthias Andree <mat...@gm...> wrote:
> TLS1.2 into a formal release that won't hicc-up the day TLS1.3 appears,

If the client is speaking 1.2 to a 1.3 capable server that
still offers 1.2 (or below), is any hiccup expected to happen?

> authoritative. Are your ISP faxing their finger prints to you?

Out of band could happen in relatively unchanging deployments,
perhaps corporate environments. Also rare would be pgp
signed cert statements that web of trust back to you.
I've seen some services that post them on a
webserver for download, like the CA's do with their roots.
It's not exactly out of band, but is better than only
receiving them via each TLS connection itself.
Then you have the cert observatory projects.

Google for example is notorious for server cert churn,
under three months. However it has it's own long term
intermediate CA signed by a root, and that int-CA is
reasonably verifiable. Users could just trust those
int-CA fingerprints and let all the server certs they sign
pass as ok, which is what browsers do.
Don't know if fetchmail supports that mode of checking
but it would be useful (in sslfingerprint and in cert file).

https://pki.google.com/GIAG2.crt

Re: [Fetchmail-users] sslfingerprint: needs to match any of multiple listed fingerprints

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

Am 15.02.2017 um 17:22 schrieb grarpamp:
> Due to providers not rolling out certs simultaneously
> across their entire infrastructure, and providers sometimes
> having different certs depending on datacenter / admin / country...
> sslfingerprint scheme needs to match any of multiple listed fingerprints
> More on the subject is probably in my .rc and TLS certificate
> tickets / posts somewhere.
I am aware of your request, I just haven't written the code yet.
Certificate verification is there today, only we need to see to getting
TLS1.2 into a formal release that won't hicc-up the day TLS1.3 appears,
and I'd like to know how you're certain that the fingerprint you see on
your end is authoritative. Are your ISP faxing their finger prints to you?

Re: [Fetchmail-users] Fetchmail logrotate script works once then fails next run

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

On Thu, Feb 16, 2017 at 10:35:12PM +0100, Matthias Andree wrote:
> Am 16.02.2017 um 14:45 schrieb Chris:
> >> On Sun, 2017-02-12 at 16:25 +0100, Matthias Andree wrote:
> >>> while [ -e /path/to/fetchmail.pid ] ; do sleep 1 ; done
> > Adding that one line to the script got it to run perfectly Matthias,
> > thanks so much for the help
> 
> Hi Chris,
> 
> good to know that, but you need to keep an eye on it if you're using it
> as is.
> If the previous fetchmail instance *crashed* and left the fetchmail.pid
> file behind, this loop will wait forever without starting fetchmail anew.

So this looks more and more like I should brush up my stalepid
tool from years ago and let people actually know about it, doesn't it...

Chris, could you take a look at https://devel.ringlet.net/sysutils/stalepid/
and see if this utility will help you?  Something like:

  stalepid /path/to/fetchmail.pid fetchmail

...should be able to do the trick; afterwards, if fetchmail.pid no longer
exists, this means that it was stale.

Of course, if stalepid fails to work for you for some reason, please do not
hesitate to let me know!

G'luck,
Peter

-- 
Peter Pentchev  ro...@ri... ro...@Fr... pp...@st...
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

Re: [Fetchmail-users] Fetchmail logrotate script works once then fails next run

[Chris <cpo...@em...>]

On Thu, 2017-02-16 at 22:35 +0100, Matthias Andree wrote:
> Am 16.02.2017 um 14:45 schrieb Chris:
> > 
> > > 
> > > On Sun, 2017-02-12 at 16:25 +0100, Matthias Andree wrote:
> > > > 
> > > > while [ -e /path/to/fetchmail.pid ] ; do sleep 1 ; done
> > Adding that one line to the script got it to run perfectly
> > Matthias,
> > thanks so much for the help
> 
> Hi Chris,
> 
> good to know that, but you need to keep an eye on it if you're using
> it
> as is.
> If the previous fetchmail instance *crashed* and left the
> fetchmail.pid
> file behind, this loop will wait forever without starting fetchmail
> anew.
> 
> Cheers,
> Matthias
> 
Ah, good to know Matthias, the cronjob runs at midnight but I check in
the morning to make sure the new log is being written to. 
-- 
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
16:21:08 up 13 days, 8:19, 2 users, load average: 1.04, 0.81, 0.80
Description:	Ubuntu 16.04.2 LTS, kernel 4.4.0-62-generic

Re: [Fetchmail-users] Fetchmail logrotate script works once then fails next run

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

Am 16.02.2017 um 14:45 schrieb Chris:
>> On Sun, 2017-02-12 at 16:25 +0100, Matthias Andree wrote:
>>> while [ -e /path/to/fetchmail.pid ] ; do sleep 1 ; done
> Adding that one line to the script got it to run perfectly Matthias,
> thanks so much for the help

Hi Chris,

good to know that, but you need to keep an eye on it if you're using it
as is.
If the previous fetchmail instance *crashed* and left the fetchmail.pid
file behind, this loop will wait forever without starting fetchmail anew.

Cheers,
Matthias

Re: [Fetchmail-users] Fetchmail logrotate script works once then fails next run

[Chris <cpo...@em...>]

On Sun, 2017-02-12 at 11:03 -0600, Chris wrote:
> On Sun, 2017-02-12 at 16:25 +0100, Matthias Andree wrote:
> > 
> > Am 12.02.2017 um 15:56 schrieb Chris:
> > > 
> > > 
> > >         postrotate
> > >         /usr/local/bin/fetchmail --quit
> > >         /usr/local/bin/fetchmail -v --nokeep --nosyslog --logfile
> > > /home/chris/fetchmaillog --uidl -m procmail
> > >         endscript
> > > [...]
> > > running postrotate script
> > > fetchmail: background fetchmail at 3786 killed.
> > > fetchmail: can't accept options while a background fetchmail is
> > > running.
> > 
> > > 
> > > 
> > > I don't understand why it worked the first time but not the 2nd
> > > as
> > > nothing was changed in between.
> > 
> > Hi Chris,
> > 
> > Looks like a race between the three instances of fetchmail
> > involved:
> > 
> > 1. you have 3786
> > 2. postrotate starts fetchmail -q, which just signals 3786 to exit,
> > but
> > does not wait for its exit (because it's not its child that
> > wouldn't
> > be
> > 100% safe anyhow)
> > 3. postrotate immediately starts a new fetchmail, which stumbles
> > over
> > the still existing instance that's still cleaning up.
> > 
> > It'd probably be good to wait until the prior instance has really
> > quit
> > before starting the next one, like so (adjust the pid file's path):
> > 
> > /usr/local/bin/fetchmail --quit
> > 
> > while [ -e /path/to/fetchmail.pid ] ; do sleep 1 ; done
> > 
> > /usr/local/bin/fetchmail -v --nokeep --nosyslog --logfile
> > /home/chris/fetchmaillog --uidl -m procmail
> > 
> > 
> > and possibly adding a counter so it does not wait too long or
> > otherwise
> > use SIGKILL to get rid of the old instance.
> > 
> > Neither will be 100% bullet-proof unless you defer to a service
> > supervisor such as runit, upstart, systemd, or thereabouts, and
> > just
> > request a fetchmail restart from such a supervisor in your
> > postrotate
> > script.
> > 
> > HTH
> > Matthias
> > 
> Thanks Matthias, I'm sure it will. I'll make the changes and give it
> some test runs until I get it right. Appreciate the assistance.
> 
Adding that one line to the script got it to run perfectly Matthias,
thanks so much for the help

Chris

-- 
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
07:43:27 up 12 days, 23:41, 2 users, load average: 2.88, 1.87, 1.11
Description:	Ubuntu 16.04.2 LTS, kernel 4.4.0-62-generic

[Fetchmail-users] sslfingerprint: needs to match any of multiple listed fingerprints

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

Due to providers not rolling out certs simultaneously
across their entire infrastructure, and providers sometimes
having different certs depending on datacenter / admin / country...
sslfingerprint scheme needs to match any of multiple listed fingerprints
More on the subject is probably in my .rc and TLS certificate
tickets / posts somewhere.