Google Groups entirely ignores SMTP time rejections
I have a very old mail address that I have made into a complete
spamtrap through my sinkhole SMTP server. Simplifying only slightly,
my SMTP server rejects all email to this address no later than after
the end of transferring the message (at the message termination after
DATA). When it rejects email this late, I capture the full
On September 5th of last year (2018), this spamtrap email address rejected a message from Google Groups informing it that it had been added to a spam mailing list:
Subject: You have been added to Equity Buyers Network
From: Equity Buyers Network <firstname.lastname@example.org>
Google Groups ignored this rejection and began sending email messages
from the group/mailing list to my spamtrap address. Each of these
messages was rejected at SMTP time, and each of them contained a
MAIL FROM address (a VERP),
which good mailing list software uses to notice delivery failures
and unsubscribe addresses. Google Groups is, of course, not good
mailing list software, since it entirely ignored the rejections.
I expect that this increases the metrics of things like 'subscribers
to Google Groups' and 'number of active Google Groups' and others
that the department responsible for Google Groups is rewarded for.
Such is the toxic nature of rewarding and requiring 'engagement',
especially without any care for the details.
Since September 5th of 2018 up until yesterday, the spamtrap address has rejected ten email messages. These came September 10th, September 21st, November 20th and 23rd, December 22nd, 24th, and 31st (the last of which prompted this entry), February 4th, and now June 12th and 21st. Many of them were stock touting spam (or in general asset touting spam); some were touting the 'message broadcasting' services of the company that established the mailing list. A couple were both at once, and if you guessed that this involves cryptocurrency (or at least something that sounds like it), you would be correct.
Due to writing this entry and thinking about the issue, I've changed my spamtrap system so that it will no longer accept any email from Google Groups and will reject such email attempts immediately as 'uninteresting spam' that is not even specifically logged. I'm not interested in being part of Google's outsourced abuse department, and this insures that I don't have to think about this any more.
(At one point I might have been interested in just what spammers set up on Google Groups, but I no longer am. That Google Groups is a de facto spam service is no longer news and I am not interested in the specifics, any more than I am with, say, Yahoo Groups.)
Sidebar: Who the responsible party is
The claimed information is a cluster of corporate names and two listed addresses. I will let you consult search engines for their websites, since I have no desire to contribute anything even approaching links. They are:
Questrust Ventures Inc
Equity Buyers Group
1875 Avenue of the Stars Ste 2115
Century City CA 90067
iAstra Canada Richmond BC, Canada, v7y-3j5
That this organization claims a Canadian address (which may or may not be real) means that they theoretically definitely fall within the reach of Canada's anti-spam laws, which they are pretty definitely acting in violation of. Of course the odds that they will ever be held to account for that are probably low.
We get a certain amount of SMTP MAIL FROM's in UTF-8 with odd characters
On Twitter, I said:
There sure are a surprising number of places that are trying to send us SMTP MAIL with a MAIL FROM that contains the Unicode character U+FEFF (either 'zero width no-break space' or a byte order mark, apparently, although it's never at the start of the address).
I was looking at the logs on our external mail gateway machine
because we use Exim and I was interested to see if we had been poked
by anyone trying to exploit CVE-2019-10149.
I didn't find anyone trying, but I did turn up these SMTP
A typical example from today is:
H=(luxuryclass.it) [220.127.116.11] rejected MAIL <Antonio<U+FEFF>Smith@luxuryclass.it>
<U+FEFF>' bit is me cutting and pasting from
Unicode codepoints this way.)
These and similar hijinks have been going on for some time. We have logs going back more than a year, and the earliest hit I can casually turn up is in late May of 2018:
H=(03216a51.newslatest.bid) [18.104.22.168] rejected MAIL <NaturalHairCare<U+200B>@newslatest.bid>
(U+200B is a zero width space, so this feels like something similar to the use of U+FEFF.)
In October of 2018, we saw a few uses of U+200E 'left to right mark':
H=(0008ceef.livetofrez.us) [22.214.171.124] rejected MAIL <TinnitusRelief<U+200E>@livetofrez.us>
Then at the start of November of 2018 we started seeing U+FEFF, which has taken over as the Unicode codepoint of choice to (ab)use:
H=(office365zakelijk.nl) [126.96.36.199] rejected MAIL <Howard<U+FEFF>Smith@office365zakelijk.nl>
We have seen a flood of these since then; they're pervasive in our logs
based purely on looking at things in
less (someday I will work out how
grep for Unicode codepoints by codepoint value, but that day is not
On a quick check, the most recent ones come from IP addresses that are
listed in the SBL CSS, as well as any
number of other DNS blocklists. I don't really care, since as long as
they're helpful enough to put UTF-8 bytes into their
MAIL FROM, we'll
reject all of their email.
PS: I checked the raw bytes of some of the U+FEFF
MAIL FROMs, and
they really have the byte sequence 0xEF 0xBB 0xBF that is a true
UTF-8 encoded U+FEFF. I'm relatively confident that Exim isn't doing
any character mangling on the way through, either, so we're almost
certainly seeing what was really on the wire.