Re: [mailop] [E] $GOOG

[Paul Vixie via mailop]

Laura Atkins via mailop wrote on 2022-04-25 02:19:

...

https://www.spamhaus.com/custom-content/uploads/2022/04/Botnet-Report-Q1-2022.pdf

...

Spamhaus ultimately concludes that section: "It’s evident that where 
there’s a freebie, there’s abuse!”


laura


spam in hand or it didn't happen.

--
P Vixie

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

Re: [mailop] [E] $GOOG

[Laura Atkins via mailop]

> On 15 Apr 2022, at 18:29, Luis E. Muñoz via mailop  wrote:
> 
> 
> Dnia 15.04.2022 o godz. 16:53:11 Laura Atkins via mailop pisze:
> 
> "EU.org, free domain names since 1996”
> 
> You quoted that. Eu.org is a *domain registrar*. Only. They don't offer any 
> email service and never did. So how can they "police users for email"?
> 
> Do you know any paid domain registrar - for example for .com domain - that 
> "polices users for email", if they don't host any email for the user?
> 
> There are many who claim that there's a correlation between easily, cheap (or 
> free) domain names and spam. Their rationale is that spammers can secure 
> disposable domain names for very low price.
> 
> Therefore, they claim, domain names meeting that criteria need to be 
> subjected to additional scrubbing. Less sophisticated receivers could simply 
> opt to reject while providers with more sophisticated mechanisms could 
> implement that "additional scrubbing" in the form of tighter tolerances, 
> starting the "reputation calculation" from a lower value or whatever makes 
> sense to them.
> 
> Their common goal according to this narrative, is to reduce the amount of 
> spam these mailbox providers have to deliver to their products/clients.
> 
The most recent Spamhaus botnet update report addresses this very nicely and 
provides direct evidence that free domain registrations are heavily abused. 

https://www.spamhaus.com/custom-content/uploads/2022/04/Botnet-Report-Q1-2022.pdf
 


"A more detailed review of our data reveals that the majority of fraudulent 
domain registrations within Freenom’s TLDs are not linked to highly advanced 
and sophisticated threat actors, but users of freely available crimeware kits 
that they have bought for a few bucks on the dark web. These somewhat “amateur” 
threat actors do not have the same financial resources as more “professional” 
cybercriminals. Therefore, it is no surprise that they try to (ab)use services 
that are available for free – such as Freenom offers.” 

Spamhaus ultimately concludes that section: "It’s evident that where there’s a 
freebie, there’s abuse!” 

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

[Simon Wilson via mailop]

The systems may not *strictly* require a Gmail account, only a Google
account,


Your adding "strictly" does not change the fact that a Gmail account  
is not required.



but that doesn't mean it is not perceived as such.


Sure, the Google account sign-up page offers to create a Gmail address  
for you, but it has immediately underneath that in bold font "Use my  
current email address instead".


However we are digressing somewhat from the thread...



However, even if it isn't actually a hard requirement, if it is
perceived as a requisite to use the software, there is still such
effect.



The comment I responded to was:


People are forced to get a Gmail account...


They are not, as you have also acknowledged. They are offered it, as  
one would expect, but clearly given an alternate option.






--
Simon Wilson
M: 0400 12 11 16

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

Re: [mailop] [E] $GOOG

[Ángel via mailop]

On 2022-04-18 at 19:32 +1000, Simon Wilson wrote:
> *Completely* and objectively not true.
> 
> I've run Android phones for many years with a Google account based on  
> my own personal non-Gmail email. I have never activated or used Gmail,  
> and at no stage has an Android phone ever tried to force me to use  
> Gmail.
> 
> When using Android without Gmail, at no stage in the "defaults" or  
> "preinstalled apps" is this anything other than "enter your Google  
> account email address and login"-difficult to achieve.
> 
> > > or for a number of other reasons related to other services.
> 
> Without knowing what "other services" you refer to, it's hard to be  
> specific, but I use a lot of Google services without having a Gmail  
> account without any difficulties. Which services (specifically) do you  
> have in mind that are forced to use Gmail?

The systems may not *strictly* require a Gmail account, only a Google
account, but that doesn't mean it is not perceived as such.

I still remember how, many moons ago (i.e. 20 years back), I was
introduced to MSN Messenger¹ and when asking what it required, told
that in order to use it I needed a hotmail account.

Was it accurate? No. What it actually required was a Microsoft Passport
account (later renamed Windows Live ID), which could be added onto an
email address by a different provider (something I only learned time
later).

However, even if it isn't actually a hard requirement, if it is
perceived as a requisite to use the software, there is still such
effect.


Best regards


¹ https://en.wikipedia.org/wiki/MSN_Messenger


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

Re: [mailop] [E] $GOOG. Domain age?

[Ángel via mailop]

On 2022-04-16 at 14:26 +0200, Jaroslaw Rafa via mailop wrote:
> Dnia 15.04.2022 o godz. 20:18:54 John Levine via mailop pisze:
> > > You quoted that. Eu.org is a *domain registrar*. Only. They don't
> > > offer any
> > > email service and never did. So how can they "police users for
> > > email"?
> > 
> > They can turn off people when they get credible spam reports.
> 
> Maybe they do. Honestly, I don't know as I'm not a spammer. What I know is
> that they explicitly state in their policy that you cannot use the domain to
> spam. This doesn't have to translate to any actual action against spammers,
> but it can.
> 
> Is there anybody here who knows for sure?
> 
> Also, as I have mentioned in another mail, it takes some effort and quite a
> lot of time to get an .eu.org domain up and running. Free doesn't mean it's
> a few clicks and you're set. Having to wait 10 days or so until your domain
> is manually accepted doesn't make it an attractive option for spammers. It's
> an "old school" service and their registration process is clearly oriented
> towards people interested in using the domain for long time.

It's a long shot, but I wonder if this may be related to their whois
not showing the creation date.

The age of a domain has long been an important feature when measuring
the worthiness of domain. Typically a domain registered last month
would be seen more suspiciously than one registered 15 years ago.

So I am certain this feature is taken into account by Google. However,
a whois of you domain does not show a creation date (there are old
changed: lines, but a system should not need to look at them as a
fallback). I don't know how Google actually measures domain age (whois
queries don't seem a likely way, but e.g. eu.org is unlikely to be in
the CZDS, either), but if it doesn't provide a registration date (which
for a niche pseudo-TLD like this doesn't seem much likely to be
noticed), old domains like yours would be grouped the same as
completely new ones.


Regards


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

Re: [mailop] [E] $GOOG

[Ángel via mailop]

On 2022-04-24 at 00:44 +0200, Jaroslaw Rafa via mailop wrote:
> Dnia 23.04.2022 o godz. 14:48:05 Dan Mahoney via mailop pisze:
> > I would LOVE there to be legal structure to say “Gee, Equifax, you failed
> > to demonstrate the basic opsec of paying some junior admin to type `yum
> > upgrade apache-struts`, so you don’t get to keep my PII anymore.” I would
> > love if there was an option to simply put a flag on my SSN that says
> > “gather/sell no data” to any of the dozens of agencies that harvest this
> > (radaris et al) and package it up neatly.
> 
> Isn't European GDPR something that is supposed to achieve exactly
> this?
> 
> Yes, it doesn't work perfectly, and there are multiple companies that try to
> go around it in multiple ways, but it's a step in good direction IMHO.
> 
> At least at the moment when GDPR came into effect I observed a BIG drop in
> amount of spam coming to my server. And still, after several years, it
> didn't return to pre-GDPR quantities yet...
> 
> Of course YMMV, especially outside Europe...

Yes, I don't think GDPR would allow Equifax to process this data.* But
AFAIK they mostly work with USA data.

What made this incident completely embarrassing was that the apache-
structs vulnerability had been known for a very long time (6-9 months?)
and widely publicised. One might understand a small company not
"getting the memo", but such a big company? Didn't they have any
security people?
(it would probably have been harder than a yum upgrade, but using it on
production should have rang all alarms months before)

That said, I am kind expecting a similar case of "big company that
should have known better getting compromised by obvious security fail"
with the log4j vulnerability that was discovered last December.


Best regards


* There are probably a number of loopholes though, such as your
companies (banks, insurance, utilities...) looking you up and reporting
certain data to this kind of services. But in general, things should be
much better under EU legisation than in the US.


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

Re: [mailop] [E] $GOOG

[Jaroslaw Rafa via mailop]

Dnia 23.04.2022 o godz. 14:48:05 Dan Mahoney via mailop pisze:
> 
> I would LOVE there to be legal structure to say “Gee, Equifax, you failed
> to demonstrate the basic opsec of paying some junior admin to type `yum
> upgrade apache-struts`, so you don’t get to keep my PII anymore.” I would
> love if there was an option to simply put a flag on my SSN that says
> “gather/sell no data” to any of the dozens of agencies that harvest this
> (radaris et al) and package it up neatly.

Isn't European GDPR something that is supposed to achieve exactly this?

Yes, it doesn't work perfectly, and there are multiple companies that try to
go around it in multiple ways, but it's a step in good direction IMHO.

At least at the moment when GDPR came into effect I observed a BIG drop in
amount of spam coming to my server. And still, after several years, it
didn't return to pre-GDPR quantities yet...

Of course YMMV, especially outside Europe...
-- 
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://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Dan Mahoney via mailop]

> 
>> I am not
>> familiar with the lawsuits, but the general solution to all reputation
>> services, whether IP-reputation, consumer credit, or any other business
>> that collects information about other subjects (the building block of
>> surveillance capitalism!) is consent:  if the subject does not consent,
>> do not collect/report.  No reporting, no cause for legal action.
>> Provide reputation certificates for subjects that opt into the service
>> and let recipients decide how to deal with the absence of such
>> reputation ceritificate(s).
> 
> your unfamiliarity extends demonstrably beyond the lawsuits. if you choose to 
> do some research and ask some informed questions, i'd love to hear them and 
> try to engage further.

This will be off-topic for mailop, but…I remember Vixie giving a talk at 
MeetBSD, at the same moment that I found out that the latest-at-the-time 
equifax breach had exposed my information a few years back.

I would LOVE there to be legal structure to say “Gee, Equifax, you failed to 
demonstrate the basic opsec of paying some junior admin to type `yum upgrade 
apache-struts`, so you don’t get to keep my PII anymore.”  I would love if 
there was an option to simply put a flag on my SSN that says “gather/sell no 
data” to any of the dozens of agencies that harvest this (radaris et al) and 
package it up neatly.  

This is not the place to get into what dystopias being able to fully “opt out”  
would lead to, except that in either case (IP or PII), a lack of fingerprint 
would surely also be regarded as suspicious and approached with gated, minimal 
trust, if any at all.  

More on topic, however:

Consent or no, for all the intelligence sources you know about (on mxtoolbox’s 
multi-rbl checker, etc), there are dozens, possibly hundreds more, private 
ones.  Some in a manually maintained DB, some in a bayesian statistical DB 
based on how likely your domain is to spam based on email volume and SPF/DKIM 
records, and some that model way more data that you can imagine, that only 
exist in the mind of an AI that’s completely opaque, even to the people that 
coded it.

I strongly believe one such black box exists inside G, and that it's not the 
only place.

The best thing you can do is learn the correct inputs to the black box, at the 
time.  Build your own statistics of what your netblock is doing, and actually 
read and report on them before someone else does.  Email is no longer “set it 
and forget it” and hasn’t been for decades or more.

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

Re: [mailop] [E] $GOOG

