Re: [mailop] FTC Report on Feasibility of Creating a 'Do Not Email' List

[Paul Vixie via mailop]

Dave Crocker via mailop wrote on 2022-05-17 18:01:

..., the bigger problem, IMO, are the folk who operate in a criminal
style, ignoring rules.
my view has always been that the people who don't know what the rules 
are, and the people who know what the rules are but see them broadly 
ignored, create the operating conditions that make solving for the 
"criminal style" impossible. as in politics, norms matter.


i don't save or analyze or filter based on spam of the "criminal style" 
any more. my modern interest is spammers who don't know what they're 
doing is wrong, or think it can only be nominally and not actually wrong 
because huge volumes of spam are what they see, and this kind of 
cost-shifting seems profitable. (it's not in the broad sense; it's 
merely extractive, not creative, of value.)


i'd much rather fight criminals whose behaviour is in no way normal.

--
P Vixie

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

Re: [mailop] FTC Report on Feasibility of Creating a 'Do Not Email' List

[Paul Vixie via mailop]

Justin Scott via mailop wrote on 2022-05-17 17:01:
Ah, the Good Old Days(tm).  I seem to recall a list of "reasons your 
anti-spam proposal won't work" someone would post every time someone 
came up with a new way to fight spam that included things like "It 
requires spammers to change their behavior" and "it involves a central 
authority or agency to approve emails" and stuff like that.  ...


that was vernon schryver, and the list is still online, and vernon still 
adds to it from time to time. rather than post the url itself, i'll post 
the KARKIVE link from news.admin.net-abuse.email where it was first 
announced. 19 years ago, yikes.


https://news.admin.net-abuse.email.narkive.com/xDLfdr5u/you-might-be-an-anti-spam-kook-if

--
P Vixie

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

Re: [mailop] The world lost another spamfighter

[Paul Vixie via mailop]

alan started at MAPS on 2000-04-03, and was from my point of view an 
unalloyed good for us. committed, passionate, professional, exemplar. he 
left us on 2002-04-05, and he wrote a Farewell message to staff@ as follows:



As I trust you've all heard, today is my last day at MAPS.  Leaving a group of 
such dedicated and competent people is not easy, but I have other commitments 
in my life which need attention.  (Imagine that...something other than spam!)

It's been quite an experience, one of which I am very proud.  I know, 
first-hand, that MAPS  stops a *lot* of spam -- stops it from being sent -- and 
I know I've been part of the force that caused it to stop. Dave and Paul, 
thanks for that opportunity!

I know that the spam war isn't over, nor is the ultimate outcome at all clear.  
But I'm more convinced than ever that it's an important fight, and that MAPS is 
part of the solution (and quite possibly a contributor to a cause even bigger 
than spam).  And, as I've seen over the two years I've been here, MAPS 
continues to find secure foundations for its existance, and to stabilize and 
solidify its position and reputation. While I'll miss many things at MAPS, and 
I have considerable sorrow in leaving, I do feel that MAPS is more viable now 
that ever before.  And I absolutely know that the present crew is totally 
capable, and committed to its success.

Best wishes to MAPS as it continues its mission, and (as I told OO) please feel 
free to ask if you think I can be of assistance to the cause (amurph@$elided, 
360-$elided).

Sincerely,

Alan Murphy
RBL Senior Investigator (ex)
650-$elided
--
Mail Abuse Prevention System, LLC http://mail-abuse.org/
"spam" definition: http://mail-abuse.org/standard.html
MAPS, RBL, RSS, DUL, and RBL+ are service marks of MAPS LLC.


i've notified dave of amurph's passing. the MAPS team has gone on to do 
many incredible things, showing the fortune and privilege we enjoyed to 
be even more extraordinary in retrospect. i've crossed paths with alan a 
few times over the two decades since he left MAPS, and i can say that he 
became even more like himself as time went on -- unchanged except to 
become stronger and more valuable to the community and to his friends.


vixie

re:

Tara Natanson via mailop wrote on 2022-05-08 09:11:
Many here have already heard but on May 6th Alan Murphy passed away 
after complications from surgery last week.


...

--
P Vixie

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

Re: [mailop] SMTP line wrapping breaking DKIM signatures when forwarding

[Paul Vixie via mailop]

Dave Crocker via mailop wrote on 2022-04-27 06:43:


On 4/27/2022 6:30 AM, Michael Kliewe via mailop wrote:
Exactly. The best and easiest solution is to contact the sender and 
tell them to fix the problem, by either using "relaxed/relaxed" or by 
reducing the line length to <=998 bytes.


So, rather than changing the message, do simply relaying of the 
(unchanged) message, but also send a notification about the problem, 
back to the SMTP Mail-From address.


i have a slight preference for "either relay it or bounce it but don't 
do a little of both". and  i must observe that in robotic e-mail, 
mail-from is often deliberately unreplyable. the only reliable error 
path is at the the end of DATA.


--
P Vixie

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

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

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

[Paul Vixie via mailop]

Chase Vance via mailop wrote on 2022-04-18 19:02:

Hello All,
I am having a issue with one of our customers getting his mail blocked 
by google and he is getting the below message back in return. Is this 
something that is getting blocked because of our IP or is it with his 
message or something else.


