Re: webmail and email from command line

2019-08-20 Thread loredana
On Wed, Aug 14, 2019 at 4:24 PM loredana  wrote:
>
> Greetings,
>
> I posted the following message to debian-accessibility and I post it
> again as suggested.

My mistake.
I can't cope with this threading hijacking. As I said in my first
post, I do have a serious problem I am trying to solve.

I will browse the mailing list for a while, just in case somebody out
there wants to help and I will be back (to debian-accessibility) once
I find a working solution.

For the time being, I need to give to my mailbox a well deserved break.

Thanks again to those who helped.

Bye,
Loredana

"A chi piu' sa, piu' perder tempo spiace" - Dante Alighieri



Re: webmail and email from command line

2019-08-19 Thread tomas
On Mon, Aug 19, 2019 at 09:01:02PM +0100, Joe wrote:
> On Mon, 19 Aug 2019 17:19:58 +0200
>  wrote:
> 
> 
> > 
> > So for Mr. Hardt, Kerberos doesn't exist. Or he's talking HTTP context
> > only.
> > 
> 
> MS has used Active Directory in some form or other since Win2000, and
> AD is basically Kerberos plus LDAP. An AD 'domain' is basically a realm.
> 
> So yes, all their technical employees know about it.

There was some sarcasm in my remark ;-)

Cheers
-- t


signature.asc
Description: Digital signature


Re: webmail and email from command line

2019-08-19 Thread Joe
On Mon, 19 Aug 2019 17:19:58 +0200
 wrote:


> 
> So for Mr. Hardt, Kerberos doesn't exist. Or he's talking HTTP context
> only.
> 

MS has used Active Directory in some form or other since Win2000, and
AD is basically Kerberos plus LDAP. An AD 'domain' is basically a realm.

So yes, all their technical employees know about it.

-- 
Joe



Re: webmail and email from command line

2019-08-19 Thread Joe
On Mon, 19 Aug 2019 14:20:29 -0400
Celejar  wrote:

> On Mon, 19 Aug 2019 19:33:55 +0200
> Alessandro Vesely  wrote:
> 
> > On Mon 19/Aug/2019 18:05:57 +0200 Celejar wrote:  
> > > On Mon, 19 Aug 2019 17:21:40 +0200
> > >  wrote:
> > >   
> > >> On Mon, Aug 19, 2019 at 10:06:33AM -0400, Celejar wrote:
> > >>
> > >> [...]
> > >>  
> > >>> I'd love to run my own mail stack, and I think I could handle
> > >>> the software deployment reasonably well, but from everything
> > >>> I've read, the headaches required to make sure that major mail
> > >>> operators will actually accept my mail are more than I have
> > >>> time or patience for:  
> > >>
> > >> It's not /that/ bad. I'm doing it myself, and I'm a C programmer.
> > >> As a sysad I'm a catastrophe :-)  
> > > 
> > > As I've explained, I'm not scared of the basic software
> > > configuration and deployment. I have no patience, however, for
> > > constant monitoring to make sure I stay off blacklists, and
> > > dealing with all sorts of unspecified rules and conditions
> > > established by various organizations for them to accept my mail.  
> > 
> > 
> > The most difficult thing is obtaining an suitable Internet
> > connection.  
> 
> Quite so.

People in the land that invented the Internet often have remarkably
little choice in terms of Internet connection. Many people have only one
option. There are at least three ISPs in the UK which have 'good' IP
addresses and keep them that way.

-- 
Joe



Re: webmail and email from command line

2019-08-19 Thread Celejar
On Mon, 19 Aug 2019 19:33:55 +0200
Alessandro Vesely  wrote:

> On Mon 19/Aug/2019 18:05:57 +0200 Celejar wrote:
> > On Mon, 19 Aug 2019 17:21:40 +0200
> >  wrote:
> > 
> >> On Mon, Aug 19, 2019 at 10:06:33AM -0400, Celejar wrote:
> >>
> >> [...]
> >>
> >>> I'd love to run my own mail stack, and I think I could handle the
> >>> software deployment reasonably well, but from everything I've read,
> >>> the headaches required to make sure that major mail operators will
> >>> actually accept my mail are more than I have time or patience for:
> >>
> >> It's not /that/ bad. I'm doing it myself, and I'm a C programmer.
> >> As a sysad I'm a catastrophe :-)
> > 
> > As I've explained, I'm not scared of the basic software configuration
> > and deployment. I have no patience, however, for constant monitoring to
> > make sure I stay off blacklists, and dealing with all sorts of
> > unspecified rules and conditions established by various organizations
> > for them to accept my mail.
> 
> 
> The most difficult thing is obtaining an suitable Internet connection.

Quite so.

Celejar



Re: webmail and email from command line

2019-08-19 Thread Alessandro Vesely
On Mon 19/Aug/2019 18:05:57 +0200 Celejar wrote:
> On Mon, 19 Aug 2019 17:21:40 +0200
>  wrote:
> 
>> On Mon, Aug 19, 2019 at 10:06:33AM -0400, Celejar wrote:
>>
>> [...]
>>
>>> I'd love to run my own mail stack, and I think I could handle the
>>> software deployment reasonably well, but from everything I've read,
>>> the headaches required to make sure that major mail operators will
>>> actually accept my mail are more than I have time or patience for:
>>
>> It's not /that/ bad. I'm doing it myself, and I'm a C programmer.
>> As a sysad I'm a catastrophe :-)
> 
> As I've explained, I'm not scared of the basic software configuration
> and deployment. I have no patience, however, for constant monitoring to
> make sure I stay off blacklists, and dealing with all sorts of
> unspecified rules and conditions established by various organizations
> for them to accept my mail.


The most difficult thing is obtaining an suitable Internet connection.
 As an alternative, someone upstream suggested a hosting site.  I keep
forgetting how that would be better than Google.  I get quite a few
thank-you messages every day from DigitalOcean Security, Google Cloud
Platform, Amazon EC2, and similar providers to whom my server sends
abuse complaints automatically.  Sometimes I get notifications that
the relevant account was stroked.  What does go wrong there?

For one thing, among the eight support tools listed in the cited Ars
Technica howto there's no firewall.  Having the server /in the office/
and working at its console makes it much easier to see what's going
on.  I think that's what everybody should be doing.  It is a social
abuse that server connections cost so much more than residential ones,
and if I were a conspiracy theorist I would point my finger there.


Best
Ale



Why I mistrust bigcorps [was: webmail and email from command line]