[Robert L Mathews via mailop]

On 4/22/22 11:00 AM, Anne Mitchell via mailop wrote:

Woodpecker, at least, is somewhat up front about the fact that what they are 
doing is enabling their senders to violate Google's policies:


A lot of these outfits aren't even trying to hide it any more, which is 
unfortunate because it risks becoming normalized.


One I saw recently was , just flat out offering 
LinkedIn scraping . I complained to 
their hosting provider Namecheap, since it clearly violates their AUP, 
but no response.


--
Robert L Mathews
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Anne Mitchell via mailop]

> On Apr 22, 2022, at 11:05 AM, Luis E. Muñoz via mailop  
> wrote:
> 
> On 21 Apr 2022, at 11:45, Anne Mitchell via mailop wrote:
> 
>> Until Google manages to shut down outfits like MailShake and Woodpecker and 
>> Gmass, instead of turning a blind eye to it, Google will never get a handle 
>> on the abuse that goes through the Gmail API, in fact it feels as if they 
>> are tacitly approving it. (I suppose "shut down" s/b "care about". I know 
>> that my inquiries about it, and offers to assist, have fallen on 
>> unresponsive ears.)
> 
> The idea behind Mailshake is not bad in itself. Many CRMs also use their 
> customer's mail servers. There are some things that these outfits should do 
> better though:
> 
>   • Verify with the domain operator that they (the ESP, via the user that 
> signed up for the service) are indeed authorized to use the ESP's services. 
> I've found a number of instances where an end user with an email account on a 
> given domain, signed up to a certain CRM using this MO and started to email 
> "prospects" from their (ahem) "lead database". Hilarity tends to ensue 
> shortly after.
>   • Do a (much!) better job at vetting customers, including real rate 
> limiting.
>   • Take ownership of the responsibility to stop mail to whomever 
> unsubscribed/complained/bounced from their mailings. And then, keep track of 
> ratios and take their clients to task when thresholds are exceeded.

Well, yes, except basically they were either created to, or now do and don't 
care that they, enable people to do "cold email" by scraping email addresses, 
adding them to a list, and then sending them through the spammer's Gmail 
account so that it *looks* one to one, thereby having a bunch of 
spammer-friendly benefits including a) making it look one-to-one, and b) 
violating Federal law about an unsub link but cloaking it in it looking 
one-to-one (see "a)"). 

Woodpecker, at least, is somewhat up front about the fact that what they are 
doing is enabling their senders to violate Google's policies:

"If you exceed the sending limits (eg. 100 emails for free Gmail accounts when 
using automated tools, like Woodpecker) or send emails containing spam words 
your email provider will send us a server notification that your mailbox was 
suspended (usually for 24 hours). In such a case, Woodpecker will show an error 
on the campaign list." (https://woodpecker.co/help/how-woodpecker-sends-emails/)

So...

> After rereading the above, I realize how delusional it sounds :-(

I dunno about delusional, but much more willing to give the benefit of the 
doubt than am I.

Anne

--
Anne P. Mitchell, Attorney at Law
CEO ISIPP SuretyMail
Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
Author: The Email Deliverability Handbook
Board of Directors, Denver Internet Exchange
Dean Emeritus, Cyberlaw & Cybersecurity, Lincoln Law School
Prof. Emeritus, Lincoln Law School
Chair Emeritus, Asilomar Microcomputer Workshop
Counsel Emeritus: Mail Abuse Prevention System (MAPS) (now the anti-spam arm of 
TrendMicro)


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

Re: [mailop] [E] $GOOG

[Luis E . Muñoz via mailop]

On 21 Apr 2022, at 11:45, Anne Mitchell via mailop wrote:

Until Google manages to shut down outfits like MailShake and 
Woodpecker and Gmass, instead of turning a blind eye to it, Google 
will never get a handle on the abuse that goes through the Gmail API, 
in fact it feels as if they are tacitly approving it. (I suppose "shut 
down" s/b "care about". I know that my inquiries about it, and offers 
to assist, have fallen on unresponsive ears.)


The idea behind Mailshake is not bad in itself. Many CRMs also use their 
customer's mail servers. There are some things that these outfits should 
do better though:


* Verify with the domain operator that they (the ESP, via the user that 
signed up for the service) are indeed authorized to use the ESP's 
services. I've found a number of instances where an end user with an 
email account on a given domain, signed up to a certain CRM using this 
MO and started to email "prospects" from their (ahem) "lead database". 
Hilarity tends to ensue shortly after.
* Do a (much!) better job at vetting customers, including real rate 
limiting.
* Take ownership of the responsibility to _stop_ mail to whomever 
unsubscribed/complained/bounced from their mailings. And then, keep 
track of ratios and take their clients to task when thresholds are 
exceeded.


After rereading the above, I realize how delusional it sounds :-(

Happy Friday.

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

Re: [mailop] [E] $GOOG

[Anne Mitchell via mailop]

>> .. I'd suggest anything that shows gmailapi.google.com in the header be 
>> rejected -- at least until Google can get a handle on the abuse.

Until Google manages to shut down outfits like MailShake and Woodpecker and 
Gmass, instead of turning a blind eye to it, Google will never get a handle on 
the abuse that goes through the Gmail API, in fact it feels as if they are 
tacitly approving it.  (I suppose "shut down" s/b "care about".  I know that my 
inquiries about it, and offers to assist, have fallen on unresponsive ears.)

Anne

---
Anne P. Mitchell, Esq.
CEO Get to the Inbox by SuretyMail
Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
Author: The Email Deliverability Handbook
Board of Directors, Denver Internet Exchange
Dean Emeritus, Cyberlaw & Cybersecurity, Lincoln Law School
Prof. Emeritus, Lincoln Law School
Chair Emeritus, Asilomar Microcomputer Workshop
Counsel Emeritus, MAPS: Mail Abuse Prevention System (now the anti-spam 
division of TrendMicro)



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

Re: [mailop] [E] $GOOG

[Bill Cole via mailop]

On 2022-04-21 at 08:33:28 UTC-0400 (Thu, 21 Apr 2022 08:33:28 -0400)
Bill Cole via mailop 
is rumored to have said:


On 2022-04-20 at 23:41:13 UTC-0400 (Wed, 20 Apr 2022 22:41:13 -0500)
Larry M. Smith via mailop 
is rumored to have said:

.. I'd suggest anything that shows gmailapi.google.com in the header 
be rejected -- at least until Google can get a handle on the abuse.


E.g.;

Received: from .* named unknown by gmailapi.google.com with HTTPREST;
  Mon, 18 Apr 2022 16:53:54 -0700


Thanks for the clue!


Actually it's not looking good in my archives. I'm apparently already 
rejecting nearly all of the mail with HTTPREST or gmailapi in a Received 
header, or it's just not hitting any of my mailboxes, which are spread 
around a diversity of systems. I'm only seeing some older (14-month+) 
legitimate discussion list mail and 1-1 business communication. Some of 
the latter is actually spam (FE: Cloudflare salesthing hitting an 
address NO ONE should be selling to) but most is legit, including 
customer mail to a support@ address at one of my clients.



--
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

Re: [mailop] [E] $GOOG

[Bill Cole via mailop]

On 2022-04-20 at 23:41:13 UTC-0400 (Wed, 20 Apr 2022 22:41:13 -0500)
Larry M. Smith via mailop 
is rumored to have said:

.. I'd suggest anything that shows gmailapi.google.com in the header 
be rejected -- at least until Google can get a handle on the abuse.


E.g.;

Received: from .* named unknown by gmailapi.google.com with HTTPREST;
  Mon, 18 Apr 2022 16:53:54 -0700


Thanks for the clue!


--
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

Re: [mailop] [E] $GOOG

[Rob McEwen via mailop]

On 4/20/2022 11:41 PM, Larry M. Smith via mailop wrote:
I'd suggest anything that shows gmailapi.google.com in the header be 
rejected -- at least until Google can get a handle on the abuse



Excellent information - somehow, this slipped under my radar. So I've 
just done some cursory analysis of this in the past 1 hour. This is 
definitely worth exploring - however - those with large mail systems 
and/or who are adverse to having false positives - just know that this 
will hit on a significant amount of false positives. For example, what I 
found  is that some CRMs and some accounting systems - use this Google 
API for things like sending invoices to clients and for other legit 
transactional messages, and that sometimes happens for both gsuite 
business addresses (using their own domain) AND gmail addresses, too. 
Also, even if it had zero false positives (it doesn't come close to 
that) - even then - of all gmail spams, the total gmail spams that this 
hits is about 1/5th or 1/4th of all gmail spams, so this far from a 
comprehensive solution to the gmail spam issue, not even considering the 
false positives. Too many other gmail-sent spams don't have that header.


However, this still might be worth adding a point or two to the spam 
score and/or amplifying other existing scoring? And that will work even 
better if combined with using email and domain name WLs that would then 
further minimize potential false positives (so not apply this scoring to 
those messages).


So this is still very helpful info! Thanks!

--
Rob McEwen, invaluement

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

Re: [mailop] [E] $GOOG

[Paul Vixie via mailop]

yuv via mailop wrote on 2022-04-18 19:54:

On Mon, 2022-04-18 at 06:16 +0200, Paul Vixie via mailop wrote:

...


... Earlier in this
interesting thread you qualified Gmail as "late stage surveillance
capitalism."  Has it occured to you that reputation services, whether
distributed or other, are early stage surveillace capitalism?


no.


I am not
familiar with the lawsuits, but the general solution to all reputation
services, whether IP-reputation, consumer credit, or any other business
that collects information about other subjects (the building block of
surveillance capitalism!) is consent:  if the subject does not consent,
do not collect/report.  No reporting, no cause for legal action.
Provide reputation certificates for subjects that opt into the service
and let recipients decide how to deal with the absence of such
reputation ceritificate(s).


your unfamiliarity extends demonstrably beyond the lawsuits. if you 
choose to do some research and ask some informed questions, i'd love to 
hear them and try to engage further.


--
P Vixie

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

Re: [mailop] [E] $GOOG

[Larry M. Smith via mailop]

On 4/19/2022, Hans-Martin Mosner via mailop wrote:
(snip)>
When I detect those in the logs I add the MAIL FROM address to the 
known-spammer list, which causes the mail to be rejected earlier in the 
SMTP dialogue and seems to stop the retries. Most times I don't care 
whether they're retrying repeatedly, though, it costs more of their 
resources than mine.




There is a group of spammers that have been on Gmail for months and 
using something that shows in the header records as gmailapi.google.com. 
 Given that it appears that the spammers have a near endless supply of 
gmail addresses to send from, I don't know how effective that strategy 
might be.


API documentation for defining aliases on the fly;
https://developers.google.com/gmail/api/guides/alias_and_signature_settings

.. I'd suggest anything that shows gmailapi.google.com in the header be 
rejected -- at least until Google can get a handle on the abuse.


E.g.;
Received: from .* named unknown by gmailapi.google.com with HTTPREST;
 Mon, 18 Apr 2022 16:53:54 -0700


--
SgtChains

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

Re: [mailop] [E] $GOOG

[Larry M. Smith via mailop]

On 4/18/2022, Bill Cole via mailop wrote:
(snip)

Did you mean "GMail?"



Yes, you are correct -- Gmail.  Sorry about that.  Finger memory, or 
something.


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

Re: [mailop] [E] $GOOG

[Bill Cole via mailop]

On 2022-04-19 at 02:10:06 UTC-0400 (Tue, 19 Apr 2022 08:10:06 +0200)
Hans-Martin Mosner via mailop 
is rumored to have said:


Am 18.04.22 um 21:02 schrieb Bill Cole via mailop:

On 2022-04-18 at 13:32:07 UTC-0400 (Mon, 18 Apr 2022 12:32:07 -0500)
Larry M. Smith via mailop 
is rumored to have said:


...
I'm going to disagree.  To the best of my knowledge Yahoo, Vz, AOL, 
or Microsoft do NOT re-queue messages after receiving a 5xx response 
-- Qmail does.


Did you mean "GMail?"

FWIW, I've not seen GMail (or Qmail) do that. Do you know how to 
reproduce it?


I have a current sample where GMail did this. They apparently do it 
for 5.7.1 responses to DATA only, and not always, but I don't have 
complete statistics for this.


Thank you so much for the details. It gives me something to look for in 
logs.


Here are the log entries for the recent run (which were rejected after 
DATA due to a known-spammer body pattern, which is one possible way to 
keep the ever-changing GMail 4-1-9ers somewhat in check.) Note that 
identical message ID provies that this isn't the spammer repeatedly 
trying to get his/her fraud message across, but Google trying to force 
the spam down our throat :-)


Hypothetically possible that the spammer resubmitted the same message 
with existing MID 11 times. (unlikely)


Hypothetically possible that this indicates envelope splitting of some 
sort, i.e. same message being sent to different recipients on each try. 
That would be a natural approach to having recipients in multiple 
domains. It would also happen if the original had n recipients but the 
receiver forces one-at-a-time transfer by 4xx-ing recipients 2 through 
n.


I have investigating to do...



Apr 18 19:43:34 mail postfix/cleanup[23243]: 7D1D4120D85: 
message-id=
Apr 18 19:50:22 mail postfix/cleanup[24996]: 7C34B120D72: 
message-id=
Apr 18 20:13:48 mail postfix/cleanup[27908]: 8189A120D84: 
message-id=
Apr 18 20:40:41 mail postfix/cleanup[459]: 059EB120D0C: 
message-id=
Apr 18 21:25:48 mail postfix/cleanup[15781]: DAAD7120D74: 
message-id=
Apr 18 22:16:56 mail postfix/cleanup[28107]: 43595120D0C: 
message-id=
Apr 18 23:43:07 mail postfix/cleanup[14675]: 0F230120D30: 
message-id=
Apr 19 01:13:13 mail postfix/cleanup[25151]: 50B47120D0C: 
message-id=
Apr 19 02:44:45 mail postfix/cleanup[9739]: 23C56120D0C: 
message-id=
Apr 19 04:30:16 mail postfix/cleanup[29190]: 74078120D0C: 
message-id=
Apr 19 06:18:44 mail postfix/cleanup[16471]: D7F3B120D0C: 
message-id=


When I detect those in the logs I add the MAIL FROM address to the 
known-spammer list, which causes the mail to be rejected earlier in 
the SMTP dialogue and seems to stop the retries. Most times I don't 
care whether they're retrying repeatedly, though, it costs more of 
their resources than mine.


Cheers,
Hans-Martin

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



--
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

Re: [mailop] [E] $GOOG

[Rob Nagler via mailop]

On Mon, Apr 18, 2022 at 8:54 PM yuv via mailop  wrote:
> (1) the dissociation of cost and benefits.  economic externalities.
> (2) the dissociation of liability and control.
> (3) competing ownership/property claims.

All excellent points! I would add that reputation management is a hidden
tax (negative externality). This mailing list is part of the tax.

I would rather pay Google a fair price for their service, even though they
are a walled garden. In the days of acoustic couplers, many of us (not me!)
paid for email-as-a-service. Now we pay for reputation-as-a-service or
DIY-reputation.

People ask me why not use AWS? The tax for DIY-hosting is much lower for
one of my (compute-bound) businesses than utility computing.

We all make different economic tradeoffs based on our interests and skills.

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

Re: [mailop] [E] $GOOG

[Hans-Martin Mosner via mailop]

Am 18.04.22 um 21:02 schrieb Bill Cole via mailop:

On 2022-04-18 at 13:32:07 UTC-0400 (Mon, 18 Apr 2022 12:32:07 -0500)
Larry M. Smith via mailop 
is rumored to have said:


...
I'm going to disagree.  To the best of my knowledge Yahoo, Vz, AOL, or 
Microsoft do NOT re-queue messages after receiving a 5xx response -- Qmail does.


Did you mean "GMail?"

FWIW, I've not seen GMail (or Qmail) do that. Do you know how to reproduce it?

I have a current sample where GMail did this. They apparently do it for 5.7.1 responses to DATA only, and not always, 
but I don't have complete statistics for this.


Here are the log entries for the recent run (which were rejected after DATA due to a known-spammer body pattern, which 
is one possible way to keep the ever-changing GMail 4-1-9ers somewhat in check.) Note that identical message ID provies 
that this isn't the spammer repeatedly trying to get his/her fraud message across, but Google trying to force the spam 
down our throat :-)


