Re: [mailop] [E] $GOOG

[Laura Atkins via mailop]

> On 17 Apr 2022, at 04:51, John Levine via mailop  wrote:
> 
> It appears that Paul Vixie via mailop  said:
>> srsly? do you really think changing one's domain name or ISP is a 
>> reasonable way forward when google isn't accepting one's e-mail?
> 
> When your domain is a cruddy free one which has earned a poor
> reputation, yes. As I have said a few times, sometimes free services
> are worth what they cost.

What’s remarkable here is that Google’s filtering is normally *incredibly* 
nuanced. They don’t deploy domain or IP level blocks by default or as a first 
response to a problem. There is an escalation path to their spam filtering. 
When they get to the point that they’re blocking IP addresses or domains, it 
means the operator has really, really screwed up for a long time. The times 
I’ve seen widespread IP / domain blocks include (but aren’t limited to): 

1) There’s been ongoing abuse that the operator just ignored for months and 
months. No one noticed that mail from that operator was going to spam, and then 
no one at the operator noticed the short term blocks and notices in their logs. 
The system was running unmonitored and was being abused and finally Google just 
decided that the sender didn’t care if their mail was accepted or not and 
blocked it. 

2) There’s something about the configuration or technical setup that is 
triggering google to determine that the current system isn’t run by someone who 
understands modern email standards. Note: these requirements are higher for 
mail over IPv6 than IPv4 because Google (and many other folks receiving mail) 
expect that if you’re technically progressive enough to send mail over IPv6 
then you can implement authentication, set up FcrDNS, use a EHLO value that 
maps back to the sending IP, set up SPF for EHLO, use TLS, etc. 

3) The provider one is using has a clear history of allowing problematic mail 
(may not just be spam, could be malware or whatever) from their customers. 
Google will block mail with any mention of that provider - in headers, rDNS of 
the connecting IP, body of the message, whatever. I’ve seen less of this 
recently, but I don’t think Google is going to have removed that particular 
tool from their box. 

As I tell my clients: it takes at least as long to repair a reputation as it 
did to break it in the first place. The reality is it can often take longer 
because there’s a lot of bad actors out there and no system can actually be 
trusted to send good mail all the time. 

Fundamentally, though, whether or not we like google’s rules and their 
filtering (or Spamhaus’ or the RBL or UCEProtect or any of the other hundreds 
of services that filter mail) yelling about it on a public mailing list isn’t 
going to get them to change their rules. The people who can make changes are 
the users of the service by pointing out the service isn’t meeting their needs. 
And I say that as someone who has actually gotten multiple providers over the 
years to change their filtering when it was legitimately blocking mail it 
shouldn't. It required a lot of work, a lot of data gathering, and an openness 
to dialog on all sides. 

laura 

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com 

Email Delivery Blog: http://wordtothewise.com/blog  






___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Tobias Fiebig via mailop]

> If your friends somehow believe that Gmail is the only mail provider in the 
> world I suppose I am sorry for them but I don't understand why that is anyone 
> else's problem.

The idea is that you give away something for free, gain significant market 
share (=network effect), and then get into a position where you can first push 
standards (hello MTA-STS), and later can migrate to a walled garden, because 
the default becomes 'if you want it to work, just go to X'. _Then_ you can 
start to monetize either the product (what we see a lot with 'free' EdTech from 
google et al.) _or_ use your market position to ensure the technology develops 
along your product vision (I would argue this is what the chromium engine 
accomplished for the web).

We had this with IE back in the day, now essentially with the chromium engine; 
As I said, we have this quiet a lot with EdTech. We had this with XMPP. And I 
think there are also some bold opinions on protocol suggestions for congestion 
control coming out of google for quick.

So, in a sense, it kind of fits in a general trend of centralization, and 
centralized control; And that may indeed be a problem for people _not_ wanting 
to host their mail with one of N big providers.

And email is simply 'next'. And I don't put any 'nasty' words towards 
Google/gmail here. They just do what an independent actor working in 
self-interest trying to optimize their outcomes does in a given system. 

With best regards,
Tobias

-Original Message-
From: mailop  On Behalf Of John Levine via mailop
Sent: Sunday, 17 April 2022 05:52
To: mailop@mailop.org
Cc: p...@redbarn.org
Subject: Re: [mailop] [E] $GOOG

