| 
     
      
      
      From: Hans C. <fo...@gm...> - 2017-02-21 22:36:28
       
   | 
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.  | 
| 
     
      
      
      From: Matthias A. <mat...@gm...> - 2017-02-22 01:45:00
       
   | 
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.  | 
| 
     
      
      
      From: Hans C. <fo...@gm...> - 2017-02-22 20:26:49
       
   | 
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' ...  | 
| 
     
      
      
      From: grarpamp <gra...@gm...> - 2017-02-22 08:34:44
       
   | 
> 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.  | 
| 
     
      
      
      From: Carlos E. R. <rob...@te...> - 2017-02-22 12:14:07
       
  
        
          
            Attachments:
            signature.asc
          
        
       
     | 
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))  | 
| 
     
      
      
      From: grarpamp <gra...@gm...> - 2017-02-22 18:00:34
       
   | 
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?  | 
| 
     
      
      
      From: Carlos E. R. <rob...@te...> - 2017-02-22 19:20:56
       
  
        
          
            Attachments:
            signature.asc
          
        
       
     | 
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))  | 
| 
     
      
      
      From: Matthias A. <mat...@gm...> - 2017-02-22 19:41:00
       
   | 
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.  | 
| 
     
      
      
      From: grarpamp <gra...@gm...> - 2017-02-22 23:22:23
       
   | 
>>> 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.  |