Apr 18 19:43:34 mail postfix/cleanup[23243]: 7D1D4120D85: 
message-id=
Apr 18 19:50:22 mail postfix/cleanup[24996]: 7C34B120D72: 
message-id=
Apr 18 20:13:48 mail postfix/cleanup[27908]: 8189A120D84: 
message-id=
Apr 18 20:40:41 mail postfix/cleanup[459]: 059EB120D0C: 
message-id=
Apr 18 21:25:48 mail postfix/cleanup[15781]: DAAD7120D74: 
message-id=
Apr 18 22:16:56 mail postfix/cleanup[28107]: 43595120D0C: 
message-id=
Apr 18 23:43:07 mail postfix/cleanup[14675]: 0F230120D30: 
message-id=
Apr 19 01:13:13 mail postfix/cleanup[25151]: 50B47120D0C: 
message-id=
Apr 19 02:44:45 mail postfix/cleanup[9739]: 23C56120D0C: 
message-id=
Apr 19 04:30:16 mail postfix/cleanup[29190]: 74078120D0C: 
message-id=
Apr 19 06:18:44 mail postfix/cleanup[16471]: D7F3B120D0C: 
message-id=


When I detect those in the logs I add the MAIL FROM address to the known-spammer list, which causes the mail to be 
rejected earlier in the SMTP dialogue and seems to stop the retries. Most times I don't care whether they're retrying 
repeatedly, though, it costs more of their resources than mine.


Cheers,
Hans-Martin

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

Re: [mailop] [E] $GOOG

[yuv via mailop]

On Mon, 2022-04-18 at 06:16 +0200, Paul Vixie via mailop wrote:
> 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.

Hindsight is 20/20, good for you you are learning.  Earlier in this
interesting thread you qualified Gmail as "late stage surveillance
capitalism."  Has it occured to you that reputation services, whether
distributed or other, are early stage surveillace capitalism?  I am not
familiar with the lawsuits, but the general solution to all reputation
services, whether IP-reputation, consumer credit, or any other business
that collects information about other subjects (the building block of
surveillance capitalism!) is consent:  if the subject does not consent,
do not collect/report.  No reporting, no cause for legal action. 
Provide reputation certificates for subjects that opt into the service
and let recipients decide how to deal with the absence of such
reputation ceritificate(s).

As has been noted in this interesting thread by others to whom I
apologize for not citing them properly, the problem is behavioral.  Not
technical.  The solution (easier said than done) is policy, and
sometimes co-operation must be enforced.

Humans live on fault lines oblivious to the tectonic movements
underneath until the tensions explode.  The three active fault lines
underneath this industry that require policing are:

(1) the dissociation of cost and benefits.  economic externalities.  I
miss the days when I could operate a mail server behind a 2400bps dial-
up modem.

(2) the dissociation of liability and control.  for much too long, this
industry has disclaimed, wether in licensing terms or terms of service,
the liability for the consequences of what it controls.  just copied
from your nemesis:

TO THE FULLEST EXTENT PERMITTED BY APPLICABLE LAW, EXCEPT AS EXPRESSLY
PROVIDED FOR HEREIN, NEITHER PARTY MAKES ANY OTHER WARRANTY OF ANY
KIND, WHETHER EXPRESS, IMPLIED, STATUTORY OR OTHERWISE, INCLUDING
WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR USE AND NONINFRINGEMENT. the opressor MAKES NO
REPRESENTATIONS ABOUT ANY CONTENT OR INFORMATION MADE ACCESSIBLE BY OR
THROUGH THE SERVICES. CUSTOMER ACKNOWLEDGES THAT THE SERVICES ARE NOT A
TELEPHONY SERVICE AND THAT THE SERVICES ARE NOT CAPABLE OF PLACING OR
RECEIVING ANY CALLS, INCLUDING EMERGENCY SERVICES CALLS, OVER PUBLICLY
SWITCHED TELEPHONE NETWORKS.

(3) competing ownership/property claims.  Who owns the network, the
device, the software, the data, the service?  And what are the limits
on such property?

Easier to point the fault lines out than to suggest solutions.  I
apologize for not being ready to offer fully thought out solutions. 
Even if I was, the even more difficult task is to gain acceptability
and get the solutions implemented.  The political process.  Even within
the most advanced legal frameworks, serious updates are required in the
areas of (A) competition law; (B) consumer protection; and (C)
telecommunication policy.

The question is:  what kind of world do we want to live in, and leave
to our children?  The answer is subjective.

Back to lurking,
--
Yuval Levy, JD, MBA, CFA
Ontario-licensed lawyer


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

Re: [mailop] [E] $GOOG

[jose.morales.velazquez--- via mailop]

Hello,

This is my first reply/post ever, I hope it helps. 
A way to reproduce would be to use your own gmail address to send email to your 
server, block your email address in the incoming rules of the server while 
assigning a 5xx code to it, send the message from gmail and wait for a bounce 
back. Also check the log on your server.


Sincerely,
Jose Morales
Rackspace Email


-Original Message-
From: "Bill Cole via mailop" 
Sent: Monday, April 18, 2022 3:02pm
To: "Larry M. Smith via mailop" 
Subject: Re: [mailop] [E] $GOOG

On 2022-04-18 at 13:32:07 UTC-0400 (Mon, 18 Apr 2022 12:32:07 -0500)
Larry M. Smith via mailop 
is rumored to have said:

> Sorry, late to the game...
>
> On 4/17/2022, John Levine via mailop wrote:
>> 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.
>>
>
> I'm going to disagree.  To the best of my knowledge Yahoo, Vz, AOL, or 
> Microsoft do NOT re-queue messages after receiving a 5xx response -- Qmail 
> does.


Did you mean "GMail?"

FWIW, I've not seen GMail (or Qmail) do that. Do you know how to reproduce it?


-- 
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 mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Paul Vixie via mailop]

i remember when folks were complaining to MAPS that AOL was bouncing 
inbound e-mail with an SMTP error code showing a MAPS.VIX.COM URL.


i remember replying that AOL was free to bounce whatever they wanted for 
whatever reason they chose, and coined "their network, their rules."


i don't believe i would have said this (or felt it) if the evidence for 
MAPS's reputation reports to AOL was not online and available.


i'm immensely saddened by google's "star chamber" gatekeeping of my 
friends and family and mailing list subscribers among billions of other 
mailboxes whose owners cannot be informed enough to have given informed 
consent for this.


if we had run MAPS that way back in the day we'd've had zero friends, 
including, noone who is defending google's behaviour on this thread.