It appears that Paul Vixie via mailop  said:
>srsly? do you really think changing one's domain name or ISP is a 
>reasonable way forward when google isn't accepting one's e-mail?

When your domain is a cruddy free one which has earned a poor reputation, yes. 
As I have said a few times, sometimes free services are worth what they cost.

>i think you could have punctuated that sentence after "operators". but 
>google is a "shabby mail operator" (your words) who has taken my 
>friends and family as hostages. ...

What we have here appears to be reverse Stockholm syndrome.

Google gives away Gmail accounts for free. It is clear that Gmail users are 
getting at least what they've paid for, and in many cases more than that.

If your friends somehow believe that Gmail is the only mail provider in the 
world I suppose I am sorry for them but I don't understand why that is anyone 
else's problem.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Rob Nagler via mailop]

Having run smallish mail servers for about four decades, the oppressors
have won "mostly" for me. This week/end I am migrating my partner's
single-person firm's domain to Google Workspace. This thread is topical,
interesting, and hilarious to skim. Indeed, as I sat down to write this I
received "Everything you need for work – right in Gmail" from Workspace.
Not!

The first migration (RadiaSoft) happened over a year ago, and I'm
relatively happy I did it although one of my co-workers is getting PTSD
from Google Drive's weird behavior on her Macbook. I cannot migrate all my
domains, e.g. the one I'm sending this from, but I probably would.

Laura, did you notice the To line in the email to which I am replying is
"Bill Cole via mailop ". While I really enjoyed your
message(s), I think this is the crux of the problem(s) with "computers
these days". Why does mailop mail sometimes take hours to get to me? Why
was the certificate on the website broken for so long? Is it still? Where
is my message going to go when I see "Bill Cole via mail op" in my MUA? Why
does visiting https://mazda.com result in Forbidden? Inquiring minds would
like to know. Or maybe it's just me and my pedant for little details like
that.

Why migrate a tiny domain? Spam. She's a real estate agent and her address
is public and in lots of people's address books. Spam, spam, spam. I try to
filter it with tools like Spamassissin, Postgrey, "sleep 8", and so on. I
gave up running an MUA years ago. I tell people to use Gmail, perhaps
that's wrong, but it's kind of what people did in the day with tiny
domains. Zoho had such a bad email reputation that I had to migrate
RadiaSoft off it on to our own servers. I certainly couldn't recommend
ad-infested MUAs like Yahoo. Gmail seemed like a good thing, and they
weren't as evil back then.

It's funny to me that people are saying "Google is just monetizing". Not as
such. More like an anarcho-syndicalist commune or the Ben & Jerry's of the
Internet. They didn't invent ad-monetized search (or ice cream). They make
money off it, and more power to them. Yet the rest of their stuff seems
like unmanaged chaos.

For the uninitiated, you cannot convert f...@gmail.com to foo.com to
Workspace without some effort. Mail can be migrated relatively easily.
Drive cannot be migrated to Drive according to Google. Fun tidbit: Drive
allows two files with exactly the same name. Oh, and you can have two
YouTube channels with the same name. Rilly?

You can migrate Drive thanks to Rclone . Though, it
took me most of the day to figure out how to get Google's Service Accounts
to work. Mail migration is only about 35 clicks and is running, but it is
going to take a week for one account, which of course is
embarrassingly parallel, so it shouldn't. Yesterday, in under an hour, I
migrated an entire site from my current colo to Linode with 100GB+
transactional SQL and files. Why is Drive to Drive not just a few clicks
like mail? It's even less complicated.

At one point this weekend, my lovely partner said "maybe I should just use
f...@gmail.com. Everybody has a gmail address, it's normal." This after
years spending time SEOing (more oppression) her own domain. Needless to
say I nearly tore my hair out at that point. She had been complaining
about having to "pop" her mail into Gmail account from her laptop (not
possible on the phone) manually for years, which finally prompted the
migration (along with a colo failure, below). She thought it was Google's
business plan to make it so difficult to switch from free to fee that she
wanted to go back to free and destroy her decade worth of brand building.
Gardners do it, which shouldn't she?

As 6p was approaching, she asked "are you going to be able to switch
gears?" Fortunately, I got a successful directory listing from rclone, and
I was ready to have dinner with friends. If I had not figured it out,
dinner would have been ruined by me talking with one of the people about
his experience with GCP and Service Accounts. As they were leaving, he
mentioned the colo failure (wait for it) and I talked about the migration
to Linode, and he said "What's Linode?" He assumed the world ran on AWS,
Azure, and reluctantly GCP. "How do they make money?" Another dimension to
this "oppression".

