Wandering Thoughts archives

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 SMTP DATA). When it rejects email this late, I capture the full message.

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 <equitybuyersgroup+noreply@googlegroups.com>

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 unique 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
Iastra Broadcasting

Equity Buyers Group
1875 Avenue of the Stars Ste 2115
Century City CA 90067
310-894-9854

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 MAIL FROMs with U+FEFF.

A typical example from today is:

H=(luxuryclass.it) [177.85.200.254] rejected MAIL <Antonio<U+FEFF>Smith@luxuryclass.it>

(The '<U+FEFF>' bit is me cutting and pasting from less; less shows 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) [217.13.107.153] 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) [172.245.45.182] 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) [190.108.194.226] 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 to grep for Unicode codepoints by codepoint value, but that day is not today).

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.