i've avoided replying to most of this thread since i want to show 
learning behaviour and unless i could surprise someone with a nuanced 
and evolved view, i figure to save you all the effort of ignoring it.


but i am reading and learning.

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

Re: [mailop] [E] $GOOG

[Michael Rathbun via mailop]

On Mon, 18 Apr 2022 12:17:25 -0400, Bill Cole via mailop 
wrote:


>Should Google be better about noticing when problems go away? Maybe. Should IP 
>addresses be made permanently useless for email because one well-intentioned 
>sysadmin didn't recognize a problem for long enough that Google noticed?

Indications we have here are that Goog puts about 1% of a sender's mail in
somebody's inbox regardless of reputation, even down to flat rejection at the
border.  I have actually seen a sender go from flat rejection to 100% inbox in
just under two weeks.  They just kept sending mail that got engagement (opens,
clicks) and minimal complaints and zero stale account hits.  

Senders who don't generate (or expect) these signs of "engagement" may not
always have pleasant outcomes.

mdr
-- 
   "There will be more spam."
  -- Paul Vixie

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

Re: [mailop] [E] $GOOG

[Bill Cole via mailop]

On 2022-04-18 at 13:32:07 UTC-0400 (Mon, 18 Apr 2022 12:32:07 -0500)
Larry M. Smith via mailop 
is rumored to have said:

> Sorry, late to the game...
>
> On 4/17/2022, John Levine via mailop wrote:
>> 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.
>>
>
> I'm going to disagree.  To the best of my knowledge Yahoo, Vz, AOL, or 
> Microsoft do NOT re-queue messages after receiving a 5xx response -- Qmail 
> does.


Did you mean "GMail?"

FWIW, I've not seen GMail (or Qmail) do that. Do you know how to reproduce it?


-- 
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

Re: [mailop] [E] $GOOG

[Larry M. Smith via mailop]

Sorry, late to the game...

On 4/17/2022, John Levine via mailop wrote:

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.



I'm going to disagree.  To the best of my knowledge Yahoo, Vz, AOL, or 
Microsoft do NOT re-queue messages after receiving a 5xx response -- 
Qmail does.


I don't know if this is because their system expects a specific text 
response, if they expect enhanced status codes (even when the remote 
doesn't respond to EHLO with ENHANCEDSTATUSCODES), of if Google simply 
believes that sender's policy trumps receivers policy.


--
SgtChains
___
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 23:20:26 UTC-0400 (Mon, 18 Apr 2022 05:20:26 +0200)
Paul Vixie via mailop 
is rumored to have said:

> Bill Cole via mailop wrote on 2022-04-17 22:56:
>> ...
>>
>> Reasonableness is case-specific Or "subjective" if you prefer...
>
> it is not.

I guess we'll have to set that aside, as we clearly do not agree on what those 
words means.

> 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.

OK, so a hypothetical untested opinion of an unknown number of unidentified 
3rd-nth parties is not subjective. Not sure what it means to you, but we 
absolutely do not understand the word "subjective" in the same way. I'm sorry 
that I used it.

By your own account of events, you had an IP operating as a chronic public 
nuisance. You burned its reputation by not controlling what came from it. You 
had one that you could to switch to after fixing the underlying issue. Seems 
reasonable to me.

Should Google be better about noticing when problems go away? Maybe. Should IP 
addresses be made permanently useless for email because one well-intentioned 
sysadmin didn't recognize a problem for long enough that Google noticed? Maybe. 
It's not 1996, and arguably 'second chances' have not worked in the quarter 
century since. There's a utility in having heads on pikes. "Paul Vixie Ran 
Afoul OF Our Spam Control Policy!" has a particularly special 'head on pike' 
quality. My suspicion is that at some level, Google has decided to play the 
asshole rather than spending money on extremely specialized support staff to 
investigate cases and resolve them in gentle ways. I don't expect Brandon Long 
to weigh in on that facet of Google policy. (I wouldn't in his place...)

> 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.

No, it is not.

The comedic value of running mail systems has been on a steady decline. It's a 
problem.

>> 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.

One must understand whether the available means to a legitimate end are 
actually a moral failure or just unpleasant to perform. Nothing guarantees a 
solution to every problem, and especially not an ideal one.


-- 
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

Re: [mailop] [E] $GOOG

[Simon Wilson via mailop]

People are forced to get a Gmail account and strongly encouraged to  
use it (for example, by defaults and preinstalled apps) when they  
get an Android phone

--


- End message from Vittorio Bertola via mailop  -

*Completely* and objectively not true.

I've run Android phones for many years with a Google account based on  
my own personal non-Gmail email. I have never activated or used Gmail,  
and at no stage has an Android phone ever tried to force me to use  
Gmail.


When using Android without Gmail, at no stage in the "defaults" or  
"preinstalled apps" is this anything other than "enter your Google  
account email address and login"-difficult to achieve.



or for a number of other reasons related to other services.


Without knowing what "other services" you refer to, it's hard to be  
specific, but I use a lot of Google services without having a Gmail  
account without any difficulties. Which services (specifically) do you  
have in mind that are forced to use Gmail?


--
Simon Wilson
M: 0400 12 11 16

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

Re: [mailop] [E] $GOOG

[Laura Atkins via mailop]

> On 18 Apr 2022, at 08:35, Vittorio Bertola via mailop  
> wrote:
> 
> 
>> Il 15/04/2022 16:43 Laura Atkins via mailop  ha scritto:
>> 
>> All of the complaints I’ve seen about google track back to: the person was 
>> either actively sending spam (possibly unknowingly, but that doesn’t exactly 
>> reflect well on the sender) or they’re using a free service that is 
>> regularly used to send spam and they refuse to actually move to a service 
>> that doesn’t allow abuse. 
> Well, no. I have been running a personal VPS with a personal .eu email domain 
> for almost 20 years now, moving across a handful of major hosting providers 
> in Europe, and several times throughout this period Gmail started to reject 
> my mail without any clear reason to do so, even if I followed all the 
> instructions on their website. Usually it got better after a few months, also 
> without any clear reason. 

Without any clear reason you could see. That doesn’t mean they didn’t have a 
reason. 

>> No one is forced to use google as a recipient mail server and everyone who 
>> is using it made a choice to do so - either by moving their domain there or 
>> actively signing up for a gmail.com  address. 
> This is also not entirely true. People are forced to get a Gmail account and 
> strongly encouraged to use it (for example, by defaults and preinstalled 
> apps) when they get an Android phone, or for a number of other reasons 
> related to other services.

Having a google account != being forced to use it for email. 

> Also, people are told to get a Gmail account as a solution to their email 
> provider being unable to deliver to Gmail :) So, sure, Gmail offers good 
> service, perhaps the best among the free ones, but a good part of their 
> success is is due to their overall dominant market position. 

I do a LOT of work with lists of domains for clients. Part of that work is 
looking at what filters are handling mail. The process is simple: do DNS 
lookups on all the domains, do some classification of the underlying MXs and 
then rank them by who is handling the most mail / domains for the client. 

The data is pretty consistent across a wide range of clients. Google and 
Microsoft are the top, followed by Yahoo if the list is a consumer list, and 
Proofpoint if it’s a business list. Then another handful of domains - mimecast 
is a big one for both consumer and business users. 

What’s interesting is the difference when I’m looking at bounce logs. When 
clients send me logs, I do roughly the same thing - grab the domains, do MX 
lookups and the classify them. Google is rarely at the top of the list in those 
cases. 

So in terms of sending mail, Google handles maybe 30 - 40% of email. Microsoft 
handles slightly less, but still quite a bit, then about a dozen different and 
very recognizable filters. In terms of bouncing mail, the numbers are all over 
the place, but Google rarely enters into it. The biggest IP blocking problem I 
see is because mimecast uses spamcop. Spamcop seems to be randomly blocking a 
shared IP pool one of my clients is using and no one can tell me if it’s my 
client’s problem (which I can fix) or just the IP pool. 

My biggest problem with Google is actually some of their customers reach out to 
me about their domains having a bad reputation and wanting help. When I reply 
to them google puts my reply in their spam folder. (Lost a couple potential 
clients that way ‘your mail ended up in spam, so you clearly don’t know what 
you’re doing.’ The answer is pretty simple, though, when I remove their domain 
from the email it makes it to the inbox. Their domain reputation is that bad. 

I don’t think I’ve ever had Google actually block my VPS ever. I’m not saying 
it doesn’t happen, I’m just saying that it’s generally for a reason. Google 
doesn’t just throw up random blocks for no reason. We may not understand it, 
but that doesn’t mean it’s random. 

The claims that Google is somehow a monopoly and that they’re using blocking to 
force people to use their systems is based on conjecture. It is demonstrably 
false. They’re not aggressive in terms of blocking mail - there are folks who 
handle less mail than Google but block much more mail. 

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

[Vittorio Bertola via mailop]

> Il 15/04/2022 17:55 Graeme Fowler via mailop  ha scritto:
> 
> Obviously we’ve had a great deal of discussion of OVH over the years, most of 
> which wasn’t favourable. YMMV, obviously.

OVH is the second biggest hoster in Europe.

Unless we want to assume that Europe is a continent of spammers, I'd say that a 
globally dominant company (in email and in the hosting/cloud business, and in 
many others) rejecting or hampering email from its second biggest competitor in 
Europe, no matter the reason, is breaking any reasonable concept of "fair 
competition".

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bert...@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Vittorio Bertola via mailop]

> Il 15/04/2022 16:43 Laura Atkins via mailop  ha scritto:
> 
> 
> 
> All of the complaints I’ve seen about google track back to: the person was 
> either actively sending spam (possibly unknowingly, but that doesn’t exactly 
> reflect well on the sender) or they’re using a free service that is regularly 
> used to send spam and they refuse to actually move to a service that doesn’t 
> allow abuse.  Well, no. I have been running a personal VPS with a personal 
> .eu email domain for almost 20 years now, moving across a handful of major 
> hosting providers in Europe, and several times throughout this period Gmail 
> started to reject my mail without any clear reason to do so, even if I 
> followed all the instructions on their website. Usually it got better after a 
> few months, also without any clear reason.
> 
> No one is forced to use google as a recipient mail server and everyone who is 
> using it made a choice to do so - either by moving their domain there or 
> actively signing up for a gmail.com  address.  This is also 
> not entirely true. People are forced to get a Gmail account and strongly 
> encouraged to use it (for example, by defaults and preinstalled apps) when 
> they get an Android phone, or for a number of other reasons related to other 
> services. Also, people are told to get a Gmail account as a solution to their 
> email provider being unable to deliver to Gmail :) So, sure, Gmail offers 
> good service, perhaps the best among the free ones, but a good part of their 
> success is is due to their overall dominant market position.