I am being oppressed by my one-data-center colo right now, which was down
for TWO DAYS a couple of weeks ago. I've been oppressed into this migration
to Linode and another DC, because they not only didn't keep their network
up for two days but failed miserably to let their customers know what was
going on. I still don't know, and I don't care.

One of my co-workers who is early career is helping with the colo-part of
the migration. He has never worked in a DC nor really done much with server
hardware. He's a serverless-cloud kinda person. He said to me the other
day, "I was thinking about you carrying a pager back in the day, and I
realized that I don't want to do that." More power to him, frankl

Re: [mailop] [E] $GOOG

[Jim Popovitch via mailop]

On Sun, 2022-04-17 at 11:06 -0600, Rob Nagler via mailop wrote:
> Laura, did you notice the To line in the email to which I am replying
> is "Bill Cole via mailop ". 


The reason you see that is because your MUA is auto-saving email
addresses of the people that email you. The "Bill Cole via mailop" is a
DMARC mitigation feature of Mailman.  Sometime in the past you received
an email from MailOP, that originated by Bill, and your MUA nicely saved
it for you (albeit I would argue that your MUA incorrectly saved it for
you).

-Jim P.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[John Levine via mailop]

It appears that Tobias Fiebig via mailop  said:
>> If your friends somehow believe that Gmail is the only mail provider in the 
>> world I suppose I am sorry for them but I don't understand why that is 
>> anyone else's problem.
>
>The idea is that you give away something for free, gain significant market 
>share (=network effect), and then get into a position where you can first push 
>standards (hello
>MTA-STS), and later can migrate to a walled garden, ...

Uh, what? Google follows public mail standards at least as well as
their large competitors like YahAOL and Microsoft. You do not have to
like MTA-STS, but it's an open IETF standard and there's a lot more
providers than Google that use it.

>We had this with IE back in the day, now essentially with the chromium engine; 

Chromium is open source, and there are dozens of browsers built on it.  Could 
you
explain what the problem is?

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Tobias Fiebig via mailop]

> Uh, what? Google follows public mail standards at least as well as their 
> large competitors like YahAOL and Microsoft. You do not have to like MTA-STS, 
> but it's an open IETF standard and there's a lot more providers than Google 
> that use it.

I was not arguing that google is not following mail standards. I _would_ argue 
thought that there is a discussion that _could_ be had regarding the 
sensibility of MTA-STS' design including HTTP; And what hits my rua currently 
mostly looks like google to me; But I am looking forward to reports from MS et 
al.

However, the point I actually did try to make, though, was indeed that mail is 
increasing in complexity, and 'the big ones' get things in order (well, apart 
from those mismatching DNS/EHLO setups from MS), while the tail of 
non-centralized setups does not keep up, ultimately leading to a 
mono/multipolization and aggregation of the ecosystem, essentially changing it 
from 'open' to 'something only big companies can take part in'. 

> Chromium is open source, and there are dozens of browsers built on it.  Could 
> you explain what the problem is?

Which, again, is exactly my point. Chromium, by now, drives the majority of 
browsers, in part because it is open source, and also because it is really good 
at what it does. Still, I would argue that the majority of contributions to 
that codebase comes from google employees. Or, to underline who makes product 
decissions for chromium, from the git log: "Do not revert without consulting 
chrome-...@google.com" Hence, this open source core puts google into a position 
where they could simply decide the direction into which the web goes.

Also, as a disclaimer: The core of this argument is not about whether google 
(or any other player in a comparable market position for a specific ecosystem; 
Think of Cisco in the past for networking, MS for OS in the past etc.) _would_ 
leverage their power to further their own interests, or are generally 'the bad 
ones'. I _personally_ would argue that utilizing that power to leverage their 
own interests is a reasonable expectation if they are an economically working 
actor. Independent of one's own answer to that question, though, the _real_ 
question is whether it is good for the Internet and society at large if 
individual actors get into a position where they _could_ leverage their pull on 
the ecosystem; And, to be fair, google has been using that power for good 
things as well; See, for example, the phase-out of plain http, which I would 
attribute--in large parts--to the chrom(e|ium) decissions around handling http. 
Still, the question remains; What ecosystem do we want a society to run on?