there is no easy way to know. the hard way is to try changing each 
element of your configuration including your sender's domain name, your 
IP address, and your IP protocol (v4 vs. v6). if google's behaviour at 
some point changes, you can probably assume that it was due to the last 
configuration element you changed. it's also possible that nothing you 
can change will alter google's behaviour, which may mean that you need 
to be able to change more things, or that google's behaviour is now 
permanent with regard to something noone could possible configure. you 
may find success through patience. google moves in mysterious ways.


The messages he is sending contain 
information for disabled veterans.


google doesn't care about that.

1650216820@88/C1-32265-4CA4C526@E7/C1-32265-1CA4C526@D0/E5-32265-1CA4C526@B@costillafreepr...@gmail.com 
@richard.vc...@gojade.org 
@default@default@9@52@0@172.253.122.27@550-5.7.1 
[129.213.214.220   7] Our system has detected that this message 
is\r\n550-5.7.1 likely unsolicited mail. To reduce the amount of spam 
sent to Gmail,\r\n550-5.7.1 this message has been blocked. Please 
visit\r\n550-5.7.1 
https://support.google.com/mail/?p=UnsolicitedMessageError\r\n550 5.7.1  
for more information. 
iw6-20020a0562140f2600b00446475d31d8si1263424qvb.299 - gsmtp

Thank you all for any help you can provide!
Chase Vance
Platform Messaging Specialist
918-855-7319


somewhere on that support web page google is telling you to ensure that 
your PTR and /A RR's are symmetric, and that you're using DKIM, and 
DMARC, and SPF. this forum includes several deliverability consultants 
if you need paid help with those details -- just ask. (not me.)


a workaround is to hire some ESP to transmit your outbound e-mail. this 
is not free.


i wish i had hope or could give you some. please send news of any change 
to your situation. many of us wonder what we'll do next time google 
rejects our e-mails in the way they are currently rejecting yours.


--
P Vixie

___
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

[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

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

[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 <mailto:mailop@mailop.org>> 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 tr

Re: [mailop] gmail - pop3 retrieval checking SPF ? ( gmail, wth ? Take 2 )

[Paul Vixie via mailop]

Brandon Long via mailop wrote on 2022-04-15 00:09:

...

If people are choosing to use us as their mail client, they are choosing 
to do so for what we provide, and our spam handling is certainly part of 
this.  ...


i did some polling among the friends and family who i could not reach 
the last time gmail was opaquely rejecting all e-mail from my server. 0% 
of those polled knew they had a choice of e-mail clients (or e-mail 
services) or that they had made such a choice. i'm not calling coercion, 
but i would like the record to state that "defaults matter".


--
P Vixie

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

[mailop] $GOOG

[Paul Vixie via mailop]

it's troubling me that in a recent thread asking where to host 
mailboxes, google was recommended several times, in spite of the fact 
that google is provably wrong and provably non-transarent in how they 
decide what inbound e-mail to reject.


of all constituencies, this one, mailop, is one i would have expected to 
know better than to cooperate with your oppressor.

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

Re: [mailop] Our experience on Gmail blacklisting our IPs range

[Paul Vixie via mailop]

Anne Mitchell via mailop wrote on 2022-04-05 09:13:

...

Amen.  Good thing their motto is "don't be evil", can you imagine what they'd 
be doing otherwise?


@k8emo made me laugh out loud one day when she said, "unlike google, 
there never was a time when uber wasn't evil." yikes!


--
P Vixie

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

Re: [mailop] Our experience on Gmail blacklisting our IPs range

[Paul Vixie via mailop]

Cyril - ImprovMX via mailop wrote on 2022-04-05 03:28:

Hi everyone!

Two weeks ago, we had two ranges of IP blocked by GMail and since they 
are a black box, we were in the dark about what would happen with the ban.


...

Clearly, someone used the reputation of ImprovMX.com to deliver emails 
by forging them before delivery.


when this happened to my primary outbound IP, it turned out to be that 
google e-mail addresses were signing up en masse for mailman lists here, 
and the resulting confirmation e-mail from mailman was seen by google as 
spam. i've since turned off confirmation e-mail, and i've added SPF 
checking to the inbound e-mail path.



...

After around a week, we restarted the IP and they were accepted by 
Gmail! We haven't received any responses from the form we submitted, nor 
from anywhere else.


when this happened to me, it went on for months. i hired an outbound 
e-mail delivery service and taught postfix how to route mail to google's 
MX servers through that service. this was fraught with pain, and so i 
eventually renumbered my primary outbound server to a different IP in 
the same /24. problem "solved".



...

My key takeaway here in case your IPs are banned by Gmail is:

  * First - and most importantly - find and stop the root cause of the
problem
  * If you can, stop sending with these IPs (after fixing the issue,
otherwise you'll get your other IP listed too!)
  * Reach out to Gmail via
https://support.google.com/mail/contact/bulk_send_new
  * Try restarting your IP from time to time.


tyvm, i wish i had had this guidance available when this happened to me.


...

I hope this will help some of you. Being blocked by Gmail is hard, and 
facing a black box makes it even harder. You don't know where to look, 
you don't know what to do, you don't know who to reach out to.


at MAPS we got sued a lot, but we always answered requests for removal 
from the RBL. what google is doing is an active harm which discredits 
the whole field of distributed reputation. there should never be 
deliberate operational impact without transparency and accountability.



... but the general feeling was clearly that Gmail is not on this world.

May your IPs stay out of DNSBLs.


yes, and yes.

--
P Vixie

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