Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..
On Sun, Jan 26, 2020 at 10:35 AM Andrew C Aitchison via mailop < mailop@mailop.org> wrote: > On Sun, 26 Jan 2020, Jaroslaw Rafa via mailop wrote: > > > Similar thing happened to me recently when I wanted to re-login to one of > > those test accounts from my home computer, but I installed a new browser > > which was not yet used with that account. Usually there are no problems > in > > such a case, but my home Internet connection just went down that day and > I > > had to switch to a backup connection via cellular modem. Probably because > > of IP address belonging to a generally-accessible mobile operator's pool, > > Google behaved differently when I logged in to the account. After I > already > > provided a correct password, Google demanded from me to enter a phone > number > > that can be used for verification (!) and I couldn't successfully > complete > > the login procedure, because I didn't want to associate any phone number > > with that account. > > Hmm. > Proving that you can read a text sent to a number you provide today > does not prove that you are the person who used the ID and password > yesterday. > So they demand you provide a new verification channel so that you can > prove your ID *next* time ? > > I find these multi-factor verifications unsettling because it takes > a significant effort to convince myself that the verification does > indeed prove what it is supposed to prove and that it is safe from > man-in-the-middle. > I have lost enough physical keys over the years to worry about what > happens if I lose my phone (which does not have a finger print reader) ... > It's hard to determine what happened based on the descriptions, but the general answer is pretty simple. Passwords are terrible and completely broken. They are generally poorly chosen, weak, and re-used. The result is extreme levels of hijacking. On top of that, people forget their passwords and this isn't something like your home electricity bill or even your bank... how does Google know it's you? At the one end, that makes account recovery challenging, and it certainly seems that Google decides that losing your account is better than giving it to someone else. There's probably extensive arguments and concerns about how exactly the draw that line, but that's the tension. Your Google account can contain multitudes of personal information, granting it to the wrong person can be crippling to the main owner. Losing access can also be terrible. The other end of this, what do you do when someone presents the right password to log in, is it a hijacking or not? What happens is a risk assessment of the login, is it from the usual location? Usual country? Usual device type? Is it from somewhere where you see a lot of unusual logins? Does it look like some automated software and not a normal browser? How strong is the password? How common is the password? The end result of that risk assessment is whether to let the user in, or to make the login more complicated. That started with captchas, sometimes requiring up to 5 or more of them in the riskiest case. The next level is requiring a phone number. Better if the phone number used was already known to Google, but really any phone number will do because a phone number costs money to obtain, so limiting how many accounts can use a number or how frequently, and you have raised the cost of accessing the account. Of course, then you need to know what all of the free or almost free phone number services are, to not allow those to be used, as they don't cost enough. Of course, if there's money to be made, there's a way, so you get people stealing entire boxes of sim cards and creating special hardware to use them, see the pictures from this article: https://cyberpolice.gov.ua/news/kiberpolicziya-prypynyla-diyalnist-masshtabnogo-servisu-dlya-reyestracziyi-riznyx-akauntiv-u-mesendzherax-soczmerezhax-ta-poshtovyx-servisax-8596/ This isn't about tracking, this is about keeping your data safe, and protecting everyone else from what can be done with a hijacked account, from sending spam to click fraud to YT abuse to bitcoin mining on GCP. In many respects, actually setting up 2FA on your account puts you in a better situation. It means that access to your account is hard to abuse, and so the risk assessment is completely different. Yes, it means that you need to keep both the password and 2FA source secure and available... but that's better than forcing Google to guess at some secondary thing to verify you and choosing wrong. Brandon ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] whose address, was Approach to dealing with List Washing services, industry feedback..
On 26 Jan 2020, at 19:23, Ángel via mailop wrote: On 2020-01-26 at 19:30 +, John Levine via mailop wrote: In article , Andrew C Aitchison via mailop wrote: I have lost enough physical keys over the years to worry about what happens if I lose my phone (which does not have a finger print reader) ... I like TOTP codes because you can install the keys into multiple apps on multiple devices, and since thes keys are just strings of letters and digits, you can print the keys out and put the paper in a safe place. I like them as 2FA solution, too. Simple, standard, offline, vendor neutral, not vulnerable to MITM... Not supported by Google, though. Have you heard of Google Authenticator? I don't use it (their app) but I do use the TOTP codes the provide for it with a Yubikey and in a non-cloudy password manager. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not For Hire (currently) ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..
In article <1580084583.939.2.ca...@16bits.net>, Ángel via mailop wrote: >> I like TOTP codes because you can install the keys into multiple apps ... >Not supported by Google, though. The gmail app on my phone would be surprised to hear that, since I've been logging in with TOTP codes for years. R's, John -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Is there anyone from Telstra Bigpond here?
I've also replied off-list. Cheers, Brad On Mon, 27 Jan 2020, 09:52 Mark Dale via mailop, wrote: > > Hi, > > Is there anyone from Telstra Bigpond here? > > We're seeing list emails from our UK server get blocked, and we've had > no response from postmas...@bigpond.com (who the NDR advises to contact). > > Thanks, > Mark > MailmanLists > > > > > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Is there anyone from Telstra Bigpond here?
see offlist mail On 27/01/2020 08:49, Mark Dale via mailop wrote: > Hi, > > Is there anyone from Telstra Bigpond here? > > We're seeing list emails from our UK server get blocked, and we've had > no response from postmas...@bigpond.com (who the NDR advises to contact). > > Thanks, > Mark > MailmanLists > > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop -- Kind Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore remains confidential and subject to copyright protected under international law. You may not disseminate any part of this message without the authors express written authority to do so. If you are not the intended recipient, please notify the sender then delete all copies of this message including attachments immediately. Confidentiality, copyright, and legal privilege are not waived or lost by reason of the mistaken delivery of this message.___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] Is there anyone from Telstra Bigpond here?
Hi, Is there anyone from Telstra Bigpond here? We're seeing list emails from our UK server get blocked, and we've had no response from postmas...@bigpond.com (who the NDR advises to contact). Thanks, Mark MailmanLists ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..
In article , Andrew C Aitchison via mailop wrote: >I have lost enough physical keys over the years to worry about what >happens if I lose my phone (which does not have a finger print reader) ... I like TOTP codes because you can install the keys into multiple apps on multiple devices, and since thes keys are just strings of letters and digits, you can print the keys out and put the paper in a safe place. -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..
On 2020-01-26 11:32 a.m., Andrew C Aitchison via mailop wrote: On Sun, 26 Jan 2020, Jaroslaw Rafa via mailop wrote: Similar thing happened to me recently when I wanted to re-login to one of those test accounts from my home computer, but I installed a new browser which was not yet used with that account. Usually there are no problems in such a case, but my home Internet connection just went down that day and I had to switch to a backup connection via cellular modem. Probably because of IP address belonging to a generally-accessible mobile operator's pool, Google behaved differently when I logged in to the account. After I already provided a correct password, Google demanded from me to enter a phone number that can be used for verification (!) and I couldn't successfully complete the login procedure, because I didn't want to associate any phone number with that account. Hmm. Proving that you can read a text sent to a number you provide today does not prove that you are the person who used the ID and password yesterday. So they demand you provide a new verification channel so that you can prove your ID *next* time ? I find these multi-factor verifications unsettling because it takes a significant effort to convince myself that the verification does indeed prove what it is supposed to prove and that it is safe from man-in-the-middle. I have lost enough physical keys over the years to worry about what happens if I lose my phone (which does not have a finger print reader) .. I get the feeling this convoluted mechanism with no safe-guards or way-out is less about verification and much more about tracking. Now I just wish there is a mechanism to just delete the account that I can no longer get into. Now it is lost to la-la land. I am who I am, and my email and authentication codes prove it. Why the continuing demand for further verification which no longer exist? Hidden in the recovery mechanism is a statement saying is that someone 'may' look into it, given an email address. Does that actually happen? Or is that just another add-on to their tracking toolings? Frustrated with the inhuman machine, Raymond. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..
On Sun, 26 Jan 2020, Jaroslaw Rafa via mailop wrote: Similar thing happened to me recently when I wanted to re-login to one of those test accounts from my home computer, but I installed a new browser which was not yet used with that account. Usually there are no problems in such a case, but my home Internet connection just went down that day and I had to switch to a backup connection via cellular modem. Probably because of IP address belonging to a generally-accessible mobile operator's pool, Google behaved differently when I logged in to the account. After I already provided a correct password, Google demanded from me to enter a phone number that can be used for verification (!) and I couldn't successfully complete the login procedure, because I didn't want to associate any phone number with that account. Hmm. Proving that you can read a text sent to a number you provide today does not prove that you are the person who used the ID and password yesterday. So they demand you provide a new verification channel so that you can prove your ID *next* time ? I find these multi-factor verifications unsettling because it takes a significant effort to convince myself that the verification does indeed prove what it is supposed to prove and that it is safe from man-in-the-middle. I have lost enough physical keys over the years to worry about what happens if I lose my phone (which does not have a finger print reader) ... -- Andrew C. Aitchison Kendal, UK and...@aitchison.me.uk ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
Dnia 24.01.2020 o godz. 15:11:58 Brandon Long via mailop pisze: > > There is no way to guarantee that a first-time email arrives in the inbox. > > If there was, the spammers would all use it. > > The best you can do is "attach" your email to some existing source of > reputation. > Unfortunately, running your own mail server for 20 years sending <10 > messages > a month to Gmail isn't an existing source of reputation. Where you're > hosting your > mail server is... and it's usually bad. So we are back to beginning, which is basically a statement of "nothing can be done about this". In that case, if Google wants to be honest to their users, you should clearly explain to them somehow (you do have UI specialists, so you probably can think of some good method that won't get unnoticed) what you stated above: that there is no guarantee, that a first time email from a user you don't know and didn't interact with previously, will arrive in your Inbox. Because that's not obvious and that's not what most people would expect from an email service, I guess. For most people it's obvious that if someone sent them an email, they will receive it (of course, an accident may always happen and the email gets lost somehow, but we are talking here about a rule, not about accidents). -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
Dnia 26.01.2020 o godz. 00:15:58 Ángel via mailop pisze:
> The problem is that it seems that Gmail is pulling your leg. A technical
> explanation ("We marked it as spam because the sender says any mails
> sent from that server are not from him [SPF and DMARC link]") would be
> fine, as it would explain what the issue is.
In fact, if the message fails SPF/DKIM/SMARC checks, Gmail displays a yellow
message stating that the mail can be possibly fake, so that's basically waht
you suggest.
> Browsing on the spam folder I found another gmail reason:
> «This message seems dangerous
>
> Similar messages were used to steal people's personal information. Avoid
> clicking links, downloading attachments, or replying with personal
> information.»
> (and it was right, it showed for a netflix phishing mail)
I've seen that message too. It is red, and it is displayed probably - I
guess - when content analysis determined that the message matches known
phishing patterns.
But I was not talking about those specific cases, ie. messages tagged as
fake or phishing, but about messages tagged as "just" spam. In that case
I've seen only that one generic explanation:
> But when a personal message, manually written, sent to one recipient, is
> junked with a reason like "It is similar to messages that were
> identified as spam in the past"¹, while there clearly that was the first
> time gmail would ever have seen that email, that makes you angry with
> the filter nonsense.
[...]
> ¹ What I am seeing on Gmail inteface is slightly different than what
> Rafa reported. Rafa, was yours not a literal copy?
Well, I was using Gmail UI in Polish language, so I had to translate the
actual messages into English first before posting them here :)
--
Regards,
Jaroslaw Rafa
r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..
Dnia 26.01.2020 o godz. 02:30:57 Ángel via mailop pisze: > The safest way to avoid this dance seems to be not to provide > any phone at all (or one for every user, perhaps, which is also > suboptimal). Not providing a phone number at all also doesn't help sometimes. As I have already written, when I had Gmail deliverability problems a few months ago, I created a few Gmail acounts for test purposes. I usually was able to create these accounts without providing any phone number, as long as I was using my home Internet connection. But once I tried to create a new Gmail account from my workplace and Google didn't allow me to create an account without providing a phone number. And I have to admit, they are very good at detecting and rejecting numbers from "scratch SMS" services available on the web (similar to "temporary email", where you can receive a confirmation code via text message without having a real phone number). Probably it was because of the fact that there are thousands of Google users connecting everyday from external IP addresses of my company (apart from employees' personal Google accounts, our company also uses Gsuite, so everybody logs in to their Gsuite account) and that's why they require the additional phone check. Similar thing happened to me recently when I wanted to re-login to one of those test accounts from my home computer, but I installed a new browser which was not yet used with that account. Usually there are no problems in such a case, but my home Internet connection just went down that day and I had to switch to a backup connection via cellular modem. Probably because of IP address belonging to a generally-accessible mobile operator's pool, Google behaved differently when I logged in to the account. After I already provided a correct password, Google demanded from me to enter a phone number that can be used for verification (!) and I couldn't successfully complete the login procedure, because I didn't want to associate any phone number with that account. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