2019-08-19 Thread tomas
[note: veering dangerously off-topic. If anyone kicks us out,
I'll accept without protesting]

On Mon, Aug 19, 2019 at 12:03:25PM -0400, Celejar wrote:
> On Mon, 19 Aug 2019 17:19:58 +0200
>  wrote:

[...]

> > Edited by D. Hardt, Microsoft. Hmmm.
> 
> Ad hominem.

rather ad corporationem. Mr. Hardt most probably is a nice guy
himself.


> > > Third-party applications are required to store the resource
> > >   owner's credentials for future use, typically a password in
> > >   clear-text.
> > 
> > So for Mr. Hardt, Kerberos doesn't exist. Or he's talking HTTP context
> > only.
> 
> Not sure what your point is here: how are the relative merits of
> OAuth and Kerberos [...]

The way you quoted rfc6749 made it seem that its way of handling
third-party authentication was unique. It is not. But for "normal"
mail business it isn't even necessary!

> > But I disgress: more interesting is this [1]:
> > 
> >"Eran Hammer resigned his role of lead author for the OAuth
> > 2.0 project, withdrew from the IETF working group, and removed
> > his name from the specification in July 2012. Hammer cited a
> > conflict between web and enterprise cultures as his reason
> > for leaving, noting that IETF is a community that is 'all
> > about enterprise use cases' and 'not capable of simple.'"
> 
> Not sure how this is relevant to our discussion.
> 
> > See also "decommoditizing protocols [2]
> 
> Relevance? Explain?

It is very much: it illustrates how bigcorps subvert standadrs
processes and use their leverage to influence perception ("not
secure" as a moniker for "not OAuth" or "not our way") to nudge
people.

> You're not addressing what I wrote: I cited the OAuth RFC's explanation
> for why something like OAuth is more secure than plain password
> authentication. You've thrown in all sorts of interesting history and
> ideology, but haven't directly addressed the points in the RFC.

OAuth may be "more secure for third-party website authentication",
that is what it was made for. It definitely isn't more secure
than "pasword authentication over a verified TLS link", and that's
how e.g. IMAP works. Heck, I'd venture that IMAPS is more secure,
because simpler (no third party).

> > > I was referring to the client side - Chrome / Chromium achieved
> > > dominance (particularly on the desktop) largely because they were
> > > widely recognized as being more performant than the alternatives.
> > 
> > Remember that Google is an advertising company?
> 
> Of course I remember, but you keep ignoring the technical points I'm
> making, and instead argue from ideology and innuendo. Do you or
> do you not agree that much of Chrome / Chromium's success for years was
> due to its technical merits?

Not really. Firefox had its weak phase, but it was short and seems
over. And I'm sure that it is in Google's strategy to influence that
perception.

Cheers
-- t


signature.asc
Description: Digital signature


Re: webmail and email from command line

2019-08-19 Thread Celejar
On Mon, 19 Aug 2019 17:21:40 +0200
 wrote:

> On Mon, Aug 19, 2019 at 10:06:33AM -0400, Celejar wrote:
> 
> [...]
> 
> > I'd love to run my own mail stack, and I think I could handle the
> > software deployment reasonably well, but from everything I've read,
> > the headaches required to make sure that major mail operators will
> > actually accept my mail are more than I have time or patience for:
> 
> It's not /that/ bad. I'm doing it myself, and I'm a C programmer.
> As a sysad I'm a catastrophe :-)

As I've explained, I'm not scared of the basic software configuration
and deployment. I have no patience, however, for constant monitoring to
make sure I stay off blacklists, and dealing with all sorts of
unspecified rules and conditions established by various organizations
for them to accept my mail.

Celejar



Re: webmail and email from command line

2019-08-19 Thread Celejar
On Mon, 19 Aug 2019 17:19:58 +0200
 wrote:

> On Mon, Aug 19, 2019 at 09:47:55AM -0400, Celejar wrote:
> > On Mon, 19 Aug 2019 10:32:31 +0200
> >  wrote:
> > 
> > > On Sun, Aug 18, 2019 at 09:15:45PM -0400, Celejar wrote:
> > > > On Sun, 18 Aug 2019 23:43:35 +0200
> > > >  wrote:
> > > > 
> > > > > On Sun, Aug 18, 2019 at 05:19:28PM -0400, Celejar wrote:
> > > > > > On Fri, 16 Aug 2019 10:10:35 +0200
> > > 
> > > [...]
> > > 
> > > > I think terming Google's decision to call software that doesn't
> > > > implement OAuth "less secure" "evil" is hyperbole [...]
> > > 
> > > This nicely demonstrates my point: OAuth is a HTTP oriented access
> > > delegation protocol. Why should that be at all relevant, e.g. in
> > > the context of IMAP?
> > 
> > >From the Introduction to RFC 6749:
> 
> Edited by D. Hardt, Microsoft. Hmmm.

Ad hominem.

> > *
> > 
> > In the traditional client-server authentication model [...]
> 
> > Third-party applications are required to store the resource
> >   owner's credentials for future use, typically a password in
> >   clear-text.
> 
> So for Mr. Hardt, Kerberos doesn't exist. Or he's talking HTTP context
> only.

Not sure what your point is here: how are the relative merits of
OAuth and Kerberos relevant to the underlying question of whether it is
or is not reasonable for Google to call OAuth more secure than plain
password authentication?

> But I disgress: more interesting is this [1]:
> 
>"Eran Hammer resigned his role of lead author for the OAuth
> 2.0 project, withdrew from the IETF working group, and removed
> his name from the specification in July 2012. Hammer cited a
> conflict between web and enterprise cultures as his reason
> for leaving, noting that IETF is a community that is 'all
> about enterprise use cases' and 'not capable of simple.'"

Not sure how this is relevant to our discussion.

> See also "decommoditizing protocols [2]

Relevance? Explain?

> > You can argue that none of this matters to you, since you trust
> > whatever OSS software you're using, but I stand by what I wrote that
> > it's unfair to term Google's decision to refer to applications that
> > don't implement OAuth "less secure" "evil".
> 
> Whatever you mean by "none of this": I am interested in security.
> But in /my/ security, on in /your/ security -- not Google's or
> Microsoft's (or whatever bigcorp's out there). Much less in their
> business model's security.

You're not addressing what I wrote: I cited the OAuth RFC's explanation
for why something like OAuth is more secure than plain password
authentication. You've thrown in all sorts of interesting history and
ideology, but haven't directly addressed the points in the RFC.

> > I was referring to the client side - Chrome / Chromium achieved
> > dominance (particularly on the desktop) largely because they were
> > widely recognized as being more performant than the alternatives.
> 
> Remember that Google is an advertising company?

Of course I remember, but you keep ignoring the technical points I'm
making, and instead argue from ideology and innuendo. Do you or
do you not agree that much of Chrome / Chromium's success for years was
due to its technical merits?

> > Firefox may be catching up now, but my impression is that for years,
> > both experts as well as laymen often preferred Chrome / Chromium
> > because of its speed. [Note that I have always stuck to Firefox for
> > almost all my browsing, largely because I don't like / trust Google, so
> > we're not as far apart as we might seem.]
> 
> [...]
> 
> > We agree - I want it out of my cereal bowl as well ;)
> 
> Google-free cereals for all ;-D

On this we agree!

Celejar



Re: webmail and email from command line

2019-08-19 Thread tomas
On Mon, Aug 19, 2019 at 11:29:04AM -0400, Jude DaShiell wrote:

> Google could evaluate the non-browser software in use and pass what is
> secure and fail the other packages with explanations for the authors of
> failed packages [...]

I think it's more subtle than that. "Traditional" (i.e. non-Webmail)
clients are qualified as "insecure" although they haven't to be.

This will softly nudge people towards (Google) webmail.

OTOH I don't want to be misunderstood. Google is big, and they actually
do a couple of things which benefit us all. Project Zero, for one.
Google Summer of Code, for another.

Cheers
-- tomás


signature.asc
Description: Digital signature


Re: webmail and email from command line

2019-08-19 Thread Jude DaShiell
On Mon, 19 Aug 2019, to...@tuxteam.de wrote:

> Date: Mon, 19 Aug 2019 11:19:58
> From: to...@tuxteam.de
> To: debian-user@lists.debian.org
> Subject: Re: webmail and email from command line
>
> On Mon, Aug 19, 2019 at 09:47:55AM -0400, Celejar wrote:
> > On Mon, 19 Aug 2019 10:32:31 +0200
> >  wrote:
> >
> > > On Sun, Aug 18, 2019 at 09:15:45PM -0400, Celejar wrote:
> > > > On Sun, 18 Aug 2019 23:43:35 +0200
> > > >  wrote:
> > > >
> > > > > On Sun, Aug 18, 2019 at 05:19:28PM -0400, Celejar wrote:
> > > > > > On Fri, 16 Aug 2019 10:10:35 +0200
> > >
> > > [...]
> > >
> > > > I think terming Google's decision to call software that doesn't
> > > > implement OAuth "less secure" "evil" is hyperbole [...]
> > >
> > > This nicely demonstrates my point: OAuth is a HTTP oriented access
> > > delegation protocol. Why should that be at all relevant, e.g. in
> > > the context of IMAP?
> >
> > >From the Introduction to RFC 6749:
>
> Edited by D. Hardt, Microsoft. Hmmm.
>
> > *
> >
> > In the traditional client-server authentication model [...]
>
> > Third-party applications are required to store the resource
> >   owner's credentials for future use, typically a password in
> >   clear-text.
>
> So for Mr. Hardt, Kerberos doesn't exist. Or he's talking HTTP context
> only.
>
> But I disgress: more interesting is this [1]:
>
>"Eran Hammer resigned his role of lead author for the OAuth
> 2.0 project, withdrew from the IETF working group, and removed
> his name from the specification in July 2012. Hammer cited a
> conflict between web and enterprise cultures as his reason
> for leaving, noting that IETF is a community that is 'all
> about enterprise use cases' and 'not capable of simple.'"
>
> See also "decommoditizing protocols [2]
>
> > You can argue that none of this matters to you, since you trust
> > whatever OSS software you're using, but I stand by what I wrote that
> > it's unfair to term Google's decision to refer to applications that
> > don't implement OAuth "less secure" "evil".
>
> Whatever you mean by "none of this": I am interested in security.
> But in /my/ security, on in /your/ security -- not Google's or
> Microsoft's (or whatever bigcorp's out there). Much less in their
> business model's security.
>
> > I was referring to the client side - Chrome / Chromium achieved
> > dominance (particularly on the desktop) largely because they were
> > widely recognized as being more performant than the alternatives.
>
> Remember that Google is an advertising company?
>
> > Firefox may be catching up now, but my impression is that for years,
> > both experts as well as laymen often preferred Chrome / Chromium
> > because of its speed. [Note that I have always stuck to Firefox for
> > almost all my browsing, largely because I don't like / trust Google, so
> > we're not as far apart as we might seem.]
>
> [...]
>
> > We agree - I want it out of my cereal bowl as well ;)
>
> Google-free cereals for all ;-D
>
> Cheers
>
> [1] https://en.wikipedia.org/wiki/OAuth#Controversy
> [2] https://www.levien.com/free/decommoditizing.html