With best regards,
Tobias


-Original Message-
From: mailop  On Behalf Of John Levine via mailop
Sent: Sunday, 17 April 2022 19:42
To: mailop@mailop.org
Cc: tob...@fiebig.nl
Subject: Re: [mailop] [E] $GOOG

It appears that Tobias Fiebig via mailop  said:
>> If your friends somehow believe that Gmail is the only mail provider in the 
>> world I suppose I am sorry for them but I don't understand why that is 
>> anyone else's problem.
>
>The idea is that you give away something for free, gain significant 
>market share (=network effect), and then get into a position where you can 
>first push standards (hello MTA-STS), and later can migrate to a walled 
>garden, ...

Uh, what? Google follows public mail standards at least as well as their large 
competitors like YahAOL and Microsoft. You do not have to like MTA-STS, but 
it's an open IETF standard and there's a lot more providers than Google that 
use it.

>We had this with IE back in the day, now essentially with the chromium 
>engine;

Chromium is open source, and there are dozens of browsers built on it.  Could 
you explain what the problem is?

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[John Levine via mailop]

It appears that Tobias Fiebig via mailop  said:
>> Uh, what? Google follows public mail standards at least as well as their 
>> large competitors like YahAOL and Microsoft. You do not have to like 
>> MTA-STS, but it's an open IETF
>standard and there's a lot more providers than Google that use it.
>
>I was not arguing that google is not following mail standards. I _would_ argue 
>thought that there is a discussion that _could_ be had regarding the 
>sensibility of MTA-STS'
>design including HTTP; And what hits my rua currently mostly looks like google 
>to me; But I am looking forward to reports from MS et al.

We spent months working out the details, including why it uses HTTPS
rather than DANE, on public mailing lists in the IETF. (I would have
preferred DANE, but the choice of HTTPS was not made casually.) If
this is something you care about, where were you?


>However, the point I actually did try to make, though, was indeed that mail is 
>increasing in complexity, and 'the big ones' get things in order (well, apart 
>from those
>mismatching DNS/EHLO setups from MS), while the tail of non-centralized setups 
>does not keep up, ultimately leading to a mono/multipolization and aggregation 
>of the
>ecosystem, essentially changing it from 'open' to 'something only big 
>companies can take part in'. 

When I look at the vast number of operators of different sizes
successfully running mail servers, that's not a persuasive argument.

I have certainly run into plenty of people who've had trouble getting
their mail into Gmail, loudly announced that GMAIL HAS BROKEN MAIL FOR
EVERYONE IN THE WORLD, then I take a look and say "do you know what SPF
is?"  "No, why do you ask?"  Sigh.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Bill Cole via mailop]

On 2022-04-16 at 23:12:19 UTC-0400 (Sun, 17 Apr 2022 05:12:19 +0200)
Paul Vixie via mailop 
is rumored to have said:


Bill Cole via mailop wrote on 2022-04-15 17:47:
On 2022-04-15 at 08:37:54 UTC-0400 (Fri, 15 Apr 2022 14:37:54 +0200) 
Jaroslaw Rafa via mailop  is rumored to have said:



Dnia 14.04.2022 o godz. 12:40:52 Al Iverson via mailop pisze:

Yes, it is unfixable. Once Google's AI decides (for no apparent
reason) that it will reject e-mails from you, or put them to
recipients' spam folder, there's pretty much nothing you can do
about it.


That is false.


I can believe your claim that "that is false" if you can give me a
WORKING advice of what can I do to make my e-mails get to the
Google's inbox. Other than "change your ISP" or "change your
domain", as this is NOT A SOLUTION, as I already stated.


OK, so you know why Google rejects your mail and how you could fix
it, if you wanted to have your mail accepted instead of having a
solid point to argue here.

So the text that Al quoted is not actually true. There IS an apparent 
reason and there IS something you could do about it.


srsly? do you really think changing one's domain name or ISP is a 
reasonable way forward when google isn't accepting one's e-mail?


Reasonableness is case-specific Or "subjective" if you prefer...

If it is the *only* clearly working way forward, I'm not sure how that 
modifies or interacts with whether it is "reasonable." If you want to do 
something, you do it in a way that works, right?


