Thank you Arne and Med for your valuable suggestions. I'm new here. Appreciate
your help in this regard. Regards,Stanley V.
---------- Original Message ----------
From: Arne Jensen <darkde...@darkdevil.dk>
To: "v...@netzero.net" <v...@netzero.net>, mailop@mailop.org
Subject: Re: [mailop] Spam from Google Work Space sender domain via Google IP(s)
Date: Wed, 28 Apr 2021 09:15:09 +0200
Den 28-04-2021 kl. 06:27 skrev vsai--- via mailop:
> I've been receiving spam and phishing scams from Google IP(s).
>
> All these messages have the sender domains associated either with
> Godaddy or with Google work space.
>
> Some of the sample sender domains are listed below:
>
> **********************************
Several of these domains exists in Spam Eating Monkey's FRESH lists,
since they were registered very recently, some of them 2 days old, some
of them around 10 days.
-> https://spameatingmonkey.com/
You might be able to use the FRESH list to trigger on domains that were
registered (very) recently, with their FRESH lists.
A couple of the listed domains that does not appear in SEM FRESH, seems
to exist in URIBL's "black" zone:
-> https://uribl.com/
Licenses and terms/conditions for various of such "reputation" lists may
vary quite a lot, so you will seriously need to go through their
policies, to figure out if you are able to incorporate their data in
your systems.
Not doing so from the beginning, might cause severe consequences...
>
> I could see couple of patterns in these spam.
>
> 1. Spamming from Google groups with topic 25838:
>
> Example: List-Help:
> <https://support.google.com/a/bfjnusfg.lanawilliams.today/bin/topic.py?topic=25838>,
SEM FRESH and URIBL mentioned above would here require you to split it
out to the real domain, e.g. "lanawilliams.today", before you look it up.
Even if you go to
"https://support.google.com/a/this.stuff.does.not.exist.invalid/bin/topic.py?topic=25838";,
you will also be redirected to
"https://support.google.com/a/topic/25838";, so you have some options here:
a) With the classic kind of learning spam/ham in spam filters, you might
be able to make your systems"learn" the full/exact link towards being
either spam/ham, but with the amount of different possibilities there
could be, e.g.:
->
https://support.google.com/a/this.stuff.does.not.exist.invalid/bin/topic.py?topic=25838
->
https://support.google.com/a/another.one.that.does.not.exist.invalid/bin/topic.py?topic=25838
That option may not be very feasible, ... for some.
b) You could split out the "real domain" from the URI if it matches the
Google link, and then look up the domain in various of those URI / RHS
lists.
->
https://support.google.com/a/bfjnusfg.lanawilliams.today/bin/topic.py?topic=25838
(lookup: lanawilliams.today)
->
https://support.google.com/a/a.very.simple.example.net/bin/topic.py?topic=25838
(lookup: example.net)
->
https://support.google.com/a/another.fancy.example.co.uk/bin/topic.py?topic=25838
(lookup: example.co.uk)
Depending on your systems, this may not be very simple, such as e.g.
getting "example.co.uk" and other second-, third- (or further level)
registrations like there.
For the extracting, I would however suggest using the Public Suffix list:
-> https://publicsuffix.org/
There are some libraries out there for many programming languages out there.
>
> 2. Received lines has lines either single or multiple "X-Received: by
> 2002"
>
> Example:
> ***************************************************************
> X-Received: by 2002:ac2:5f75:: with SMTP id
> c21mr4375339lfc.600.1618693533415;
> Sat, 17 Apr 2021 14:05:33 -0700 (PDT)
IPv6 subnet 2002:ac2:5f75::/48, refers to IPv4 address 10.194.95.117.
> Received: by 2002:a05:6512:c22:: with SMTP id
> z34ls4162850lfu.2.gmail; Sat, 17
> Apr 2021 14:05:32 -0700 (PDT)
IPv6 subnet 2002:a05:6512::/48, refers to IPv4 address 10.5.101.18.
> X-Received: by 2002:a19:7508:: with SMTP id
> y8mr7152413lfe.123.1618693532208;
> Sat, 17 Apr 2021 14:05:32 -0700 (PDT)
> ***************************************************************
IPv6 subnet 2002:a19:7508::/48, refers to IPv4 address 10.25.117.8.
These IPv6 addresses/subnets are part of the 2002::/16 6to4 anycast
network. So I wouldn't put any weight to them.
Maybe if you expanded them to the IPv4 addresses (hex decode the IPv4
with the first two groups after 2002: minus any :'s in the middle
(ac25f75, a056512 & a197508)), and then maybe if these were actually
revealing other "public IP addresses", and not private/reserved IP
addresses, there might be a chance of using them to detect stuff.
The majority (if not all) of Google email headers seem to indicate
Google is using the 10.0.0.0/8 equivalent of the 6to4 IPv6 space (e.g.
2002:a00::/24 (2002:0a00:0000:0000:0000:0000:0000:0000 -
2002:0aff:ffff:ffff:ffff:ffff:ffff:ffff)) in their internal networks.
>
> Please let us know if anyone is observing same trend of spam and what
> measures are taken to prevent these patterns.
Personally, I'm not currently experiencing it with Google, however - the
trend of using (... very) fresh domains seems to have raised over the
last months, and I do not mind rejecting domains younger than e.g. 30
days myself.
Another situation you could do to above, but which can cause collateral
damage in several situations, would be to look up each individual domain
as well, for it's A and AAAA records.
Currently, all the domains you listed point to 34.102.136.180 (A), and
no AAAA records.
The IP addresses, e.g. 34.102.136.180 in this case, could potentially be
used as well, to score messages positively/negatively, or even reject
them outright.
But two different and independent parties (a good guy, and a bad guy)
could be renting a classic shared hosting packages, they are assigned to
the same web server, the one domain could via email be spamming, where
the others wasn't.
Doing stuff like this one would hit both of them, but you could always
argue, if the good guy is supporting companies that support bad guys,
why would you care about them?
>
> Does any one have any contact with Google, where we could forward such
> complaints. I've tried sending mails to Google IP abuse contact
> address(s) and also to Google work space domain contact
> <ab...@domain.com> & <postmas...@domain.com> but of no use.
postmaster@{domain} and abuse@{domain} could potentially reveal that
your email account (the target of the spam) is alive, and confirm to bad
guys that the inbound email works (... which might eventually be leading
to even more spam).
I would report the spamming to the provider, through the abuse contact
(listed in RIPE, ARIN, ... et cetera) for the very first mail server's
(that you do not trust) IP address.
If 192.0.2.25 is the one delivering the message for v...@netzero.net
directly to it's MX records (e.g. mx.vgs.untd.com / mx.dca.untd.com),
then 192.0.2.25's abuse contact (from RIPE, ARIN, ... et cetera) would
be the one I would send it to.
You cannot trust earlier Received: headers than that, so therefore, if
192.0.2.25's abuse contact means the issue needs to be dealt with
somewhere or somehow else, they are then the ones who needs to take it
further from there, and not you, ... as their IP address were the one
targetting your network. It's not your problem to fix the stuff that
passes through THEIR network.
>
> Appreciate your help in this regard.
Hope at least some of all this will be helpful!
--
Med venlig hilsen / Kind regards,
Arne Jensen
____________________________________________________________
Sponsored by
https://www.newser.com/?utm_source=part&utm_medium=uol&utm_campaign=rss_taglines_more
One Deputy Killed, Another Hurt in North Carolina Standoff
http://thirdpartyoffers.netzero.net/TGL3231/608a4b9cc6ab54b9c2a5dst03vuc1
Biden's Speech to Congress, and the Reactions to It
http://thirdpartyoffers.netzero.net/TGL3231/608a4b9ce9f084b9c2a5dst03vuc2
Federal Investigators Swoop on Giuliani's Apartment, Office
http://thirdpartyoffers.netzero.net/TGL3231/608a4b9d191c14b9c2a5dst03vuc3_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