--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bert...@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy
___
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] [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 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

[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]

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

[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] $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

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

[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

[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

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

[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:
>> 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

[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

[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, 

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

[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

[John Levine via mailop]

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

Re: [mailop] [E] $GOOG - IPv6 aside

[Paul Vixie via mailop]

Luis E. Muñoz via mailop wrote on 2022-04-15 18:49:

...

Someone once said that IPv6 was an opportunity to introduce a good
set of requirements into the email ecosystem (forgot who/where, and
I'm paraphrasing). ...


that's what i was trying to get at here:

https://circleid.com/posts/20110607_two_stage_filtering_for_ipv6_electronic_mail

--
P Vixie

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

Re: [mailop] [E] $GOOG

[Paul Vixie via mailop]

wait, wait.

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?


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.)




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". 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 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.


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

--
P Vixie

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

Re: [mailop] [E] $GOOG

[Jaroslaw Rafa via mailop]

Dnia 15.04.2022 o godz. 20:18:54 John Levine via mailop pisze:
> >
> >You quoted that. Eu.org is a *domain registrar*. Only. They don't offer any
> >email service and never did. So how can they "police users for email"?
> 
> They can turn off people when they get credible spam reports.

Maybe they do. Honestly, I don't know as I'm not a spammer. What I know is
that they explicitly state in their policy that you cannot use the domain to
spam. This doesn't have to translate to any actual action against spammers,
but it can.

Is there anybody here who knows for sure?

Also, as I have mentioned in another mail, it takes some effort and quite a
lot of time to get an .eu.org domain up and running. Free doesn't mean it's
a few clicks and you're set. Having to wait 10 days or so until your domain
is manually accepted doesn't make it an attractive option for spammers. It's
an "old school" service and their registration process is clearly oriented
towards people interested in using the domain for long time.
-- 
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://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[John Levine via mailop]

It appears that Jaroslaw Rafa via mailop  said:
>Dnia 15.04.2022 o godz. 16:53:11 Laura Atkins via mailop pisze:
>> 
>> "EU.org, free domain names since 1996” 
>
>You quoted that. Eu.org is a *domain registrar*. Only. They don't offer any
>email service and never did. So how can they "police users for email"?

They can turn off people when they get credible spam reports.

>Do you know any paid domain registrar - for example for .com domain - that
>"polices users for email", if they don't host any email for the user?

Yes.  Registries, too.

As I may have said once or twice, sometimes free services are worth what you 
pay for them.

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

Re: [mailop] [E] $GOOG

[John Levine via mailop]

According to Peter Nicolai Mathias Hansteen via mailop :
>> 15. apr. 2022 kl. 16:24 skrev Al Iverson via mailop :
>> 
>> PPS- Don't send to Gmail over IPv6.
>
>I would rather say «don’t try to send to gmail over IPv6 unless you have a 
>correct reverse DNS for your IPv6 address». Google apparently decided to
>raise the bar a little when it comes to receiving over IPv6.

I send lots of mail to Google over IPv6 and it works fine.

But I have been careful to configure my MTA with squeaky clean correct rDNS and 
SPF and so forth,

My ISP doesn't do IPv6 ("you're the only person who's ever asked") so I use a 
tunnel to Hurricane
Electric which works amazingly well.  And it's free.

-- 
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://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Bill Cole via mailop]

On 2022-04-15 at 14:20:28 UTC-0400 (Fri, 15 Apr 2022 19:20:28 +0100)
Laura Atkins via mailop 
is rumored to have said:

> .eu.org  is, essentially, a tld. And .tlds have their own 
> reputation, too. Just this week a few of us were talking about ‘weird’ tlds. 
> One of the participants works at a filtering company, checked their stats and 
> said “this particular tld is 9x% spam.” So 9+ times in 10 when they see a 
> domain registered in that tld, it’s spam.

This is consistent with the SpamAssassin RuleQA stats. 
https://ruleqa.spamassassin.org/?daterev==%2FTLD shows the stats for rules 
with 'TLD' in their names. (N.B.: the SA sample size is nowhere near what the 
big providers have, and it probably skews differently) The default rules 
channel includes a list of 'suspicious' TLDs that have been used predominantly 
in spam, at least at some point in the past. Reliably 99%+ spam & with some 
minor FP protection that goes over 99.9%. Some of those have been pulled out as 
test rules (T_*) in response to complaints by "legit" (stipulated, unchecked) 
senders. Every TLD tested individually that way has been found to be 
persistently associated at least 95% with spam, except for .space which has a 
slightly better record hovering around 90%.

It is entirely reasonable to see a TLD (or any zone used as a registry) as a 
meaningful attribute in spam filtering. There is a correlation in many cases. I 
cannot nail down what causes that correlation, but that doesn't affect its 
utility. OTOH, even with the spam/ham reduction in recent years, the majority 
of mail is still spam so a 90% correlation isn't as significant as it sounds. A 
few years ago, a 90% spam source would have been *better* than the aggregate 
mean...



-- 
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

Re: [mailop] [E] $GOOG

[Jaroslaw Rafa via mailop]

Dnia 15.04.2022 o godz. 19:20:28 Laura Atkins via mailop pisze:
> 
> Would you really hold it against that company, given the data they have,
> if they blocked all mail with that tld in it? Given that it’s 90+%
> guaranteed that tld is spam? What if 90+% of the mail in the .eu.org
>  tld is also spam? Does it make more sense to block mail
> containing that domain? Or are we just refusing to consider any domain
> based blocking at all?

I think *domain* based blocking is OK, if the domain is confirmed to send
spam, but this applies to end-user domains, not to TLDs. TLD-based blocking
is definitely not.

Similarly IP-based blocking is OK, if the IP is confirmed to send spam,
netblock-based blocking is not.

Even if 95% of mail from some TLD (or netblock) is spam, that remaining 5%
could contain something very important to someone.

Of course I'm talking about general email providers. If someone runs a
private mail server and does not expect that he/she ever receives any
legitimate mail - for example - from Brazil, it is understandable that he/she
blocks the entire .br domain or Brazillian networks (a LOT of spam coming
from there!). But for a general email provider, blocking off Brazil would be
wrong, even considering the huge amount of spam coming from there.

There was a previous discussion in this thread regarding spam filtering more
concentrated on "badput" or "goodput". One can either have a goal to minimize
the amount of spam passed through, caring less about some legitimate
messages being filtered out, or one can have a goal to minimize false
positives, living with the fact that a few spams will end up in the inbox.
My opinion is that you cannot have both. Either you minimize the amount of
spam - sacrificing some legitimate email in process - or you maximize the
amount of legitimate email, allowing some spam to pass through.

I obviously prefer the second approach, while it looks that Google is taking
the first one. For recipient being an experienced user, the message getting
into spam folder is no big deal, because such users will check their spam
folders anyway. But majority of Google users have little experience :). They
just believe that things in spam folder are actual spam and they have no
reason to look there. My recipients for example, even after multiple
cases of my messages ending up in their spam folder, seem to still not
develop the habit of checking that folder too, nor clicking "this is not
spam" on messages that mistakenly landed in the spam folder.

Therefore I think a few spams landing in the inbox do less harm to an
average user than even one legitimate mail filed to spam folder, because
even an inexperienced user is able to note the obvious signs of spam and
delete the message manually (at least that's what I believe, maybe I'm
wrong?). And if we're talking about targeted, sophisticated phishing, even a
very strict spam filter will be usually unable to catch it anyway. Just
today at my work email I received a phishing message that no spam filter
would catch (unless the URL of the link that I was supposed to click would
be known to the spam filter - but for targeted phishing they usually use
fresh domains, not used previously). It was just a regular message that an
average person would send, only the content was suspicious because it
claimed things that were unprobable in relationship to my actual life.
But it wasn't any well-known scam like Nigerian fraud, so no filter could
know that, only a human can :).
-- 
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://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Laura Atkins via mailop]

> On 15 Apr 2022, at 18:29, Luis E. Muñoz via mailop  wrote:
> 
> On 15 Apr 2022, at 12:50, Jaroslaw Rafa via mailop wrote:
> 
> Dnia 15.04.2022 o godz. 16:53:11 Laura Atkins via mailop pisze:
> 
> "EU.org, free domain names since 1996”
> 
> You quoted that. Eu.org is a *domain registrar*. Only. They don't offer any 
> email service and never did. So how can they "police users for email"?
> 
> Do you know any paid domain registrar - for example for .com domain - that 
> "polices users for email", if they don't host any email for the user?
> 
> There are many who claim that there's a correlation between easily, cheap (or 
> free) domain names and spam. Their rationale is that spammers can secure 
> disposable domain names for very low price.
> 
That wasn’t what I was claiming, honestly. what I was saying is that he doesn’t 
know what other folks are doing with eu.org , yet he’s sharing 
reputation with absolutely everyone who is using that registration service. And 
that there’s a very low barrier to entry to getting a .eu.org  
domain. And given the domain registration runs off donations and volunteers 
there’s likely no one actively policing the use of the domain. 

.eu.org  is, essentially, a tld. And .tlds have their own 
reputation, too. Just this week a few of us were talking about ‘weird’ tlds. 
One of the participants works at a filtering company, checked their stats and 
said “this particular tld is 9x% spam.” So 9+ times in 10 when they see a 
domain registered in that tld, it’s spam. 

Would you really hold it against that company, given the data they have, if 
they blocked all mail with that tld in it? Given that it’s 90+% guaranteed that 
tld is spam? What if 90+% of the mail in the .eu.org  tld is 
also spam? Does it make more sense to block mail containing that domain? Or are 
we just refusing to consider any domain based blocking at all? 

Filters generally make sense, but they often have access to data that we, as 
senders, don’t. 

Of course, that doesn’t mean the filters are always right. I’ve certainly been 
able to demonstrate that filters are wrong and get ISPs to stop using them. One 
of the times that stands out was a major anti-spam vendor was following on 
every link in an email - including the closed loop confirmation link - and then 
listing the COI-only IPs that sent mail after the confirmation. They refused to 
change what they were doing and continued to insist the only fix was to send 
COI mail. (How? you’re confirming your addresses want the mail and then listing 
it). We collected enough evidence that this was happening and shared it with 
the appropriate decision makers.  The filter didn’t stop being stupid, but at 
least one of the cable companies using that particular blocklist stopped. 

I am pretty sure, though, that yelling on mailop has never convinced a 
filtering company to change their approach. 

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

[Jaroslaw Rafa via mailop]

Dnia 15.04.2022 o godz. 13:29:45 Luis E. Muñoz via mailop pisze:
> 
> There are many who claim that there's a correlation between easily,
> cheap (or free) domain names and spam. Their rationale is that
> spammers can secure disposable domain names for very low price.

Domains at eu.org are free, but it is not easy to register a domain there.
In other words, you don't pay with money, but you pay with your effort and
time, so I don't think it's an attractive option for spammers. This is
really an "old school" service which isn't designed to be super-easy to use
:). And I appreciate that :).

First, when you register a domain name at eu.org, you must already have two
working DNS servers for that domain set up. This is checked during the
registration process. They don't provide DNS servers for you, you have to
set them up yourself.

Second, all registration applications are accepted manually by eu.org
administrators, so you have to wait for your domain to be registered. This
can be from few days to even few weeks. I don't remember how long I waited
for my rafa.eu.org domain (I registered it 15+ years ago), but 2 years ago I
registered another domain at eu.org and I waited about 10 days for that
domain to become active. So yes, there are quite significant "costs"
involved in getting a domain at eu.org (only these are non-financial costs)
and so I don't think it's an attractive option for spammers.

With discounts that some paid domain registrars give for first year, it's
much easier to register a .com or national domain as a throwaway one, as you
can do this almost instantly with only a few clicks and a small payment,
than go through the hassles of registering at eu.org. The latter makes sense
only if you are interested in using the domain for long time.
-- 
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://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG - IPv6 aside

[Al Iverson via mailop]

lem wrote:

> > You're not wrong. Depends on email volume level and server config.
> > They're just so sensitive to reputation for IPv6 sends, though. Don't
> > even try without SPF and DKIM, and even then, get ready for some
> > possible pain.
>
> For well managed mail servers, supporting well managed mailing lists I see no 
> practical difference between address families. I have visibility over a few 
> boxes sending a few hundred thousand messages per day.

I see no reason to disagree with you. :)

The difference between your scenario and mine (and the scenarios of
people struggling) is that you're sending much more mail than me (and
the people struggling), I think.