and does anyone think my friends and family who use google as their 
mailbox provider would be glad google had taken that approach to my 
e-mail? (don't make me say "survivorship bias" please.)


I have no useful opinion on what unfamiliar-to-me 3rd parties would 
think.



If you still think this is fixable, then give me a working fix.


Don't try to send mail to shabby mail operators with a domain that
they can't distinguish from similar ones that they correctly know to
be used as throwaways.


i think you could have punctuated that sentence after "operators".


It certainly would radically change the meaning from what I said...

but google is a "shabby mail operator" (your words) who has taken my 
friends and family as hostages. i cannot be expected to like this, or 
thank them for it, or respect them for it. "we're the phone company, 
we don't care, we don't have to" hasn't gotten more appealing across 
the decades.


I would never dream of expecting you or anyone else to like or respect 
Google. I don't consider that a prerequisite for interop.


In the context I was replying to (Mr. Rafa's well-publicized 
difficulties rooted in use of a de facto registry under a 2LD,) there 
really are 2 options: use a different domain without a reputational 
problem or just live with deliverability issues and hope that eventually 
having recipients mark stuff as "not spam" has an effect on the holy 
Algorithm.



I am NOT saying that what Google is doing is "right" in some way that
doesn't assume a Google corporate viewpoint. It's not. It's stupid
and wrong, unless one is primarily concerned with Google's short-term
financial bottom line.


i'm with you there.


But as Al said, it is simply false that they are acting at random or
that their deterministic blundering cannot be worked around.
their capricious opacity isn't helping them or us, but is hurting them 
and us, and amounts to the same kind of cost-shifting that we all seem 
to hate when spammers do it.


Yes. The same is true of many things we do for deliverability. We live 
in the world we were all trying to prevent 20+ years ago.



"cannot be worked around" is not the standard under discussion, btw.


Context matters.

Also, I'm not sure any other standard is useful for deliverability in 
2022. Are Fastmail, Protonmail, Runbox, Tucows, etc. really better than 
Google, MS, or Yahoo at accepting non-spam or are they just smaller 
enough that they haven't yet blocked one of the rare folk who speak up 
about it where I can see it? I have no way to know. I know that the 
mailbox providers I've worked with have at times rejected legitimate 
mail, albeit not knowingly & persistently, because their mailbox users 
are their customers. That's less true of the freemail providers who've 
expanded into outsourcing corporate mail. One thing that sets the Big 
Guys apart is that they all appear to be happy with not delivering 
wanted mail to the INBOX if a sender doesn't meet their arbitrary 
standards. I don't know how big a mailbox provider needs to be to adopt 
that attitude. I'm fairly certain that no amount of outrage from 
middle-aged sysadmins can move the needle on it, so I've stopped being 
outraged at needing to work around the stupidity.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://lis

Re: [mailop] Fwd: RFC 9228 on Delivered-To Email Header Field

[Paul Gregg via mailop]

On Thu, Apr 14, 2022 at 06:34:07AM -0700, Dave Crocker via mailop wrote:
> 
> Folks,
> 
> This was just issued. It will aid in evaluating handling history of a
> messsage, especially through aliasing and mailing list sequences.
> 
> d/
> 
>  Forwarded Message 
> Subject: RFC 9228 on Delivered-To Email Header Field
> Date: Wed, 13 Apr 2022 23:04:21 -0700 (PDT)
> From: rfc-edi...@rfc-editor.org
> To: ietf-annou...@ietf.org, rfc-d...@rfc-editor.org
> CC: rfc-edi...@rfc-editor.org, drafts-update-...@iana.org
> 
> A new Request for Comments is now available in online RFC libraries.
> 
> RFC 9228
> 
> Title:  Delivered-To Email Header Field
> Author: D. Crocker, Ed.
> Status: Experimental
> Stream: Independent
> Date:   April 2022
> Mailbox:dcroc...@bbiw.net
> Pages:  10
> Updates/Obsoletes/SeeAlso:   None
> 
> I-D Tag:draft-crocker-email-deliveredto-10.txt
> 
> URL:https://www.rfc-editor.org/info/rfc9228
> 
> DOI:10.17487/RFC9228
> 

Whilst I understand the Delivered-To: header isn't explicitly codified
in an RFC - I don't think there is anything here that we haven't all been
using for a *long* time already.

Author seems to argue that 'new' use is list explosion and forwarding
which is trivially disproven by prior-art.

Specifically DJB's draft of 26 years ago:
https://datatracker.ietf.org/doc/html/draft-bernstein-mail-loops-war-00
which explicitly calls out such uses as Dave thinks is new.

Sure, ressurect the proposal and push for standards track - but credit
needs to go to Dan, not Dave.

PG
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Tobias Fiebig via mailop]

