Am Mittwoch, 13. Februar 2019, 01:46:21 CET schrieb Christian Balzer via
Exim-users:
> And come to name it here as "The Google Lie".
>
> On the face of it this looks like another attempt to ram the
> unpalatable SPF/DKIM/DMARC cocktail down everybody's throat because of
> course Google knows best and is also a cute 800kg gorilla that won't do
> evil (honest guv!).
hmm, i'm personally not a fan of Googles Email services, but this conclusion
sound's a bit strong to me.
As the linked page states, there are "basic" things like reverse DNS and
similiar which gmail expects from "non authenticated" users - things which
are typical for many other mail services too and even recommend by major
rfcs. Without DKIM i'm not sure as i did not tested that yet - but without
DKIM it seems difficult to get a "reliable" email service up today.
>From my experience, GMail doesn't require DMARC or SPF from senders, but it
could help shifting reputation for mail services where it may makes sense..
For higher volumes GMail offers a "GMail Postmaster Account" where Postmasters
can "list" their mailservers which send to GMail - Google seems to use this
as a "abuse contact" too (which many mailservers did not really have yet but
"should" by rfc).
DMARC is not a general solution for everyone, but could help some email
entities with special applications (i.e. financial services).
> Received-SPF: pass (google.com: best guess record for domain of
> chibi@??? designates 203.216.5.73 as permitted sender)
> client-ip=203.216.5.73; ---
>
> So why do we see those failures then?
Checking the DNSBLs could makes sense, as these DNSBLs are used in many email
services and anti-spam "solutions". Currently i see i.e. a listing in:
https://www.anticaptcha.net/check/?ip=203.216.5.73
> As it turns out, Google uses Spamhaus (they're a customer, but won't admit
> to using their RBLs in public) and in particular checks mails for their
> origin IP against XBL (CBL).
There are many others who does that too - at least by any weightings.
> So Google:
> a) lies, the error is based on the origin-IP.
I did not see this as a "ly" - each Mail ISP is able to define his own
"authentication" policies to prevent spam. And as i can see your email
session was not a "authenticated one" - which leads GMail (as many others) to
much stricter validity / "authentity" checks then for authenticated one.
There is no absolute Email Service, as users have very different expectations
onto i.e. "spam" filtering / anti-abuse actions - including a different view
onto the definition of "spam".
GMail is very restrictive in this - this means GMail users have to accept
that they did not get any email they might want to - as a cost of a highly
spam reduced inbox traffic. This is a contract/decision between GMail and GMail
customers/users and not the senders to GMail.
DKIM/SPF/DMARC are not any killer solutions - they only "makes sense" in
(different) special scenarios which do not fit all email users.
Mail Providers could do their best to get around "any" anti-spam ratings of
whatever target systems in many different ways of shifting their reputations.
Even the definition of "reputation" is very diverse in the net. I.e. there are
many who did not accept non-auth emails from known dynamic. The diversity is
as large as the customer profiles and expectations in the world. This is why i
pertsonally don't like GMail - their "usage rules" (filter rules) would not fit
my personal expectations. There is no "perfect" email service.
i know the good old story of customers complaining "they did not got my
email" - but this is a issue / resposibility of the reciever (and his
decision for a emails ervice provider) as long as the sender fulfills official
specs. If this comes transparent, the stories of the "bad monopolies" who
"dictate the internet" are over. I do not know any professional operating
company relying onto highly diverse Email traffic using standard GMail for
their Email stuff.
hth,
best regards,
niels.
--
---
Niels Dettenbach
Syndicat IT & Internet
http://www.syndicat.com
PGP:
https://syndicat.com/pub_key.asc
---