Google could evaluate the non-browser software in use and pass what is
secure and fail the other packages with explanations for the authors of
failed packages but what google could do and what google is doing or will
be doing are three different matters altogether.  Lord Ackton in his full
quote had a few things to say about this and other corporate situations
in which we find ourselves these days.  By the way, his full quote is
longer than its first seven words and even better for that for my money.

>
> -- t >

-- 



Re: webmail and email from command line

2019-08-19 Thread tomas
On Mon, Aug 19, 2019 at 10:06:33AM -0400, Celejar wrote:

[...]

> I'd love to run my own mail stack, and I think I could handle the
> software deployment reasonably well, but from everything I've read,
> the headaches required to make sure that major mail operators will
> actually accept my mail are more than I have time or patience for:

It's not /that/ bad. I'm doing it myself, and I'm a C programmer.
As a sysad I'm a catastrophe :-)

Cheers
-- t


signature.asc
Description: Digital signature


Re: webmail and email from command line

2019-08-19 Thread tomas
On Mon, Aug 19, 2019 at 09:47:55AM -0400, Celejar wrote:
> On Mon, 19 Aug 2019 10:32:31 +0200
>  wrote:
> 
> > On Sun, Aug 18, 2019 at 09:15:45PM -0400, Celejar wrote:
> > > On Sun, 18 Aug 2019 23:43:35 +0200
> > >  wrote:
> > > 
> > > > On Sun, Aug 18, 2019 at 05:19:28PM -0400, Celejar wrote:
> > > > > On Fri, 16 Aug 2019 10:10:35 +0200
> > 
> > [...]
> > 
> > > I think terming Google's decision to call software that doesn't
> > > implement OAuth "less secure" "evil" is hyperbole [...]
> > 
> > This nicely demonstrates my point: OAuth is a HTTP oriented access
> > delegation protocol. Why should that be at all relevant, e.g. in
> > the context of IMAP?
> 
> >From the Introduction to RFC 6749:

Edited by D. Hardt, Microsoft. Hmmm.

> *
> 
> In the traditional client-server authentication model [...]

> Third-party applications are required to store the resource
>   owner's credentials for future use, typically a password in
>   clear-text.

So for Mr. Hardt, Kerberos doesn't exist. Or he's talking HTTP context
only.

But I disgress: more interesting is this [1]:

   "Eran Hammer resigned his role of lead author for the OAuth
2.0 project, withdrew from the IETF working group, and removed
his name from the specification in July 2012. Hammer cited a
conflict between web and enterprise cultures as his reason
for leaving, noting that IETF is a community that is 'all
about enterprise use cases' and 'not capable of simple.'"

See also "decommoditizing protocols [2]

> You can argue that none of this matters to you, since you trust
> whatever OSS software you're using, but I stand by what I wrote that
> it's unfair to term Google's decision to refer to applications that
> don't implement OAuth "less secure" "evil".

Whatever you mean by "none of this": I am interested in security.
But in /my/ security, on in /your/ security -- not Google's or
Microsoft's (or whatever bigcorp's out there). Much less in their
business model's security.

> I was referring to the client side - Chrome / Chromium achieved
> dominance (particularly on the desktop) largely because they were
> widely recognized as being more performant than the alternatives.

Remember that Google is an advertising company?

> Firefox may be catching up now, but my impression is that for years,
> both experts as well as laymen often preferred Chrome / Chromium
> because of its speed. [Note that I have always stuck to Firefox for
> almost all my browsing, largely because I don't like / trust Google, so
> we're not as far apart as we might seem.]

[...]

> We agree - I want it out of my cereal bowl as well ;)

Google-free cereals for all ;-D

Cheers

[1] https://en.wikipedia.org/wiki/OAuth#Controversy
[2] https://www.levien.com/free/decommoditizing.html

-- t


signature.asc
Description: Digital signature


Re: webmail and email from command line

2019-08-19 Thread Celejar
On Mon, 19 Aug 2019 11:33:52 +0200
Alessandro Vesely  wrote:

>  On Mon 19/Aug/2019 03:15:45 +0200 Celejar wrote:
> > I think terming Google's decision to call software that doesn't
> > implement OAuth "less secure" "evil" is hyperbole that doesn't help our
> > broader cause of opposing its breaking of standards, imposing various
> > sorts of lock-in, invasions of privacy, etc.
> 
> 
> Breaking of standards?  Not sure about the web, but for email
> protocols Google counts many active participants and gmail is often
> among the early adopters (e.g. ARC).

I think I've seen many reports of Gmail's breaking of standards over
the years, but here's one that I've been able to find:

http://pyropus.ca/software/getmail/faq.html#faq-notabug-gmail-bug

...

> At this point I realize this message is not so off-topic as I had
> figured when I hit the reply button.  So, let me mention I'm also
> still running my own server.  I use Courier-MTA, which integrates SMTP
> and IMAP with maildrop (delivery agent and mail filter) and a plethora
> of utilities.  Of course, I recommend it.

I'd love to run my own mail stack, and I think I could handle the
software deployment reasonably well, but from everything I've read,
the headaches required to make sure that major mail operators will
actually accept my mail are more than I have time or patience for:

https://arstechnica.com/information-technology/2014/02/how-to-run-your-own-e-mail-server-with-your-own-domain-part-1/
https://arstechnica.com/gadgets/2018/12/review-helm-personal-server-gets-email-self-hosting-almost-exactly-right/

Celejar



Re: webmail and email from command line

2019-08-19 Thread Celejar
On Mon, 19 Aug 2019 10:32:31 +0200
 wrote:

> On Sun, Aug 18, 2019 at 09:15:45PM -0400, Celejar wrote:
> > On Sun, 18 Aug 2019 23:43:35 +0200
> >  wrote:
> > 
> > > On Sun, Aug 18, 2019 at 05:19:28PM -0400, Celejar wrote:
> > > > On Fri, 16 Aug 2019 10:10:35 +0200
> 
> [...]
> 
> > I think terming Google's decision to call software that doesn't
> > implement OAuth "less secure" "evil" is hyperbole [...]
> 
> This nicely demonstrates my point: OAuth is a HTTP oriented access
> delegation protocol. Why should that be at all relevant, e.g. in
> the context of IMAP?

>From the Introduction to RFC 6749:

*

In the traditional client-server authentication model, the client
   requests an access-restricted resource (protected resource) on the
   server by authenticating with the server using the resource owner's
   credentials.  In order to provide third-party applications access to
   restricted resources, the resource owner shares its credentials with
   the third party.  This creates several problems and limitations:

Third-party applications are required to store the resource
  owner's credentials for future use, typically a password in
  clear-text.

...

Third-party applications gain overly broad access to the resource
  owner's protected resources, leaving resource owners without any
  ability to restrict duration or access to a limited subset of
  resources.

Resource owners cannot revoke access to an individual third party
  without revoking access to all third parties, and must do so by
  changing the third party's password.

Compromise of any third-party application results in compromise of
  the end-user's password and all of the data protected by that
  password.

*

https://tools.ietf.org/html/rfc6749

You can argue that none of this matters to you, since you trust
whatever OSS software you're using, but I stand by what I wrote that
it's unfair to term Google's decision to refer to applications that
don't implement OAuth "less secure" "evil".

> > > In general,
> > > 
> > >  - dominance on the server (adwords, visibility in search engines...)
> > >and on the client (Chrome/Chromium, Android) side.
> > 
> > I don't consider dominance gained largely through superior
> > technology and legitimate means "evil". Undesirable, yes.
> 
> This misses the point. The fact that my favourite news"paper" has to
> embed Google trackers in its website to survive economically has nothing
> to do with technical superiority and all with market dominance.

I was referring to the client side - Chrome / Chromium achieved
dominance (particularly on the desktop) largely because they were
widely recognized as being more performant than the alternatives.
Firefox may be catching up now, but my impression is that for years,
both experts as well as laymen often preferred Chrome / Chromium
because of its speed. [Note that I have always stuck to Firefox for
almost all my browsing, largely because I don't like / trust Google, so
we're not as far apart as we might seem.]

...

> > > IMO they're far too big.
> > 
> > Agreed, but again, I don't think that makes them "evil".
> 
> Call that what you want. I call this "emergent evil". And I definitely
> want it out of my cereal bowl :-)

We agree - I want it out of my cereal bowl as well ;)

Celejar



Re: webmail and email from command line

2019-08-19 Thread Alessandro Vesely
 On Mon 19/Aug/2019 03:15:45 +0200 Celejar wrote:
> I think terming Google's decision to call software that doesn't
> implement OAuth "less secure" "evil" is hyperbole that doesn't help our
> broader cause of opposing its breaking of standards, imposing various
> sorts of lock-in, invasions of privacy, etc.


Breaking of standards?  Not sure about the web, but for email
protocols Google counts many active participants and gmail is often
among the early adopters (e.g. ARC).

On the other hand, I am perplexed when I see epic personalities of
IETF standard making, like Brian Carpenter, Dave Crocket, and many
other, preferably use gmail addresses.  Most of them used to prefer
sending from their own mail servers.  Obviously, they find gmail more
convenient...  Of course, protocols will be useless when there will be
just one or two providers.

Even John Klensin, the author of ESMTP, although he uses his own
domain for sending mail through Exim, uses outlook.com for incoming
MX.  Presumably, that's more convenient than maintaining efficient
anti-virus and anti-spam.  Notably, as an SMTP purist, John deploys
neither SPF nor DKIM.

At this point I realize this message is not so off-topic as I had
figured when I hit the reply button.  So, let me mention I'm also
still running my own server.  I use Courier-MTA, which integrates SMTP
and IMAP with maildrop (delivery agent and mail filter) and a plethora
of utilities.  Of course, I recommend it.


jm2c
Ale





Re: webmail and email from command line

2019-08-19 Thread Nektarios Katakis
On Mon, 19 Aug 2019 10:32:31 +0200
 wrote:

> On Sun, Aug 18, 2019 at 09:15:45PM -0400, Celejar wrote:
> > On Sun, 18 Aug 2019 23:43:35 +0200
> >  wrote:
> > 
> > > On Sun, Aug 18, 2019 at 05:19:28PM -0400, Celejar wrote:
> > > > On Fri, 16 Aug 2019 10:10:35 +0200
> 
> [...]
> 
> > I think terming Google's decision to call software that doesn't
> > implement OAuth "less secure" "evil" is hyperbole [...]
> 
> This nicely demonstrates my point: OAuth is a HTTP oriented access
> delegation protocol. Why should that be at all relevant, e.g. in
> the context of IMAP?
> 

I couldn't agree more. SMTP and IMAP have their own specs and any mail
host that follows them is legit. Google is evil as it is monopolizing
the market and following microsoft practices from 10-15 years back.

Like either works with Google or we dont care. 

> > > In general,
> > > 
> > >  - dominance on the server (adwords, visibility in search
> > > engines...) and on the client (Chrome/Chromium, Android) side.
> > 
> > I don't consider dominance gained largely through superior
> > technology and legitimate means "evil". Undesirable, yes.
> 
> This misses the point. The fact that my favourite news"paper" has to
> embed Google trackers in its website to survive economically has
> nothing to do with technical superiority and all with market
> dominance.
> 
> Not long ago, Microsoft was in this position. Remember when Internet
> Explorer was the dominant browser and everyone was hot on implementig
> ActiveX?
> 
> [...]
> 
> > > (I'm sure you can think of two or three more).
> > > 
> > > IMO they're far too big.
> > 
> > Agreed, but again, I don't think that makes them "evil".
> 
> Call that what you want. I call this "emergent evil". And I definitely
> want it out of my cereal bowl :-)

And definitely is. I am happy that there are people out there
recognizing it.


> 
> Cheers
> -- t

Regards,

-- 
Nektarios Katakis



Re: webmail and email from command line