Heho,
> We spent months working out the details, including why it uses HTTPS rather 
> than DANE, on public mailing lists in the IETF. (I would have preferred DANE, 
> but the choice of HTTPS was not made casually.)
To clarify, my comment did not want to pull the found consensus into question, 
and I do not doubt that there are good reasons _for_ HTTPS at this level. This 
comment relates more to issues in the operational implementation I encountered 
when I (recently) implemented MTA-STS; The most pressing one that the MTA-STS 
policy is bound to the recipient domain, which means that I can not simply roll 
it out for all my MX, iff they are accepting mail for domains where I do not 
control the DNS, and my favorit MTA not supporting MTA-STS, because they do not 
want to include an HTTP client. However, I also assume that such issues were 
indeed discussed, and a tradeoff happened.

> If this is something you care about, where were you?
This one hurts, mostly because I know where I was, and also know where I rather 
would have been, doing what. ;-)

> I have certainly run into plenty of people who've had trouble getting their 
> mail into Gmail, loudly announced that GMAIL HAS BROKEN MAIL FOR EVERYONE IN 
> THE WORLD, then I take a look and say "do you know what SPF is?"  "No, why do 
> you ask?"  Sigh.
I think this gets to the core of why centralization for many things is 
succesfull in the first place (leaving the whole good/bad/intention discussion 
out of it). Running systems is not easy; Especially for basic infrastructure 
(which email is), it should just _work_. Then again, over the past three 
decades, it also got _a lot_ more complex (see [0] for my favorit summary on 
that); There is also some work I was involved in which I hope to be able to 
share with the list by the end of the month, goin into the direction of "good 
setups" w.r.t. mail hosters, and the results align pretty much with your 
observation there.

However, it also circles back to the age old question (among people sceptical 
of centralization) of how we can have more distributed infrastructure, without 
having it a) constantly break, b) crappily maintained, and thereby c) causing 
more issues than it solves. At the moment, I sadly do not yet have a good 
answer for that, and I suspect that it won't have a technical answer at all. 

With best regards,
Tobias

[0] 
https://dataswamp.org/~solene/2021-07-09-obsolete-feeling-in-the-crossfire.html

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Andrew C Aitchison via mailop]

On Sun, 17 Apr 2022, Bill Cole via mailop wrote:

On 2022-04-16 at 23:12:19 UTC-0400 (Sun, 17 Apr 2022 05:12:19 +0200)
Paul Vixie via mailop 
is rumored to have said:

> Bill Cole via mailop wrote on 2022-04-15 17:47:
> > Don't try to send mail to shabby mail operators with a domain that
> > they can't distinguish from similar ones that they correctly know to
> > be used as throwaways.
>
> i think you could have punctuated that sentence after "operators".

It certainly would radically change the meaning from what I said...


I am now confused.
Are you suggesting that
 a) the sender or
 b) the shabby mail operator
should not have a domain that may be seen as throwaway ?

--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Bill Cole via mailop]

On 2022-04-17 at 18:11:16 UTC-0400 (Sun, 17 Apr 2022 23:11:16 +0100 
(BST))

Andrew C Aitchison via mailop 
is rumored to have said:


On Sun, 17 Apr 2022, Bill Cole via mailop wrote:

On 2022-04-16 at 23:12:19 UTC-0400 (Sun, 17 Apr 2022 05:12:19 +0200)
Paul Vixie via mailop 
is rumored to have said:


Bill Cole via mailop wrote on 2022-04-15 17:47:

Don't try to send mail to shabby mail operators with a domain that
they can't distinguish from similar ones that they correctly know 
to

be used as throwaways.


i think you could have punctuated that sentence after "operators".


It certainly would radically change the meaning from what I said...


I am now confused.


I may have been confused by Paul's meaning. Would not be the first time. 
Looking at it again I think I see it...



Are you suggesting that
 a) the sender or
 b) the shabby mail operator
should not have a domain that may be seen as throwaway ?


Sender. Better edit:

Don't try to send mail to shabby mail operators, using a domain 
that
they can't distinguish from similar ones that they correctly know 
to

be used as throwaways.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] does ESP have the preference for email domains

[wilson via mailop]

Hello