You might be at the low end compared to how much mail Gmail sends, but
you're in rather a good spot as having enough email to send to build
up a good sending reputation. (Of course, it's not ONLY about
volume...but that is indeed part of it.)

Cheers,
Al


-- 
Al Iverson / Deliverability blogging at www.spamresource.com
Subscribe to the weekly newsletter at wombatmail.com/sr.cgi
DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Luis E . Muñoz via mailop]

On 15 Apr 2022, at 12:50, Jaroslaw Rafa via mailop wrote:


Dnia 15.04.2022 o godz. 16:53:11 Laura Atkins via mailop pisze:


"EU.org, free domain names since 1996”


You quoted that. Eu.org is a *domain registrar*. Only. They don't 
offer any

email service and never did. So how can they "police users for email"?

Do you know any paid domain registrar - for example for .com domain - 
that

"polices users for email", if they don't host any email for the user?


There are many who claim that there's a correlation between easily, 
cheap (or free) domain names and spam. Their rationale is that spammers 
can secure disposable domain names for very low price.


Therefore, they claim, domain names meeting that criteria need to be 
subjected to additional scrubbing. Less sophisticated receivers could 
simply opt to reject while providers with more sophisticated mechanisms 
could implement that "additional scrubbing" in the form of tighter 
tolerances, starting the "reputation calculation" from a lower value or 
whatever makes sense to them.


Their common goal according to this narrative, is to reduce the amount 
of spam these mailbox providers have to deliver to their 
products/clients.


There is bound to be conflict on this _operational_ decision. 
Registrants of those cheap domains face an uphill battle with their 
deliverability to those providers following the above process, while 
these same providers see a net improvement on their situation by taking 
a simple (to them) step to curb spam.


This is more or less the same line of thought as when discussing about 
who is in charge of the network where your mail service sends from.


Best regards

-lem

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

Re: [mailop] [E] $GOOG

[Grant Taylor via mailop]

On 4/15/22 10:48 AM, Jaroslaw Rafa via mailop wrote:

What do you disagree with? The fact that *I* never sent email via IPv6 from
my server?


I disagree with the lack of caffeine and distraction that I had when i 
originally read your message.  :-/


I mistook your statement as:

   Never use IPv6 to send mail at all.

As opposed to:

   Never used IPv6 to send mail at all.

The missing "d" really makes a difference.

*sigh*

/me goes to get more caffeine.


I guess I know better how my server is configured :)


I want to agree with you.  But tt depends who you ask.  Some vendors 
think they know how to run /your/ systems better than /you/ do.  Bit, 
that's besides the point that you're making.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Jaroslaw Rafa via mailop]

Dnia 15.04.2022 o godz. 11:47:37 Bill Cole via mailop pisze:
> 
> 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.

As I said initially, using a different domain is only a poor workaround, not
a solution, because:

1) I lose my "digital identity". Yes, I'm that old-fashioned type who
considers my email address to be something that identifies me on the
Internet. People on mailing lists etc. know me by my e-mail address. This
one, not a different one that I needed to make up only to send to Google.

2) even more important: I can not have any guarantee that over time Google
doesn't treat my new domain in the same way as the current one. I had no
problems with Google deliverability for several years of using this address;
the issues started only about two years ago. The fact that my new domain
works for Google now, doesn't mean that it will still work after - say - 4
or 5 years.
-- 
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://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Bill Cole via mailop]

On 2022-04-15 at 12:42:53 UTC-0400 (Fri, 15 Apr 2022 17:42:53 +0100)
Laura Atkins via mailop 
is rumored to have said:

> In these cases, though, it’s often the companies that are doing “cold 
> outreach”

Thanks for the new euphemism. It's cute...

I have zero visibility into businesses that intentionally send unsolicited bulk 
and/or commercial email. It does not surprise me from being on the other end of 
their work that they prefer MS.


-- 
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

Re: [mailop] [E] $GOOG

[Jaroslaw Rafa via mailop]

Dnia 15.04.2022 o godz. 16:55:36 Graeme Fowler via mailop pisze:
> 
> $ host 217.182.79.147
> 147.79.182.217.in-addr.arpa domain name pointer rafa.eu.org.
> 
> $ whois -h whois.cymru.com 217.182.79.147
> AS  | IP   | AS Name
> 16276   | 217.182.79.147   | OVH, FR
> 
> Obviously we’ve had a great deal of discussion of OVH over the years, most
> of which wasn’t favourable. YMMV, obviously.

You seem to be missing the bit of information (which I repeated twice) that
when I send email from exactly the same IP, but with a different sender
domain, it goes through to inbox. So it's a domain thing, not an IP thing.
-- 
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://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Jaroslaw Rafa via mailop]

Dnia 15.04.2022 o godz. 16:53:11 Laura Atkins via mailop pisze:
> 
> "EU.org, free domain names since 1996” 

You quoted that. Eu.org is a *domain registrar*. Only. They don't offer any
email service and never did. So how can they "police users for email"?

Do you know any paid domain registrar - for example for .com domain - that
"polices users for email", if they don't host any email for the user?
-- 
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://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG - IPv6 aside

[Luis E . Muñoz via mailop]

On 15 Apr 2022, at 12:02, Al Iverson via mailop wrote:

> On Fri, Apr 15, 2022 at 10:36 AM Grant Taylor via mailop
>  wrote:
>>
>> On 4/15/22 8:24 AM, Al Iverson via mailop wrote:
>>> Don't send to Gmail over IPv6.
>>
>> Drive by comment.
>>
>> It is possible to send to Google via IPv6.  My personal / small /
>> bespoke server sends to my Google hosted work address all the time over
>> IPv6.
>
> You're not wrong. Depends on email volume level and server config.
> They're just so sensitive to reputation for IPv6 sends, though. Don't
> even try without SPF and DKIM, and even then, get ready for some
> possible pain.

For well managed mail servers, supporting well managed mailing lists I see no 
practical difference between address families. I have visibility over a few 
boxes sending a few hundred thousand messages per day. They are all dual stack 
and provisioned on a cloud provider (gasp!). The two deliverability issues 
they've had in the last two years have been related to sending to Microsoft, 
over IPv4.

I also see similar boxes, used mostly for one-to-one and small scale mailing 
lists in the same scenario, with the same results.

Of course, this is a small number of samples and perhaps even anecdotal, but 
these kinds of absolute pieces of advice are perhaps not for everyone.

Someone once said that IPv6 was an opportunity to introduce a good set of 
requirements into the email ecosystem (forgot who/where, and I'm paraphrasing). 
With the potential to send each individual email message over the lifetime of a 
mailing list from a unique IPv6 address, I think this is a good justification 
for this.

Best regards

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

Re: [mailop] [E] $GOOG

[Jaroslaw Rafa via mailop]

Dnia 15.04.2022 o godz. 09:36:16 Grant Taylor via mailop pisze:
> On 4/15/22 8:32 AM, Jaroslaw Rafa via mailop wrote:
> >Never used IPv6 to send mail at all.
> 
> I strongly disagree with that statement.  Both in the current
> veracity and the long term implications thereof.

What do you disagree with? The fact that *I* never sent email via IPv6 from
my server?

I guess I know better how my server is configured :)
-- 
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://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Laura Atkins via mailop]

> On 15 Apr 2022, at 17:24, Bill Cole via mailop  wrote:
> 
> On 2022-04-15 at 10:43:13 UTC-0400 (Fri, 15 Apr 2022 15:43:13 +0100)
> Laura Atkins via mailop 
> is rumored to have said:
> 
>> Recipients have agency here and can move elsewhere for mail. The fact that 
>> they don’t tells me that google understands their userbase really well and 
>> does what they need to do to keep them happy.
> 
> FWIW, I have some visibility into that and have seen a few small businesses 
> move their mailboxes from a boutique outsourcer to Google only to move them 
> soon afterwards to MS365. None the other way.

I’ve seen a lot of folks moving, too. In these cases, though, it’s often the 
companies that are doing “cold outreach” are moving to Microsoft because their 
outbound filtering isn’t as good and Google is actually shutting down their 
senders (only for 24 hours and only when they’ve send their 1000 emails). The 
service providers in that space are also recommending MS rather than Google as 
they can send more. 

> Those decisions had everything to do with cost and end-user experience, never 
> about precision and fairness in spam control or transparent collaboration 
> with the email community. In my experience, deliverability into MS is worse 
> than into Google from the standpoint of a strictly no-spam sender only using 
> IPv4 for email.

Totally agree here. MS are more aggressive with their filters, more opaque with 
their filters and will happily toss mail on the floor. It’s also a much harder 
process to fix problems once you’ve gotten into trouble there. But I’ve had 
clients who’ve done it there after months and months of cleaning up and 
consistent sending. 

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

[Bill Cole via mailop]

On 2022-04-15 at 10:43:13 UTC-0400 (Fri, 15 Apr 2022 15:43:13 +0100)
Laura Atkins via mailop 
is rumored to have said:

> Recipients have agency here and can move elsewhere for mail. The fact that 
> they don’t tells me that google understands their userbase really well and 
> does what they need to do to keep them happy.

FWIW, I have some visibility into that and have seen a few small businesses 
move their mailboxes from a boutique outsourcer to Google only to move them 
soon afterwards to MS365. None the other way.

Those decisions had everything to do with cost and end-user experience, never 
about precision and fairness in spam control or transparent collaboration with 
the email community. In my experience, deliverability into MS is worse than 
into Google from the standpoint of a strictly no-spam sender only using IPv4 
for email.


-- 
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

Re: [mailop] [E] $GOOG

[Bill Cole via mailop]

On 2022-04-15 at 10:24:41 UTC-0400 (Fri, 15 Apr 2022 09:24:41 -0500)
Al Iverson via mailop 
is rumored to have said:

>
> PPS- Don't send to Gmail over IPv6.
>

Excellent advice. Although, I should say that I admire the people who try to 
run mail systems primarily on IPv6. They are paving the way for the eventual 
future we will all live in, provided we all have unusually long lives. Paving 
the newly blazed trail with their vitrified bones, one of 2^128 IPs at a time...

However, if I'm recalling correctly, Mr. Rafa's problem with Google is solely 
due to the use of a domain under an independent/private registry zone (eu.org) 
which has a history of abuse. That is worse in a way than being stuck on IPv6, 
as people actually care about how their domain names look to humans and you 
really need to pay for one in a traditional gTLD or non-monetized ccTLD to get 
solid deliverability.

In the end, all spam control works by imposing costs (including problem-solving 
effort) on all senders so that the vast masses of low-rent spammers who lack 
the resources (including skills) to pass muster. That sucks.

-- 
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

Re: [mailop] [E] $GOOG - IPv6 aside

[Al Iverson via mailop]

On Fri, Apr 15, 2022 at 10:36 AM Grant Taylor via mailop
 wrote:
>
> On 4/15/22 8:24 AM, Al Iverson via mailop wrote:
> > Don't send to Gmail over IPv6.
>
> Drive by comment.
>
> It is possible to send to Google via IPv6.  My personal / small /
> bespoke server sends to my Google hosted work address all the time over
> IPv6.