2019-08-19 Thread tomas
On Sun, Aug 18, 2019 at 09:15:45PM -0400, Celejar wrote:
> On Sun, 18 Aug 2019 23:43:35 +0200
>  wrote:
> 
> > On Sun, Aug 18, 2019 at 05:19:28PM -0400, Celejar wrote:
> > > On Fri, 16 Aug 2019 10:10:35 +0200

[...]

> I think terming Google's decision to call software that doesn't
> implement OAuth "less secure" "evil" is hyperbole [...]

This nicely demonstrates my point: OAuth is a HTTP oriented access
delegation protocol. Why should that be at all relevant, e.g. in
the context of IMAP?

> > In general,
> > 
> >  - dominance on the server (adwords, visibility in search engines...)
> >and on the client (Chrome/Chromium, Android) side.
> 
> I don't consider dominance gained largely through superior
> technology and legitimate means "evil". Undesirable, yes.

This misses the point. The fact that my favourite news"paper" has to
embed Google trackers in its website to survive economically has nothing
to do with technical superiority and all with market dominance.

Not long ago, Microsoft was in this position. Remember when Internet
Explorer was the dominant browser and everyone was hot on implementig
ActiveX?

[...]

> > (I'm sure you can think of two or three more).
> > 
> > IMO they're far too big.
> 
> Agreed, but again, I don't think that makes them "evil".

Call that what you want. I call this "emergent evil". And I definitely
want it out of my cereal bowl :-)

Cheers
-- t


signature.asc
Description: Digital signature


Re: webmail and email from command line

2019-08-18 Thread Celejar
On Sun, 18 Aug 2019 23:43:35 +0200
 wrote:

> On Sun, Aug 18, 2019 at 05:19:28PM -0400, Celejar wrote:
> > On Fri, 16 Aug 2019 10:10:35 +0200
> >  wrote:
> 
> [...]
> 
> > > > less secure apps" option, and then configure POP3 / SMTP normally.
> > >   
> > > 
> > > Google's evil comes through the backdoor, without making any noise,
> > > like Wormtongue.
> > 
> > Explain, please?
> 
> Allow me to be short, since off-topic for this thread and most probably
> off-topic for the list.
> 
> In the specific case above, first of all, definitional power ("we get
> to say what is secure").

I think terming Google's decision to call software that doesn't
implement OAuth "less secure" "evil" is hyperbole that doesn't help our
broader cause of opposing its breaking of standards, imposing various
sorts of lock-in, invasions of privacy, etc.

> In general,
> 
>  - dominance on the server (adwords, visibility in search engines...)
>and on the client (Chrome/Chromium, Android) side.

I don't consider dominance gained largely through superior
technology and legitimate means "evil". Undesirable, yes.

>  - mindshare: developers get used to do things "the Google way"
> 
>  - mindshare (II): users perceive an app as broken if it works
>differently
> 
>  - subtle behavioural knowledge about almost anyone on or near
>the 'net
> 
> (I'm sure you can think of two or three more).
> 
> IMO they're far too big.

Agreed, but again, I don't think that makes them "evil".

Celejar



Re: webmail and email from command line

2019-08-18 Thread tomas
On Sun, Aug 18, 2019 at 05:19:28PM -0400, Celejar wrote:
> On Fri, 16 Aug 2019 10:10:35 +0200
>  wrote:

[...]

> > > less secure apps" option, and then configure POP3 / SMTP normally.
> >   
> > 
> > Google's evil comes through the backdoor, without making any noise,
> > like Wormtongue.
> 
> Explain, please?

Allow me to be short, since off-topic for this thread and most probably
off-topic for the list.

In the specific case above, first of all, definitional power ("we get
to say what is secure").

In general,

 - dominance on the server (adwords, visibility in search engines...)
   and on the client (Chrome/Chromium, Android) side.

 - mindshare: developers get used to do things "the Google way"

 - mindshare (II): users perceive an app as broken if it works
   differently

 - subtle behavioural knowledge about almost anyone on or near
   the 'net

(I'm sure you can think of two or three more).

IMO they're far too big.

Cheers
-- t


signature.asc
Description: Digital signature


Re: webmail and email from command line

2019-08-18 Thread Celejar
On Fri, 16 Aug 2019 10:10:35 +0200
 wrote:

> On Thu, Aug 15, 2019 at 10:02:57PM -0400, Celejar wrote:
> > On Wed, 14 Aug 2019 16:24:49 +
> > loredana  wrote:
> > 
> > ...
> > 
> > > secure applications, this is likely not to be a viable solution (it
> > > seems that google is going to forbit less secure application access
> > > starting November first of this year and it is already a pain to use
> > > it now).
> > 
> > What is your source for Google's plans, and how is it already a pain? I
> > have been using getmail and sylpheed with several Google mail accounts
> > for years, and it seemed pretty straightforward - just set the "allow
> > less secure apps" option, and then configure POP3 / SMTP normally.
>   
> 
> Google's evil comes through the backdoor, without making any noise,
> like Wormtongue.

Explain, please?

Celejar



Re: webmail and email from command line

2019-08-16 Thread Jude DaShiell
anyone who needs that, needs a burner account.  Those are lots less
permanent and when your account is taken by someone else since you have
no way to recover that account it's understood whatever you had in it
was encrypted and is disposible.  Google provides a higher level of
management than you need for this kind of account.  The aol "service" it
turns out had these kind of accounts which once a screen name was taken
over you lost the account that went with it.
Search for public internet sites and check out what mail services those
have to offer and I think you'll be happy.

On Fri, 16 Aug 2019, loredana wrote:

> Date: Fri, 16 Aug 2019 11:26:53
> From: loredana 
> To: Jude DaShiell 
> Cc: debian-user@lists.debian.org
> Subject: Re: webmail and email from command line
> Resent-Date: Fri, 16 Aug 2019 13:27:39 + (UTC)
> Resent-From: debian-user@lists.debian.org
>
> On Fri, Aug 16, 2019 at 12:51 PM Jude DaShiell  wrote:
>
> > Running using 2fa may be possible with non-browser apps if your security
> > records indicate you ran with what google considers an untrusted app and
> > google has it listed.  You can generate an app-specific password for the
> > non-browser app and will need to save it.  Then you modify your
> > non-browser app settings on local machine and key in that app-specific
> > password in place of the other password you used earlier.  This has been
> > documented for mutt as being possible and may work for other non-browser
> > apps too.  You'll need to give google a mobile number for account
> > recovery and the like too.
>
> Yes, that should work too (see the first mail in this thread).
>
> But ... what stopped me and made me think is: what if I prefer to have
> access to "my" mail without giving up a mobile or not so mobile
> telephone number?
>
> I am happier if this is made possible for everybody who prefer so via
> a free application. Not sure gmailieer is going to work, not until I
> try it. Bu it looks promising.
>
> Cheers,
> Loredana
>
>

-- 



Re: webmail and email from command line

2019-08-16 Thread lena
Hi Loredana,

I agree with other debianers that setting a forward to another email
provider for now should be the easiest option.

I think it would be a good idea to find an email provider that allows
smtp/imap clients, and as far as I know protonmail does it only in Pro
version. I know there is posteo.de that does. Also, there should be
some small local email providers in your area, the services are usually
on fee (normally quite low) but you gain direct support with setups and
all the rest.

As for command line email clients, probably the most complete one is
Mutt. There is a guide from a year ago on how to configure it with gmail
here: https://gitlab.com/muttmua/mutt/wikis/UseCases/Gmail

I know mutt allows different security features, but it surpass my
experience with it, as gmail might be demanding and moody in allowing
external clients.

You can actually set mutt and emacs to work together as explained here:
https://gitlab.com/muttmua/mutt/wikis/MuttFaq/Editor#how-do-i-configure-mutt-to-use-mail-mode-in-emacs
or here https://www.emacswiki.org/emacs/MuttInEmacs 

If you decide for mutt and stumble across configuration problems, you
can look for support in sdf.org community. It is a command-line based
community (you login over ssh) with an important part of blind users,
so surely they will be more knowledgeble than I am :smiley:

I hope this helps,
best regards,
~l.




Re: webmail and email from command line

2019-08-16 Thread loredana
On Fri, Aug 16, 2019 at 12:51 PM Jude DaShiell  wrote:

> Running using 2fa may be possible with non-browser apps if your security
> records indicate you ran with what google considers an untrusted app and
> google has it listed.  You can generate an app-specific password for the
> non-browser app and will need to save it.  Then you modify your
> non-browser app settings on local machine and key in that app-specific
> password in place of the other password you used earlier.  This has been
> documented for mutt as being possible and may work for other non-browser
> apps too.  You'll need to give google a mobile number for account
> recovery and the like too.

Yes, that should work too (see the first mail in this thread).

But ... what stopped me and made me think is: what if I prefer to have
access to "my" mail without giving up a mobile or not so mobile
telephone number?

I am happier if this is made possible for everybody who prefer so via
a free application. Not sure gmailieer is going to work, not until I
try it. Bu it looks promising.

Cheers,
Loredana



Re: webmail and email from command line

2019-08-16 Thread Jude DaShiell
On Fri, 16 Aug 2019, loredana wrote:

> Date: Fri, 16 Aug 2019 10:02:17
> From: loredana 
> To: Celejar 
> Cc: debian-user@lists.debian.org
> Subject: Re: webmail and email from command line
> Resent-Date: Fri, 16 Aug 2019 12:03:05 + (UTC)
> Resent-From: debian-user@lists.debian.org
>
> First of all, I wish to thank all of you who shared their experience.
> Be reassured I am taking any constructive suggestion into serious
> account and exploring more.
>
> Then:
>
> On Fri, Aug 16, 2019 at 2:03 AM Celejar  wrote:
> >
> > On Wed, 14 Aug 2019 16:24:49 +000
>
> > loredana  wrote:
> > > secure applications, this is likely not to be a viable solution (it
> > > seems that google is going to forbit less secure application access
> > > starting November first of this year and it is already a pain to use
> > > it now).
> >
> > What is your source for Google's plans, and how is it already a pain?
>
> I am following the google development on this issue, but I got the
> date from the mu4e mailing list. I'l post the link, if I can find it
> again (remember, I am almost blind and even replying to email is, at
> the moment, really slow and difficult).
>
> > have been using getmail and sylpheed with several Google mail accounts
> > for years, and it seemed pretty straightforward - just set the "allow
> > less secure apps" option, and then configure POP3 / SMTP normally.
>
> In the email that started this thread, I tried to make clear that this
> is something happening "now". I use the internet for crossing oceans
> quickly since bitnet and I remember whet google was born as
> google."org". I am myself a long term gmail user and this is why I
> carefully look after main changes. The way email clients will
> authenticate to gmail is drfinitely one of them and is going to affect
> us for sure.
>
> I may be able to be more responsive once I find a good way of avoiding 
> webmail.
> Meanwhile, here is the best I could find toward a possible solution
> that may help avoid the OAUTH2 authorization issue by complying with
> it.
>
> You need debian buster as a minimum, then look at the gmailieer
> package. It seems to be oauth2 enabled and therefore be able to access
> gmail and possibly other mail providers. I still have to test it. If
> you try it, be careful because it requires notmuch and notmuch is in
> the less secure apps list, so you have to allow less secure apps
> first, I guess, and hopefully be able to set it off/on as you like
> again (if you can, this will probably get a feeling about the pain
> ...).
>
> gmailieer is GPLv3+ and in debian. IMHO this these are two good
> things. The debian package page:
> https://packages.debian.org/search?keywords=gmailieer
>
> It seems that mbsync (isink) is on itw long way to become OAUTH2
> enableb, too, as possibly other applications. It is a matter of timen
> and the free software community will catch up, as usual.
>
> I don't think the authentication issue is going to affect webmail
> users for a while.

Running using 2fa may be possible with non-browser apps if your security
records indicate you ran with what google considers an untrusted app and
google has it listed.  You can generate an app-specific password for the
non-browser app and will need to save it.  Then you modify your
non-browser app settings on local machine and key in that app-specific
password in place of the other password you used earlier.  This has been
documented for mutt as being possible and may work for other non-browser
apps too.  You'll need to give google a mobile number for account
recovery and the like too.

> > Loredana > >

--



Re: webmail and email from command line

2019-08-16 Thread loredana
First of all, I wish to thank all of you who shared their experience.
Be reassured I am taking any constructive suggestion into serious
account and exploring more.

Then:

On Fri, Aug 16, 2019 at 2:03 AM Celejar  wrote:
>
> On Wed, 14 Aug 2019 16:24:49 +000

> loredana  wrote:
> > secure applications, this is likely not to be a viable solution (it
> > seems that google is going to forbit less secure application access
> > starting November first of this year and it is already a pain to use
> > it now).
>
> What is your source for Google's plans, and how is it already a pain?

I am following the google development on this issue, but I got the
date from the mu4e mailing list. I'l post the link, if I can find it
again (remember, I am almost blind and even replying to email is, at
the moment, really slow and difficult).

> have been using getmail and sylpheed with several Google mail accounts
> for years, and it seemed pretty straightforward - just set the "allow
> less secure apps" option, and then configure POP3 / SMTP normally.

In the email that started this thread, I tried to make clear that this
is something happening "now". I use the internet for crossing oceans
quickly since bitnet and I remember whet google was born as
google."org". I am myself a long term gmail user and this is why I
carefully look after main changes. The way email clients will
authenticate to gmail is drfinitely one of them and is going to affect
us for sure.

I may be able to be more responsive once I find a good way of avoiding webmail.
Meanwhile, here is the best I could find toward a possible solution
that may help avoid the OAUTH2 authorization issue by complying with
it.

You need debian buster as a minimum, then look at the gmailieer
package. It seems to be oauth2 enabled and therefore be able to access
gmail and possibly other mail providers. I still have to test it. If
you try it, be careful because it requires notmuch and notmuch is in
the less secure apps list, so you have to allow less secure apps
first, I guess, and hopefully be able to set it off/on as you like
again (if you can, this will probably get a feeling about the pain
...).

gmailieer is GPLv3+ and in debian. IMHO this these are two good
things. The debian package page:
https://packages.debian.org/search?keywords=gmailieer

It seems that mbsync (isink) is on itw long way to become OAUTH2
enableb, too, as possibly other applications. It is a matter of timen
and the free software community will catch up, as usual.

I don't think the authentication issue is going to affect webmail
users for a while.

Loredana



Re: webmail and email from command line

2019-08-16 Thread tomas
On Thu, Aug 15, 2019 at 10:02:57PM -0400, Celejar wrote:
> On Wed, 14 Aug 2019 16:24:49 +
> loredana  wrote:
> 
> ...
> 
> > secure applications, this is likely not to be a viable solution (it
> > seems that google is going to forbit less secure application access
> > starting November first of this year and it is already a pain to use
> > it now).
> 
> What is your source for Google's plans, and how is it already a pain? I
> have been using getmail and sylpheed with several Google mail accounts
> for years, and it seemed pretty straightforward - just set the "allow
> less secure apps" option, and then configure POP3 / SMTP normally.
  

Google's evil comes through the backdoor, without making any noise,
like Wormtongue.

Cheers
-- t


signature.asc
Description: Digital signature


Re: webmail and email from command line

2019-08-15 Thread Celejar
On Wed, 14 Aug 2019 16:24:49 +
loredana  wrote:

...

> secure applications, this is likely not to be a viable solution (it
> seems that google is going to forbit less secure application access
> starting November first of this year and it is already a pain to use
> it now).

What is your source for Google's plans, and how is it already a pain? I
have been using getmail and sylpheed with several Google mail accounts
for years, and it seemed pretty straightforward - just set the "allow
less secure apps" option, and then configure POP3 / SMTP normally.

Celejar



Re: webmail and email from command line

2019-08-15 Thread Celejar
On Wed, 14 Aug 2019 18:23:23 +0200
to...@tuxteam.de wrote:

...

> Elsewhere, perhaps riseup [1] is an option. It's donation-funded,
> so consider throwing some small amount into their hat.
> 
> Cheers
> 
> [1] https://riseup.net/

I think you've mentioned them before, but how seriously should we take
its politics? Say I do have some moderate techno-libertarian leanings,
but I don't quite qualify as a person who is "working on liberatory
social change" [1], or an "[ally] engaged in struggles against
patriarchy, white-supremecy, capitalism, and other forms of
oppression." [2] Is Riseup still for me?

[1] https://riseup.net/
[2] https://account.riseup.net/user/new

Celejar



Re: webmail and email from command line

2019-08-15 Thread David Wright
On Wed 14 Aug 2019 at 12:19:01 (-0600), Joe Pfeiffer wrote:
> loredana  writes:
> 
> > On Wed, Aug 14, 2019 at 3:00 PM  wrote:
> >
> >> [...]
> >
> >> Note that what Google calls there "less secure applications" is just
> >> marketing mumbo-jumbo to nudge users off their non-browser clients.
> >
> > I know. But knowing it, and perhaps blaiming it, is not a solution.
> >
> >> Is changing mail provider an option for you?
> >
> > Yes, not an easy one, 'though. Image writing to all your contacts,
> > human and automatic ones, and convince them to write to a new email
> > address.
> 
> For exactly that reason, years ago I bought my own domain (no, this
> isn't it -- mostly out of inertia, I still post to usenet using my old
> NMSU address) and run my own email server.

Just to make it clear, you don't have to go to the trouble of running
a mail server just because you buy a domain. A hosting service can do
this for you, so that you need do no more than read emails and manage
your inboxes through a mail client via IMAP, and send emails through
their smarthost via SMTP.

I originally bought my domain through my ISP, and it cost nothing
because it was bundled into their service. I've moved it once, to
an independent hosting service, when I changed my ISP to one that
doesn't do hosting.

Since moving continents (and ISP), I've kept the domain with the same
hosting service (in the UK). They automatically reregister it
(actually, them) automatically every two years (as they did just today).
It means no change in email addresses every time you move.

> That way I only had to do it
> one last time, and won't need to change again.
> 
> > Moreover, is this going to be a solution?
> >
> > Which provider would you suggest?
> 
> There are multiple providers out there that will work fine.  I'm on
> netfirms.com; I'm webmaster for a shotgun club
> (mesillavalleyshotgunsports.com) that uses godaddy.com. 

Cheers,
David.



Re: webmail and email from command line

2019-08-14 Thread Joe Dennigan
to...@tuxteam.de writes:
> On Wed, Aug 14, 2019 at 06:02:01PM +, loredana wrote:
> > On Wed, Aug 14, 2019 at 3:00 PM  wrote:
> >=20
> > > [...]
> >=20
> > > Note that what Google calls there "less secure applications" is just
> > > marketing mumbo-jumbo to nudge users off their non-browser clients.
> >
> > I know. But knowing it, and perhaps blaiming it, is not a solution.
> 
> Of course not. It's just noticing the problem. This is a prerequisite for
> the solution :-)
> 
> > > Is changing mail provider an option for you?
> >0
> > Yes, not an easy one, 'though. Image writing to all your contacts,
> > human and automatic ones, and convince them to write to a new email
> > address.
> >
> > Moreover, is this going to be a solution?
> 
> To some things, yes. To others, no :-)
> 
> But at least expect a more "normal" IMAP access than Google offers...
> 
> > Which provider would you suggest?
> 
> Depends on where you are. Over here in Germany, I know a few good
> ones costing a small fee.
> 
> Elsewhere, perhaps riseup [1] is an option. It's donation-funded,
> so consider throwing some small amount into their hat.
> 
> Cheers
> 
> [1] https://riseup.net/
> 
Just thought I'd chime in here.  I've been redirecting all webmail (currently
gmail and my ISP) to a Fastmail¹ account for nearly ten years then using
fetchmail and nmh (+ emacs/mh-e at times) to read it with no problems.
Sending via their servers and a basic postfix installation here has been
reliable.

I don't know if their service meets the OPs needs but may be worth a look,
and they're pretty cheap for basic email.

Regards

Joe

¹https://www.fastmail.com


-- 
“Blood sacrifices keep the planet from eating your feet”
 -- Red



Re: webmail and email from command line

2019-08-14 Thread Joe Pfeiffer
loredana  writes:

> On Wed, Aug 14, 2019 at 3:00 PM  wrote:
>
>> [...]
>
>> Note that what Google calls there "less secure applications" is just
>> marketing mumbo-jumbo to nudge users off their non-browser clients.
>
> I know. But knowing it, and perhaps blaiming it, is not a solution.
>
>> Is changing mail provider an option for you?
>
> Yes, not an easy one, 'though. Image writing to all your contacts,
> human and automatic ones, and convince them to write to a new email
> address.

For exactly that reason, years ago I bought my own domain (no, this
isn't it -- mostly out of inertia, I still post to usenet using my old
NMSU address) and run my own email server.  That way I only had to do it
one last time, and won't need to change again.

> Moreover, is this going to be a solution?
>
> Which provider would you suggest?

There are multiple providers out there that will work fine.  I'm on
netfirms.com; I'm webmaster for a shotgun club
(mesillavalleyshotgunsports.com) that uses godaddy.com. 



Re: webmail and email from command line

2019-08-14 Thread Paul Sutton


On 14/08/2019 19:02, loredana wrote:
> On Wed, Aug 14, 2019 at 3:00 PM  wrote:
>
>> [...]
>> Note that what Google calls there "less secure applications" is just
>> marketing mumbo-jumbo to nudge users off their non-browser clients.
> I know. But knowing it, and perhaps blaiming it, is not a solution.
>
>> Is changing mail provider an option for you?
> Yes, not an easy one, 'though. Image writing to all your contacts,
> human and automatic ones, and convince them to write to a new email
> address.
>
> Moreover, is this going to be a solution?
>
> Which provider would you suggest?
>
> Cheers, Loredana
>
>
I use https://protonmail.com/ which is due to get features such as
calender etc very soon

and

https://disroot.org/en

disroot also offers, cloud, file sharing and many other services. 

Moving is not always difficult or can just be time consuming.  I spent a
good few hours logging in to websites, changing my credentials and
confirming from the resulting e-mail. 

It also gives you a chance to do an audit and decide do I use this
service, if not dump it or move the e-mail associated with that to
another service,  2 or 3 disroot services are good for different things.

I had scam e-mail a while back, sent a e-mail to report it, and got a
reply asking for me to include headers, so the developers want you and
care about their user base enough to do this.

Hope this helps

Paul


>> Cheers
>> -- tomás

-- 
Paul Sutton
http://www.zleap.net
gnupg : 7D6D B682 F351 8D08 1893  1E16 F086 5537 D066 302D

https://fediverse.party/ - zl...@social.isurf.ca



Re: webmail and email from command line

2019-08-14 Thread Dan Purgert
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

loredana wrote:
> On Wed, Aug 14, 2019 at 3:00 PM  wrote:
>
>> [...]
>
>> Note that what Google calls there "less secure applications" is just
>> marketing mumbo-jumbo to nudge users off their non-browser clients.
>
> I know. But knowing it, and perhaps blaiming it, is not a solution.
>
>> Is changing mail provider an option for you?
>
> Yes, not an easy one, 'though. Image writing to all your contacts,
> human and automatic ones, and convince them to write to a new email
> address.

You can always set gmail up to forward mails to another email address.
Then your friends and family can keep sending to "y...@gmail.com".
You'll just be replying from "y...@not-gmail.com".

> Which provider would you suggest?

Digital Ocean, and Postfix / Dovecot.

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAl1UPQYACgkQjhHd8xJ5
ooGSwwgAmeCAcyCwycVnWtNZ3xwqYtnElsMKqv0AMlZbz511yMTrXenoM1E+KKuN
yUDEAiqureKVQGvlJOGlEpivKF9+394a/r9WRsJIn64lesRA4P9Ox3o7vi/Un9Ar
Urt7RSSHJjVt2lCn/z2rdClHarjk9rhCM1lQhmpkvX0OF+lWCCcIdFjFYZosAddQ
EkPD2h7e2I5PcpeDRQ+AkYeTaSZWeonBfC8CN5H2Zk1YPbyZBt40DExAMxeHNPCw
KYxhkWkf4vgCt5c8AFr8rzS0ayWfBF8Dvkiizg74uht2TKUwAp12Qlut5b/xZ+Ie
3MtxK/VKGTI/IGzBCDube5KyEAuIQw==
=6IrX
-END PGP SIGNATURE-

-- 
|_|O|_| 
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281



Re: webmail and email from command line

2019-08-14 Thread tomas
On Wed, Aug 14, 2019 at 06:02:01PM +, loredana wrote:
> On Wed, Aug 14, 2019 at 3:00 PM  wrote:
> 
> > [...]
> 
> > Note that what Google calls there "less secure applications" is just
> > marketing mumbo-jumbo to nudge users off their non-browser clients.
> 
> I know. But knowing it, and perhaps blaiming it, is not a solution.

Of course not. It's just noticing the problem. This is a prerequisite for
the solution :-)

> > Is changing mail provider an option for you?
> 
> Yes, not an easy one, 'though. Image writing to all your contacts,
> human and automatic ones, and convince them to write to a new email
> address.
> 
> Moreover, is this going to be a solution?

To some things, yes. To others, no :-)

