Re: [mailop] $GOOG

[Dan Mahoney via mailop]

[Note that I'm replying to add a datapoint or two to this whole thread, rather 
than to just one person's comments.  (The in-reply-to header has to be set to 
something, it might as well be the first post).]

To add to a long (looong) thread, let me add something indecipherable, but it 
requires looking at an image from google postmaster tools:

https://imgur.com/a/BSANX0s 

According to this graph, for the past many, many days, we've had 100 percent 
SPF and DKIM compliance with all messages we send.

But by the same graph, our dmarc compliance is all over the place.  DMARC has 
no headers it adds to outbound mail, our record hasn't changed in months.  If 
*either* SPF or DKIM validate 100 percent of the time, my DMARC should also be 
100 percent, no?

Is this because some machine under (our org) is sending invalidated mail for 
other domains, but for all mail received with a From: header of that org, 
everything looks good?  (Like a listserv would do).

If so, that's graphing two RADICALLY different things on the same misleading 
graph.  (Also, the graphing algo hides the dmarc line behind the SPF line, 
c'mon google, you're smart enough to figure out how to overlap those lines 
visibiy).

If this is our mailman lists causing this stupidity, does it make sense to 
stuff those under a secondary domain and a distinct /24 and /48?  

==

Related, looking at dmarcian, we're having a bunch of chinese ipv4 addresses 
spoof us and attempt to send to google, but those also fail SPF *and* DKIM.  
We're a very old (older than gmail), short-named domain so it might make us 
attractive, but *none* of that spoofing shows in that google graph either.

(https://imgur.com/a/nxrSMIK )

I'm trying to play the correct game here, but Google postmaster tools shows no 
ipv6 addresses when I click on "ip reputation", and until the issues a month 
ago, that was all we did.  We've been dual stack for over a decade (although 
gmail hasn't).

Things simply do not correlate.

-Dan

> On Apr 13, 2022, at 2:43 PM, Paul Vixie via mailop  wrote:
> 
> 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

___
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] Fwd: RFC 9228 on Delivered-To Email Header Field

[Jakub Olexa via mailop]

John, Dave,

we use postfix with aliases and dovecot and delivered-to header always 
shows the actual mailbox it was delivered to. Eg. you send me an email 
to ja...@mailkit.com and Delivered-To will be ja...@mailkit.eu because 
that is the actual name of the mailbox.


Jakub Olexa
Founder & CEO
E-mail: ja...@mailkit.com
Tel: +420 778 535 877 

Mailkit - Closing the circle between Deliverability and Engagement 



On 15.04.2022 5:42, Dave Crocker via mailop wrote:



On 4/14/2022 5:22 PM, John R Levine wrote:

On Thu, 14 Apr 2022, Dave Crocker wrote:

Without knowing what mail software your provider is running, there is
no way to tell.


The benefit of an over-the-wire approach to specification writing is 
that all that matters is what goes... over the wire.  One does not 
need to know the 'intent' or 'thinking' or who the source is, or 
whatever about the source of the data that goess over the wire.  One 
merely needs to know what goes over the wire, and compare it to what 
is in the specification.


So, just so I don't misunderstand, you're saying that one can tell 
what a complex piece of software does by examining a single example 
of its output.  That's quite impressive.


John, I said nothing of the sort.  Which, of course, you know.

What is actually impressive is that what I recited about the 
over-the-wire model for interoperable protocol specification is the 
very mundane and long-standing foundation for Internet 101, but you 
somehow seem not to understand it.  Very large wow.




Section 4, second bullet

If a receiving system's delivery process applies mappings or
transformations from the address used by the MHS to a local value,
this new value SHOULD also be recorded into a separate Delivered-To:
field when transit and processing using that address successfully
complete. This ensures a detailed record of the sequence of handling
addresses used for the message.


covers that form of string.


It doesn't, we explained why last year, but since I doubt anyone else 
is interestied in this p*ing match, I'm really done now.


I asked a very simple question, for you to provide the technical 
specifics that are the basis for the conclusion you keep uttering.


Rather than participating in a constructive technical exchange, you 
have repeatedly insisted on aggressively relying on an appeal to your 
authority about this.  But that's not how open, collaborative 
technical work is done.


In effect, you've been done for quite a few months.

d/
___
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] $GOOG

[Grant Taylor via mailop]

On 4/14/22 9:44 PM, Rob McEwen via mailop wrote:
Still, that all systems are imperfect - isn't and shouldn't be an excuse 
to not aim for best practices, and that's even less of a valid excuse to 
institutionalize or hard-wire mediocrity.


I *completely* agree.

Though falling short of best practice doesn't mean something imperfect 
is inherently bad.


Not sure I follow you here - but if anything - my recommendations were 
going a step further than RFCs, but not actually defying or breaking RFCs.


I don't know how I as a mail operator can cause / persuade / influence a 
different mail operator to change what they are doing.  Certainly not in 
mass.  --  The only real control that I have is over what I do (not) do.


Here is a key distinction that might help - when I said that I was open 
to a very limited/rare after-connection time filtering, and then gave 
the example of a zero-day virus not being delivered to the inbox due to 
addition information discovered in after-connection filtering - here is 
a huge distinction - I was implying that the spam filter has an amazing 
level of accuracy in determining so - and I'm also going by the very 
sound and reasonable principle that a messages that might potentially be 
a hand-typed legit email - are much more deserving of getting a 
connection time response that accurately reflects the status of the 
message - whereas the criminal sending a zero-day virus deserves NOTHING.


It seems that I misinterpreted your "allowing for an unknown exception" 
as a larger tolerance for after the fact filtering.  --  I'm sorry for 
that misunderstanding.  Thank you for clarifying.


... in contrast - messages known to contain viruses or malware - with 
a high degree of certainty - are situations where these are sent by 
actual criminals - and those senders deserve nothing.


Is it fair to summarize your position as the following?

Perform any and all filtering /during/ the SMTP transaction that is 
possible so that the message can be rejected.


What is your opinion on sending DSNs after message acceptance except 
when the purported sending address is known to be untrustworthy.  Thus 
trying to avoid message black holing.




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

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