some people told me not to use .xyz domain b/c it's more spammers liked.
may I ask if the big ESP or the open antispam policies have the 
preference on domains? such as com/net/org is preferred, but xyz/top/pro 
is not.


Thanks
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Bob Proulx via mailop]

Tobias Fiebig via mailop wrote:
> Running systems is not easy; Especially for basic infrastructure
> (which email is), it should just _work_.
...
> However, it also circles back to the age old question (among people
> sceptical of centralization) of how we can have more distributed
> infrastructure, without having it a) constantly break, b) crappily
> maintained, and thereby c) causing more issues than it solves. At
> the moment, I sadly do not yet have a good answer for that, and I
> suspect that it won't have a technical answer at all.

The main problem is that at the same time that people are trying to
fix things and make things work there are other people who are trying
to break things and make things fail.  Scammers and spammers and other
miscreants work against the public good.  The good guys working to
make things work are clever.  Unfortunately the bad guys working to
make things fail are also clever.  We are in the middle of a battle
between these two forces.  It is as yet unclear which side will win in
the end but we are not at the end yet.

Bob
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] good vs bad $GOOG

[John Levine via mailop]

It appears that Bill Cole via mailop  said:
> One thing that sets the Big 
>Guys apart is that they all appear to be happy with not delivering 
>wanted mail to the INBOX if a sender doesn't meet their arbitrary 
>standards.

All the mail providers I know of whatever size basically work from
user complaints. I would also distinguish between "wanted" mail and
"tolerated" mail.  I expect my small system rejects some mail that my
users wouldn't object to receiving, but if they don't notice and tell
me, I don't care.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Paul Vixie via mailop]

1,$/oppress/p

Rob Nagler via mailop wrote on 2022-04-17 19:06:

Having run smallish mail servers for about four decades, the oppressors ...
... This after years spending time SEOing (more oppression) 
... Another dimension to this "oppression".
... I am being oppressed by my one-data-center colo right now, which was 
down for TWO DAYS a couple of weeks ago. I've been oppressed into this ...


thank you for this demonstration; it was illuminating.

--
P Vixie

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Paul Vixie via mailop]

Bill Cole via mailop wrote on 2022-04-17 22:56:

...

Reasonableness is case-specific Or "subjective" if you prefer...


it is not. no member of my circle of mailman subscribers who live inside 
the googplex would consider google's opaque requirement that i renumber 
my mailserver "reasonable". that's the definition which matters.


they weren't consulted and won't be. google knows that the threshold for 
nonattraction is mostly not related to the threshold for alienation. "we 
don't care, we don't have to, we're the phone company" was not funny the 
first time and isn't funny now.


If it is the *only* clearly working way forward, I'm not sure how that 
modifies or interacts with whether it is "reasonable." If you want to do 
something, you do it in a way that works, right?


yikes.

--
P Vixie

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Paul Vixie via mailop]

Bob Proulx via mailop wrote on 2022-04-18 02:23:

...

The main problem is that at the same time that people are trying to
fix things and make things work there are other people who are trying
to break things and make things fail.


that's not a dichotomy.


Scammers and spammers and other
miscreants work against the public good.  The good guys working to
make things work are clever.  Unfortunately the bad guys working to
make things fail are also clever.  We are in the middle of a battle
between these two forces. ... 


there are many more than two forces. for example, outside of the 
distinction you draw, are forces acting to improve their operating 
conditions (like getting home in time for dinner or not getting paged on 
the weekend or trying to ensure their company's future competitiveness) 
whose resulting impact is perceived by many other actors with the same 
goal ("improve their operating conditions") consider to be harmful.


all of these actors might be "trying to make things work" but be taking 
a naive or ignorant or provincial or subjective view of both "things" 
and "work".


none of these actors might think of themselves as miscreants or even be 
thinking in terms of the public good.


--
P Vixie

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Bob Proulx via mailop]

Paul Vixie via mailop wrote:
> all of these actors might be "trying to make things work" but be taking a
> naive or ignorant or provincial or subjective view of both "things" and
> "work".

By trying to make things work I was thinking of SPF, DKIM, DMARC,
DANE, and DNSBLs, and other, and the list goes on.  To keep the noise
down so that email is usable.

(I might predict that a decade from now all of those will be considered
completely obsolete and it will be a completely new set of defenses
with new set of requirements.  Except instead I think it will be all
of those and additionally that same amount again of something new and
different.  It's difficult to learn all at once now.  It's hard enough
keeping up with the developments as they develop.)