But at least expect a more "normal" IMAP access than Google offers...

> Which provider would you suggest?

Depends on where you are. Over here in Germany, I know a few good
ones costing a small fee.

Elsewhere, perhaps riseup [1] is an option. It's donation-funded,
so consider throwing some small amount into their hat.

Cheers

[1] https://riseup.net/

-- tomás


signature.asc
Description: Digital signature


Re: webmail and email from command line

2019-08-14 Thread john doe
On 8/14/2019 8:02 PM, loredana wrote:
> On Wed, Aug 14, 2019 at 3:00 PM  wrote:
>
>> [...]
>
>> Note that what Google calls there "less secure applications" is just
>> marketing mumbo-jumbo to nudge users off their non-browser clients.
>
> I know. But knowing it, and perhaps blaiming it, is not a solution.
>
>> Is changing mail provider an option for you?
>
> Yes, not an easy one, 'though. Image writing to all your contacts,
> human and automatic ones, and convince them to write to a new email
> address.
>

You could use e-mail redirect to work around this

In other words, you setup your gmail account to redirect/forward all
your e-mail to an other e-mail that is more suitable to you.

--
John Doe



Re: webmail and email from command line

2019-08-14 Thread loredana
On Wed, Aug 14, 2019 at 3:00 PM  wrote:

