"Trust Andrew(tm) when I say this."
Disable your IPv6 access to their mail server.
At Google, something hasn't worked, well since the beginning of
time, when it come to propagating your domain reputation to <something>
handling incoming emails using IPv6.
I just had the case last week when a customer account go abused and
dropped their domain reputation to 0 for GMail/GSuite. Nothing worked
until I made outgoing emails connection "icmp unreachable" thru IPv6.
Example with ipfw.
ipfw add [rule number] reject ip6 from me6 to any 25
ipfw add [rule number] reject ip6 from me6 to any 587
Good luck.
-----
Alain Hebert aheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443
On 2019-10-23 20:18, Constantine A. Murenin wrote:
Dear NANOG@,
I'm not sure where else to post this, and this is not really new,
either, but I think I have a new take here.
I use my own personal domain name for various UNIX stuff, including
sending log-related things to myself out of cron, which end up in my
own Gmail.com account, either directly, or through forwarding (w/o
SRS). (I do not use G Suite for my own domain name, for obvious
reasons; just the consumer-based gmail.com <http://gmail.com> email
address from the old times of invitation-based registrations.)
Over the years, I sometimes had certain messages rejected by Gmail,
but it was a very low rate of rejection (less than 5% for any mail I
cared about), and wasn't a major problem (usually only some automated
messages would be rejected).
A couple of months ago, I setup some new scripts that would send me
new nightly emails. It's all plain text, but had a few dozen of
domain names present (it's logs). Absolutely no links, just plenty of
domains which I don't control. So, Gmail has been presenting most of
these messages with their red warning label that the email contains
malicious links, even though all of these emails contained zero links,
zero URLs to any of these unknown domain names, zero URL schemes, zero
"http://", zero "https://" etc. You get the idea.
Since about a few weeks ago, I am now seeing at least a 95% rejection
rate for my domain name, for ALL email, including the forwards.
Including emails which I send to myself from within Google, and which
get forwarded back to Gmail by my UNIX machine (which is not known to
break Gmail's DKIM, either, although it's also difficult to test,
because when it does get through, it's automatically marked as a
duplicate by Gmail, so, you don't get DKIM status from Gmail by
looking at the headers, since you only get to examine the original
copy that was sent, not the forwarded duplicate that was subsequently
accepted). I.e., emails with a passing DMARC still get rejected.
The funny thing is, Google doesn't actually blacklist my primary IPv6
address in my own /48 from which all of my messages originate; even
though the rDNS resolves to a subdomain on the very same domain name
which they've blacklisted "due to the very low reputation". They've
blacklisted just the main domain name that I use for my own
non-Gmail-hosted mail. Sending the same messages into my Gmail.com
from a different domain name in MAIL FROM, which is served from the
same zone file DNS-wise (e.g., an SPF pass), through sendmail's `-f`
option, or with Mutt, makes the messages go through (even with rDNS
being "low reputation"); sending it from my primary domain name in
MAIL FROM results in the following:
>>> DATA
<<< 550-5.7.1 [2001:470:xxxx:: 19] Our system has detected that
this message is
<<< 550-5.7.1 likely suspicious due to the very low reputation of the
sending
<<< 550-5.7.1 domain. To best protect our users from spam, the message
has been
<<< 550-5.7.1 blocked. Please visit
<<< 550 5.7.1 https://support.google.com/mail/answer/188131 for more
information. 135si403977wma.43 - gsmtp
554 5.0.0 Service unavailable
The support article suggests using Postmaster Tools; great, never
heard of it, sounds cool; let's verify our domain, and try it out,
hopefully, there's a solution right there.
However, after verifying my domain name through DNS for Postmaster
Tools, it is revealed that Postmaster Tools cannot tell me anything at
all, with all tabs and screens being 100% blank, allegedly because I'm
not actually a mass email sender (I don't send hundreds of emails a
day or whatnot), and they're too afraid that I'll figure out why my
mail doesn't actually go through, instead of signing up for G Suite.
Right now, I've had a business need to reply to a work-related email
from some other business.
This is what I got after sending my reply from my primary domain name
through mutt — a nice double rejection by both the G Suite and Gmail
in a single bounce generated by my server:
----- Transcript of session follows -----
... while talking to aspmx.l.google.com <http://aspmx.l.google.com>.:
>>> DATA
<<< 550-5.7.1 [2001:470:xxxx:: 19] Our system has detected that
this message is
<<< 550-5.7.1 likely suspicious due to the very low reputation of the
sending
<<< 550-5.7.1 domain. To best protect our users from spam, the message
has been
<<< 550-5.7.1 blocked. Please visit
<<< 550 5.7.1 https://support.google.com/mail/answer/188131 for more
information. z11si12494671wrw.137 - gsmtp
554 5.0.0 Service unavailable
... while talking to gmail-smtp-in.l.google.com
<http://gmail-smtp-in.l.google.com>.:
>>> DATA
<<< 550-5.7.1 [2001:470:xxxx:: 19] Our system has detected that
this message is
<<< 550-5.7.1 likely suspicious due to the very low reputation of the
sending
<<< 550-5.7.1 domain. To best protect our users from spam, the message
has been
<<< 550-5.7.1 blocked. Please visit
<<< 550 5.7.1 https://support.google.com/mail/answer/188131 for more
information. 135si403977wma.43 - gsmtp
554 5.0.0 Service unavailable
Changing MAIL FROM into a non-primary domain name (served out of an
identical zone file, basically) gets the message accepted, without
DKIM, without the 4-minute delay that many "suspicious" messages have
had for months now, from the very same IPv6 address with the rDNS
pointing to the domain name with "the very low reputation", and it
shows up in both my own Gmail as well as, presumably, in the G Suite
account of the business partner I was replying to. (Note that this
trick where the rDNS domain gets ignored works only for new emails
with a passing SPF; I presume the rDNS still prevails in bringing the
"low reputation of the sending domain" for forwards, as they don't
seem to succeed any longer now.)
There are a number of possible tl;dr: takeaways here:
* don't spread the monoculture — don't use G Suite for your organisation;
* don't send crontab output to your Gmail from your primary domain name;
* don't use Gmail.
What is my own takeaway here?
* Without being an anti-Google zealot, from a purely practical
perspective, since my Gmail account no longer contains the mail I care
most about, as it gets rejected on the SMTP layer, I'll have fewer
reasons to use it.
* I'll now have no other choice but to modify my setup to stop
forwarding to Gmail, because my business contacts don't need to see
all these bounces that are now taking place.
* Since so many businesses are G Suite useds, I'm still looking for a
solution to get rid of the "the very low reputation of the sending
domain" from a domain name I've been using since 2007, and which I'm
100% convinced was blacklisted by Google entirely for me sending
crontab with system logs (zero HTML, zero URLs) to my own Gmail. I
have SPF and DMARC all setup and passing since years ago, which
doesn't stop this issue from occurring. Merely switching the name of
the domain in From and MAIL FROM to any other domain I own (which
points to the very same MX) appears to be my workaround for now.
Some possible suggestions for Google, if I may:
* Maybe don't convert schemeless domain names which are non-URLs into
"malicious" URLs? (They already do seem to block them from being
presented as links in the UI in such an instance, but there's little
reason for trying to convert these domain names into links in the
first place.)
* Maybe don't consider harmless plain text emails with a bunch of
domain names to contain malicious links when they don't?
* Maybe don't assume everyone with a domain name runs a G Suite?
(Their whole troubleshooting guide is built around it.)
* Maybe don't assume everyone with a domain name sends hundreds of
emails from their domain name per day? (They seem to limit Postmaster
Tools based on such a criterion.)
* Maybe don't blacklist a domain name for sending harmless logs to a
Gmail account that lists said domain name as an alternative From address?
Cheers,
Constantine.