> none of these actors might think of themselves as miscreants or even be
> thinking in terms of the public good.

I was mosty thinking of the spammers who are always trying new things
in order to slip their messages through the filters.  Which breaks
things.  Because spam noise is so bad people on the receiving end
react in often reactionary ways (Please make it stop!) and then break
things in order to avoid the noise.  I don't really blame them.  Any
port in a storm.

We all have taken shortcuts that we hoped were temporary to reduce a
problem somewhat.  Block an IP address?  Sure.  The /24 neighborhood?
Yup.  It's from OVH, Digital Ocean, Linode?  Let's block all of that
hosting center.  Just examples of behavior I think is undesirable.
(Yet I definitely have /24 networks in my own block lists.)

But that really creates problems for the concept of distributed email.
If any operator that is NOT Too Big To Block has their entire hosting
network blocked then only those that are Too Big To Block will remain.
And those very small ones that no one knows about.  With nothing in
between.  The big get bigger and the small get smaller.

Bob


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Paul Vixie via mailop]

Bob Proulx via mailop wrote on 2022-04-18 05:59:

Paul Vixie via mailop wrote:

all of these actors might be "trying to make things work" but be taking a
naive or ignorant or provincial or subjective view of both "things" and
"work".


By trying to make things work I was thinking of SPF, DKIM, DMARC,
DANE, and DNSBLs, and other, and the list goes on.  To keep the noise
down so that email is usable.


that's fair. note that the original RBL (at MAPS, this was) was an 
attempt (by me, and then by others) to "keep the noise down so that 
e-mail is usable". you should be able to verify from where you sit that 
(a) we did not achieve that goal, (b) we achieved a number of other 
deleterious non-goals, and (c) we were not universally hailed as 
liberators by others who thought they knew better what "the public 
interest" actually was.



(... It's difficult to learn all at once now.  It's hard enough
keeping up with the developments as they develop.)


and for the record, when google started bouncing my e-mail because i 
didn't have DKIM and SPF set up, i was a little annoyed but a lot more 
embarrassed. it wasn't until i'd fixed everything they demanded but they 
were still bouncing my e-mail and not telling me why that i got a lot 
annoyed. once they invited their first billion mailboxes to shelter 
behind their spam defense, they acquired the obligations of nobility.



...

We all have taken shortcuts that we hoped were temporary to reduce a
problem somewhat.  Block an IP address?  Sure.  The /24 neighborhood?
Yup.  It's from OVH, Digital Ocean, Linode?  Let's block all of that
hosting center.  Just examples of behavior I think is undesirable.
(Yet I definitely have /24 networks in my own block lists.)


for the record, when vernon schryver and i developed the DNS version of 
all this (called RPZ; see it on the web at dnsrpz.info) my first ruleset 
for my own RDNS servers was to accept TCL.TK but deny resolution for all 
other *.TK names. what a relief! so i grok your cost:benefit concerns.



But that really creates problems for the concept of distributed email.
If any operator that is NOT Too Big To Block has their entire hosting
network blocked then only those that are Too Big To Block will remain.
And those very small ones that no one knows about.  With nothing in
between.  The big get bigger and the small get smaller.
centralization is the capital-amplifying way to scale things. i know 
that google has a hard problem in accepting e-mail from small domains 
and that their life would be easier if they only had to worry about the 
big ones. however, they're the centralizer, so the burden is theirs. i 
was he who first coined the phrase "their network, their rules" but i 
did not realize that the future held many operators who were "too big to 
care" on the receiving side. in my present at that time (1996 or so) the 
only "too big to care" entities were on the sending side. ouch.


--
P Vixie

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] does ESP have the preference for email domains

[Byung-Hee HWANG via mailop]

Dear wilson,

wilson via mailop  writes:

> Hello
>
> some people told me not to use .xyz domain b/c it's more spammers liked.
> may I ask if the big ESP or the open antispam policies have the
> preference on domains? such as com/net/org is preferred, but
> xyz/top/pro is not.

Well i have no trouble with Gmail(Google Servers) and most mailing list
servers such as Debian Project, GNU Project, etc., ...

> Thanks

Thanks, too!

Sincerely, Linux fan Byung-Hee

-- 
^고맙습니다 _布德天下_ 감사합니다_^))//
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop