so i talked to my web developer guru, and he talked with his web developer guru (who is a guy at godaddy… which, in my impression, means either that he knows a lot and doesn’t get the chance to actually touch any of the machines, or he knows practically nothing and has his hands inside a lot of machines), and they both agreed that the evidence pointed towards me having a spammer in my email system. the primary reason for this was that, despite the fact that i have email with chinese characters automatically sent to /dev/null, i’m still getting spam with chinese characters in the subject line.

at the bottom of the global email filters window, there is a place where you can test email filters, to see what they do. after the first few, i just assumed that they worked, because they always did, so i didn’t pay much attention to the filter tester. it turns out that you can run mail that has already been delivered through the filter tester, to determine which filters caused it to end up in the wrong place.

what i discovered is that the chinese email filters work fine, but if the filter encounters an element that has a different rule than sending it to /dev/null, then it will do that, instead. once i resolved the conflict over which rule to use, the emails that are supposed to be getting delivered, are getting delivered, and the mail that is supposed to be deleted, goes to /dev/null

i still have a whole bunch of directories that have the name of my old host provider in my email system, that i really want removed, if it is possible, but the fact that it now looks like i DO NOT have a spammer/cracker nesting in my system is a great weight off my mind… and it means that i can put switching to gsuites on the back burner for the time being. 👍

ETA: i also discovered, using the same reverse-filter-testing procedure described above, why some random emails that don’t have any obvious reasons to be filtered, were getting filtered anyway. it turns out that i’ve got a whole bunch of filters that look for TLDs, such as .bid, .host, .win and so forth. except that the filter doesn’t care whether it’s a TLD, somewhere in the middle of the URI, or in some javacript code that is in the body of the email. so a MTA named “mailpod.hostingplatform.com” was getting filtered because it contained “.host”, and another mail was filtered because it had a javascript variable named “character.bidirectional”, which contains “.bid”…

i changed all of the TLD filters to look for an extra character that differentiates it from things that aren’t TLDs: the “dot letters” combination, followed by a forward slash — / — is what MAKES IT a TLD. why i didn’t think of that when i originally made the first filter is a gross act of stupidity on my part. 😕