> [...]

> Note that what Google calls there "less secure applications" is just
> marketing mumbo-jumbo to nudge users off their non-browser clients.

I know. But knowing it, and perhaps blaiming it, is not a solution.

> Is changing mail provider an option for you?

Yes, not an easy one, 'though. Image writing to all your contacts,
human and automatic ones, and convince them to write to a new email
address.

Moreover, is this going to be a solution?

Which provider would you suggest?

Cheers, Loredana


>
> Cheers
> -- tomás



Re: webmail and email from command line

2019-08-14 Thread tomas
On Wed, Aug 14, 2019 at 04:24:49PM +, loredana wrote:
> Greetings,
> 
> I posted the following message to debian-accessibility and I post it
> again suggested.

[...]

> 'Though I managed to send mail to my gmail account by allowing less
> secure applications, this is likely not to be a viable solution (it
> seems that google is going to forbit less secure application access
> starting November first of this year and it is already a pain to use
> it now).

Note that what Google calls there "less secure applications" is just
marketing mumbo-jumbo to nudge users off their non-browser clients.

Is changing mail provider an option for you?

Cheers
-- tomás


signature.asc
Description: Digital signature


webmail and email from command line

2019-08-14 Thread loredana
Greetings,

I posted the following message to debian-accessibility and I post it
again suggested.

Briefly, I am a "long term" debian user (since debian potato) and I am
almost but not completely blind. This happened recently, so I am still
adapting to the new situation. Please keep this in mind, as it is the
primary problem for us.

I find increasily difficult and error prone to read/send email via a
browser and would like to either use emacs (preferred, now that it
talks, thanks to speechd-el) or the command line.

'Though I managed to send mail to my gmail account by allowing less
secure applications, this is likely not to be a viable solution (it
seems that google is going to forbit less secure application access
starting November first of this year and it is already a pain to use
it now).

Two factor authentication may well be the only solution for desktop
users in a couple of months time.

Your Institution willl have somebody solving this issue for you, but
at home normal users who prefer to avoid using a browser for email are
on their own.

Once the authentication issue is solved, then any client (not only a
browser) should be able to read/send mail, making life for me and
possibly other visually impaired people easier.

Here is what I plan to do:

* use mbsync to fetch mail locally

* use any tool to read/edit mail locally (I will use emacs and mu4e,
but at this point any editor and mail agent than can work with mail
locally should be just fine)

* configure exim to deal with gmail authentication to read and send
mail via smtp gmail server frpm localhost.

Is this a reasonable approach? Any comment or suggestion? Any other
way of dealing with email locally, without a browser, and to use the
network only for reading/sending mail with an imap/smtp server
acceptable authorization?

BTW, swacks is in debian and it is a very nice tool to test smtp
connections from the command line:

swaks --tls --auth --to @gmail.com --server smtp.gmail.com

Be careful with spoken passwords ..

Loredana