You're not wrong. Depends on email volume level and server config.
They're just so sensitive to reputation for IPv6 sends, though. Don't
even try without SPF and DKIM, and even then, get ready for some
possible pain. I think Gmail could be worried that with IPv6 being so
broad that somebody could do a spam run targeted at them with each
individual message coming from a different IPv6 IP. So I think they
are way quicker to drop the hammer and block an IPv6 IP at very low
volumes versus an IPv4 IP. (That's a bit of a generalization there, of
course.)

When I set up a new VPS at a provider, I immediately disable the IPv6
interface and IP. I have never had any sort of broad blocking issues
at Gmail with my newest servers. Occasionally I get a content block or
trigger something weird-- I accidentally stumbled across a bug in my
mailing list manager a couple of weeks ago that would sometimes result
in having two message-ID headers and that caused Gmail blocking. But I
was able to troubleshoot and fix it.

Cheers,
Al

-- 
Al Iverson / Deliverability blogging at www.spamresource.com
Subscribe to the weekly newsletter at wombatmail.com/sr.cgi
DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Graeme Fowler via mailop]

On 15 Apr 2022, at 16:39, Grant Taylor via mailop  wrote:
> Your VPS doesn't sound like "a free service".  But there is a chance that 
> your VPS is with a VPS provider that has a ... questionable reputation.  --  
> I speaking in the hypothetical as I've not looked.  -- Thus you may be 
> suffering from guilt by association (with your chosen VPS provider).

$ host 217.182.79.147
147.79.182.217.in-addr.arpa domain name pointer rafa.eu.org.

$ whois -h whois.cymru.com 217.182.79.147
AS  | IP   | AS Name
16276   | 217.182.79.147   | OVH, FR

Obviously we’ve had a great deal of discussion of OVH over the years, most of 
which wasn’t favourable. YMMV, obviously.

Also (referencing Google), I believe this is where we have to state “their 
network, their rules”. Again.

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

Re: [mailop] [E] $GOOG

[Laura Atkins via mailop]

> On 15 Apr 2022, at 16:39, Grant Taylor via mailop  wrote:
> 
> On 4/15/22 9:09 AM, Jaroslaw Rafa via mailop wrote:
>> How is my own VPS, that I pay for, that only I control and only I use to 
>> send mail "a free service that doesn't police users for email" ???
> 
> Your VPS doesn't sound like "a free service".  But there is a chance that 
> your VPS is with a VPS provider that has a ... questionable reputation.  --  
> I speaking in the hypothetical as I've not looked.  -- Thus you may be 
> suffering from guilt by association (with your chosen VPS provider).

"EU.org, free domain names since 1996” 

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

[Bill Cole via mailop]

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.


> BTW. It's definitely a domain thing, not an IP reputation thing, since I
> send from the same server e-mails from different domain that I mentioned in
> my previous email, and those get through. However mails from this address
> don't. They are hand-typed, plain text, without any links or attachments.
> Just like this one. But anything coming from this domain is right away
> spam-marked by Google.
>
> I have discussed this even directly with Brandon Long from Google on this
> list. I have submitted the issue via their "sender troubleshooting form"
> multiple times (BTW. they state it clearly in the form that you WON'T GET
> ANY RESPONSE!). No effect.
>
> 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 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. But 
as Al said, it is simply false that they are acting at random or that their 
deterministic blundering cannot be worked around.


-- 
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

Re: [mailop] [E] $GOOG

[Grant Taylor via mailop]

On 4/15/22 9:09 AM, Jaroslaw Rafa via mailop wrote:
How is my own VPS, that I pay for, that only I control and only I use 
to send mail "a free service that doesn't police users for email" ???


Your VPS doesn't sound like "a free service".  But there is a chance 
that your VPS is with a VPS provider that has a ... questionable 
reputation.  --  I speaking in the hypothetical as I've not looked.  -- 
Thus you may be suffering from guilt by association (with your chosen 
VPS provider).




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Grant Taylor via mailop]

On 4/15/22 8:32 AM, Jaroslaw Rafa via mailop wrote:

Never used IPv6 to send mail at all.


I strongly disagree with that statement.  Both in the current veracity 
and the long term implications thereof.


 - I send a fair bit of email via IPv6 without any problems at all.

 - I do have a select few destination domains that I have disabled IPv6 
for.


I acknowledge that the current state of email over IPv6 is not as good 
as it is over IPv4.  *HOWEVER* I think that it's /very/ /important/ that 
we actually use IPv6 for email because if we don't the current status 
quo will never get better.  So for the health of the Internet we /need/ 
to use IPv6 for email.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG - IPv6 aside

[Grant Taylor via mailop]

On 4/15/22 8:24 AM, Al Iverson via mailop wrote:

Don't send to Gmail over IPv6.


Drive by comment.

It is possible to send to Google via IPv6.  My personal / small / 
bespoke server sends to my Google hosted work address all the time over 
IPv6.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Peter Nicolai Mathias Hansteen via mailop]

> 15. apr. 2022 kl. 16:24 skrev Al Iverson via mailop :
> 
> PPS- Don't send to Gmail over IPv6.

I would rather say «don’t try to send to gmail over IPv6 unless you have a 
correct reverse DNS for your IPv6 address». Google apparently decided to raise 
the bar a little when it comes to receiving over IPv6.

I just sent as a test the message preserved at 
https://www.bsdly.net/~peter/somebody_mentioned_ipv6.eml.txt 
 which was 
delivered over IPv6, as the headers will show, so it’s definitely possible.

I have however at times seen people with gmail accounts either not getting 
messages from my domains at all or only finding them in the spam folder, when 
my logs record the messages as accepted by the Google servers.

I would most certainly have preferred some sort of error message, but that 
appears not to be Google’s way of doing things.

The domain’s reputation in Google’s view may have been tainted by their 
classifying some automatically generated mail *about* spam activity as spam. I 
was originally somewhat reluctant to mention those episodes, but for those 
bored witless and curious the bounces are archived at 
https://home.nuug.no/~peter/googlefail/ 
. It’s even possible that some of the 
items at the first link in my signature has more information in a field notes 
type of style.

- Peter

—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.






signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Jaroslaw Rafa via mailop]

Dnia 15.04.2022 o godz. 15:43:13 Laura Atkins via mailop pisze:
> 
> He’s also been told, repeatedly, to stop using a free service that doesn’t
> police its users for email. Google doesn’t like services that let folks
> abuse them and don’t do anything about it. They’re also blocking mail
> with bit ly links in them, too.

How is my own VPS, that I pay for, that only I control and only I use to
send mail "a free service that doesn't police users for email" ???
-- 
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://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Laura Atkins via mailop]

> On 15 Apr 2022, at 15:24, Al Iverson via mailop  wrote:
> 
> On Fri, Apr 15, 2022 at 7:41 AM Jaroslaw Rafa via mailop
>  wrote:
>> 
>> 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.
> 
> Okay.
> 
> Cheers,
> Al Iverson
> PS- I already troubleshoot this stuff all day for pay, and then
> already help kind people on the side for free, so then also helping
> somebody who's already half grumpy about it to try to win an argument
> that they don't want me to win, anyway, doesn't really give me a whole
> heck of a lot of joy.
> PPS- Don't send to Gmail over IPv6.

He’s also been told, repeatedly, to stop using a free service that doesn’t 
police its users for email. Google doesn’t like services that let folks abuse 
them and don’t do anything about it. They’re also blocking mail with bit ly 
links in them, too. 

All of the complaints I’ve seen about google track back to: the person was 
either actively sending spam (possibly unknowingly, but that doesn’t exactly 
reflect well on the sender) or they’re using a free service that is regularly 
used to send spam and they refuse to actually move to a service that doesn’t 
allow abuse. 

No one is forced to use google as a recipient mail server and everyone who is 
using it made a choice to do so - either by moving their domain there or 
actively signing up for a gmail.com  address. 

Recipients have agency here and can move elsewhere for mail. The fact that they 
don’t tells me that google understands their userbase really well and does what 
they need to do to keep them happy. 

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

[Byung-Hee HWANG via mailop]

Al Iverson via mailop  writes:

> (... thanks ...)
> PPS- Don't send to Gmail over IPv6.

Very useful tip, to me!

Thanks ^^^

Sincerely, Linux fan Byung-Hee

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

Re: [mailop] [E] $GOOG

[Jaroslaw Rafa via mailop]

Dnia 15.04.2022 o godz. 09:24:41 Al Iverson via mailop pisze:
> PPS- Don't send to Gmail over IPv6.

Never used IPv6 to send mail at all.
-- 
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://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Al Iverson via mailop]

On Fri, Apr 15, 2022 at 7:41 AM Jaroslaw Rafa via mailop
 wrote:
>
> 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.

Okay.

Cheers,
Al Iverson
PS- I already troubleshoot this stuff all day for pay, and then
already help kind people on the side for free, so then also helping
somebody who's already half grumpy about it to try to win an argument
that they don't want me to win, anyway, doesn't really give me a whole
heck of a lot of joy.
PPS- Don't send to Gmail over IPv6.

-- 
Al Iverson / Deliverability blogging at www.spamresource.com
Subscribe to the weekly newsletter at wombatmail.com/sr.cgi
DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Cyril - ImprovMX via mailop]

I can understand the frustration and tension in these emails as Gmail
clearly doesn't provide any helpful way to resolve issues.

We too are in the same scenario. We got our domain lowered to bad about two
months ago, without any apparent reasons (no clear changes on our end), and
we are now struggling to find ways to revert it back to good. We read lots
of blogs talking about this, but they often talk about setting up
SPF/DKIM/DMARC, and having custom content with no or few links, etc, which
already (SPF/DKIM/DMARC) or does not (links/content) apply to us.

I am like Jaroslaw Rafa here: I want to believe. I want to believe that
there is a way to revert these bans back to normal.

I'd love to know why our domain has been pushed to "bad", in order to work
on fixing this issue.
I'd love to know why our IPs have been blocked and to have a way to request
delisting, even if it needs to talk to a team in order to explain what was
done, what has been implemented, and all needed proof that we are not
spammers.

Unfortunately, as far as I know, and as far as everyone seems to understand
from Google on this mailing list, Gmail is a black box. Nothing comes out
of it, and no one is providing clear solutions and explanations about what
to do.
I suspect this is not related to the people working at Google specifically,
but more about a policy set by the organization.

I'd LOVE to be proven wrong.

Please prove me I'm wrong.

Le ven. 15 avr. 2022 à 14:41, Jaroslaw Rafa via mailop 
a écrit :

> 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.
>
> BTW. It's definitely a domain thing, not an IP reputation thing, since I
> send from the same server e-mails from different domain that I mentioned in
> my previous email, and those get through. However mails from this address
> don't. They are hand-typed, plain text, without any links or attachments.
> Just like this one. But anything coming from this domain is right away
> spam-marked by Google.
>
> I have discussed this even directly with Brandon Long from Google on this
> list. I have submitted the issue via their "sender troubleshooting form"
> multiple times (BTW. they state it clearly in the form that you WON'T GET
> ANY RESPONSE!). No effect.
>
> If you still think this is fixable, then give me a working fix.
>
> Just for comparison, I want to tell you about a completely different
> experience. I mailed someone with the address @mail.ru. Mail.ru didn't
> like
> my IP address and rejected the email - giving me in the rejection message
> an
> URL to the page where I can request unblocking for my IP. I filled in the
> form, next day I got a message that I'm unblocked. Everything smooth and
> without any problems.
>
> That's what I would expect from a company as popular as Google.
> --
> 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://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Jaroslaw Rafa via mailop]

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.

BTW. It's definitely a domain thing, not an IP reputation thing, since I
send from the same server e-mails from different domain that I mentioned in
my previous email, and those get through. However mails from this address
don't. They are hand-typed, plain text, without any links or attachments.
Just like this one. But anything coming from this domain is right away
spam-marked by Google.

I have discussed this even directly with Brandon Long from Google on this
list. I have submitted the issue via their "sender troubleshooting form"
multiple times (BTW. they state it clearly in the form that you WON'T GET
ANY RESPONSE!). No effect.

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

Just for comparison, I want to tell you about a completely different
experience. I mailed someone with the address @mail.ru. Mail.ru didn't like
my IP address and rejected the email - giving me in the rejection message an
URL to the page where I can request unblocking for my IP. I filled in the
form, next day I got a message that I'm unblocked. Everything smooth and
without any problems.

That's what I would expect from a company as popular as Google.
-- 
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://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Paul Vixie via mailop]

i see that grant and rob are having a lovely time down-thread but i have 
nothing to add so i'll make this my final reply, this time to mr. iverson.


Al Iverson via mailop wrote on 2022-04-14 19:40:

On Thu, Apr 14, 2022 at 12:00 PM Jaroslaw Rafa via mailop
 wrote:


... 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.


so, i am not jaroslaw rafa, but i do have a related observation.


That is false.

Cheers,
Al Iverson


and cheers to you, old comrade. let me share some of my related story. 
last thanksgiving or so (nov/dec 2021) i began hearing errors from gmail 
when trying to reach mailboxes they hosted. turned out it was a demand 
for SPF and DKIM, which i sheepishly then implemented. alas, this just 
led to the next echelon, which looked like this:



<$person@$place.com>: host aspmx.l.google.com[2607:f8b0:400e:c08::1b] said:
550-5.7.1 [2001:559:8000:cd::4 19] Our system has detected that this
550-5.7.1 message is likely suspicious due to the very low reputation of the
550-5.7.1 sending domain. To best protect our users from spam, the message has
550-5.7.1 been blocked. Please visit
550 5.7.1 https://support.google.com/mail/answer/188131 for more information.
v67si211465pfv.268 - gsmtp (in reply to end of DATA command) 


i guessed and hoped that this reputation score would decay but after a 
week it hadn't so i signed up with sendgrid as my outbound relay for 
google hosted recipients, just to keep my mailing lists flowing. note, 
this was a bad move and i regret it, postfix doesn't do what i wanted.


on a guess, i went through my historical maillogs to see what i may have 
been transmitting toward gmail that could earn me a bad reputation, and 
i found it immediately. bad bots had been joe-jobbing gmail.com 
recipients using my mailman signup page. every request mailman sent to 
one of these spoofed addresses looked to gmail like templated spam. i 
sheepishly turned on SPF verification for inbound so that i'd reject 
spoofed-source gmail.com mail, and also robot-proofed mailman's signup 
page to keep these addresses from bypassing my SPF checks.


again i waited, hoping for decay. and note that while the user interface 
of gmail's complaints wasn't good, all errors so far in this story had 
been mine. i wasn't happy but i wasn't pointing fingers (yet.) anyway, a 
week went by and no change. i got busy and forgot about it until a few 
months later when sendgrid's renew-bot asked for another payment.


on another guess, i renumbered my outbound e-mail server, that is, i 
changed only the last octet (low-order 8 bits), preserving the hostname 
and DKIM key and making no changes to the SPF data. presto, it worked!


it should not have worked! what i did was too trivial to count as an 
"imposed cost" by gmail.com as a defender, had i been an actual 
attacker. if renumbering a host within the same netblock would bypass a 
test, then that test is an ill-conceived self-defeat (or self-harm).


however, a lot of e-mail between members of my community and members of 
gmail's community were bounced over a five month period, with me having 
no recourse except to pay sendgrid and finally to renumber my server. 
perhaps gmail as a hyper scale company has to throw out a lot of babies 
with their bathwater and hope to make it up in volume. but i do not 
think this is the reputation gmail wants to have -- or claims to have.


so, al, if upon hearing this story you're minded to say "paul, you 
idiot, all you had to do was $thing", then i am minded to listen. if not 
then i think jaroslaw rafa's assertion that you said was false, is true.


--
P Vixie

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

Re: [mailop] [E] $GOOG

[Paul Vixie via mailop]

this has been an interesting thread. i'll touch on only a few points.

Marcel Becker wrote on 2022-04-14 02:14:
On Wed, Apr 13, 2022 at 2:58 PM Paul Vixie via mailop > wrote:


that google is provably wrong and provably non-transarent in how they
decide what inbound e-mail to reject.

Unless you have a solution which ensures that only good senders are able 
to send email, then yes, you will find that receivers will be mostly 
non-transparent on how they decide what to reject. Any receiver 
protecting their users will be.


thank you for putting that so delicately. i said provably wrong, though. 
the proof is that the goal of deliberate rejection of some inbound 
e-mail is to increase the goodput fraction not to decrease the badput 
fraction. false positives do not achieve the actual objective, and a 
policy which must inexorably and does in fact reduce the goodput 
fraction, is provably wrong.


as to your observation on transparency, all of the early distributed 
reputation systems (RSS, RBL, DUL, and later the SBL) had a rejection 
message which was the URL of a document which explained why that 
particular message had been blocked, what was the evidence behind the 
reasoning, and what steps could be taken to accept accountability. this 
may have been before some of the people participating in this thread 
were participating in the e-mail industry, but it was once a norm with 
100% coverage. as co-founder at MAPS i've got to say that transparency 
of this kind is part of how we got sued so often and so well.


google does not do this. and having offered free(-ish) e-mail services 
to my friends, my family, and my colleagues on a bunch of mailing lists 
i operate, their lack of transparency does real harm to the community 
(in addition to the self-harm described above). i will never argue that 
google (or anybody) has a duty to accept all e-mail. as the owner of 
their service they have authority over its policy. what i am arguing is 
something more subtle: if you reject e-mail, say why, because it might 
be a false rejection worthy (to the service operator) of getting fixed.


finally as to your clear implication that transparency by defenders can 
aid attackers. we found this to be true from the earliest days of spam, 
where spammers could tune their methods making gradual improvements as 
directed by the errors they received, until they found a way through. i 
called out spamassassin for this problem on the day it was released, so 
hopefully i'll seem both informed about and sympathetic to your concern. 
here's how it applies in the gmail case.


if gmail is concerned only with badput volume and not goodput volume 
then they would not want the risk of enabling spammers to tune their 
methods. in this case they would tell their user base both current and 
future that "we're going to silently reject a lot of inbound e-mail 
without telling our recipients or the outside senders why, and so you 
will sometimes miss e-mail, which will not be received by us at all and 
therefore cannot be placed into your spam folder."


that's not their messaging. if they're not going to speak words to this 
effect then they have a duty of care *to their users* to not take 
actions to this effect.


note, i don't mind the spam folder thing. last night i found my COVID 
test result in my spam folder and while i find this sophomoric it does 
not indicate false advertising, or absence-of-truth advertising.



know better than to cooperate with your oppressor.

This was stressed before (even by the list admin): But if you want 
people to collaborate and be more transparent, maybe refrain from 
sentences like the one above.
i think the thread that descended from the above text has been quiet 
collaborative, and my experience does not provide me a more effective 
way to get at the real issue than to say it out loud.


gmail is to me an example of late stage surveillance capitalism in which 
things are centralized that don't need to be leading to constraints 
imposed without informed consent or indeed any consent at all.


anyone who knows either first hand or from reports on this mailing list 
that gmail will occasionally reject goodput with no transparency and 
thus permitting no recourse, should probably stop using gmail for their 
own mail, and should probably stop recommending that others use gmail 
for their own mail.


for google to accumulate a billion e-mail endpoints and then after some 
period of years impose fees on some and impose opaque filtering rules on 
all, is at least an abuse of position. to emit gigatons of spam at the 
same time raises this to an exercise in oppression because google 
demands recourse for itself but offers none to others.


i was not expecting any of google's people to respond on this thread no 
matter what language i used. not that i meant to alienate, only that the 
issues at heart here are long known and well trodden.


--
P Vixie

Re: [mailop] [E] $GOOG

[Al Iverson via mailop]

On Thu, Apr 14, 2022 at 12:00 PM Jaroslaw Rafa via mailop
 wrote:
>
> Dnia 13.04.2022 o godz. 19:44:52 Al Iverson via mailop pisze:
> >
> > Seconded. Google does not do things the way I would, and I find them
> > frustrating, yes, but no, it is not true about there being some
> > conspiracy to keep you out, and no, it's not unfixable, unless you
> > stick your head in the sand or put your fingers in your ears and don't
> > do things the right way for 2022 because you don't want to or can't.
>
> 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.

Cheers,
Al Iverson


-- 
Al Iverson / Deliverability blogging at www.spamresource.com
Subscribe to the weekly newsletter at wombatmail.com/sr.cgi
DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Jaroslaw Rafa via mailop]

Dnia 13.04.2022 o godz. 19:44:52 Al Iverson via mailop pisze:
> 
> Seconded. Google does not do things the way I would, and I find them
> frustrating, yes, but no, it is not true about there being some
> conspiracy to keep you out, and no, it's not unfixable, unless you
> stick your head in the sand or put your fingers in your ears and don't
> do things the right way for 2022 because you don't want to or can't.

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.

Advices like "change your domain" or "change your hosting provider" (because
of "bad IP reputation") cannot be seriously considered as a fix. In best
case, it is a poor workaround, that - in case of a domain change - makes you
lose your long-used email address, known to people (at least as a sender
address; yes, someone can still reach you at your old address, but you can
no longer "represent" yourself with this address, which is quite important
if you used this address for - say - 10+ years), and in case of a hosting
provider change it requires a lot of time and effort to migrate the server,
even if no additional money. And it isn't even guaranteed to work, you can
only *hope* that you will be treated better with a new domain or new
provider.
-- 
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://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Al Iverson via mailop]

>> that google is provably wrong and provably non-transarent in how they
>> decide what inbound e-mail to reject.
>
> Unless you have a solution which ensures that only good senders are able to 
> send email, then yes, you will find that receivers will be mostly 
> non-transparent on how they decide what to reject. Any receiver protecting 
> their users will be.
>
>> know better than to cooperate with your oppressor.
>
> This was stressed before (even by the list admin): But if you want people to 
> collaborate and be more transparent, maybe refrain from sentences like the 
> one above.

Seconded. Google does not do things the way I would, and I find them
frustrating, yes, but no, it is not true about there being some
conspiracy to keep you out, and no, it's not unfixable, unless you
stick your head in the sand or put your fingers in your ears and don't
do things the right way for 2022 because you don't want to or can't.

Cheers,
Al Iverson

-- 
Al Iverson / Deliverability blogging at www.spamresource.com
Subscribe to the weekly newsletter at wombatmail.com/sr.cgi
DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Marcel Becker via mailop]

On Wed, Apr 13, 2022 at 2:58 PM Paul Vixie via mailop 
wrote:

> that google is provably wrong and provably non-transarent in how they
> decide what inbound e-mail to reject.
>

Unless you have a solution which ensures that only good senders are able to
send email, then yes, you will find that receivers will be mostly
non-transparent on how they decide what to reject. Any receiver protecting
their users will be.


> know better than to cooperate with your oppressor.
>

This was stressed before (even by the list admin): But if you want people
to collaborate and be more transparent, maybe refrain from sentences like
the one above.

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