[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Unable to email anyone from my primary domain name; thanks Google Mail and G Suite.
On 10/28/19 1:43 PM, Alain Hebert wrote:
> Â Â Â Hi,
>
> Â Â Â This is not an assumption, it is my experience.
Mine as well. My mail server's PTR records are identical for IPv4 and
IPv6. IPv6 fails and IPv4 is fine. I disabled IPv6 for gmail.com.
>
> Â Â Â Sorry it didn't fit your case.
>
> -----
> Alain Hebertahebert at pubnix.net
> PubNIX Inc.
> 50 boul. St-Charles
> P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
> Tel: 514-990-5911http://www.pubnix.net Fax: 514-990-9443
>
> On 2019-10-24 17:10, Constantine A. Murenin wrote:
>> You're assuming that IPv6 is at fault, but as I've already mentioned,
>> if I change the From and MAIL FROM to one of the other domains with a
>> DNS zone similar to the primary one with crontab-acquired "very low
>> reputation", without changing anything else, then the identical
>> messages do get through at the SMTP stage â?? and show up directly in
>> Inbox â?? i.e., don't even end up in the Spam folder, either.
>>
>> So, sorry, but I'm not going to go around blocking my IPv6 for no reason.
>>
>> C.
>>
>> On Thu, 24 Oct 2019 at 07:41, Alain Hebert <ahebert at pubnix.net
>> <mailto:ahebert at pubnix.net>> wrote:
>>
>> Â Â Â "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 Hebertahebert at pubnix.net <mailto:ahebert at pubnix.net>
>> PubNIX Inc.
>> 50 boul. St-Charles
>> P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
>> Tel: 514-990-5911http://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.
>>
>>
>
--
John
PGP Public Key: 412934AC