Base64 encoding of a text representation of an IP address and date seems inefficient.

There are 4 octets in a ipv4 address, where each octet is one of 2^8 possible integers. The entire 32-bit ipv4 address space should therefore be possible to encode in 6 characters in base64.

Similarly, a timestamp with a precision/resolution in seconds can generally be represented by a 32-bit integer, at least up through 2038. So that can be represented by another 6 characters.

Or, if you know you’re always going to be encoding these two numbers together, you can put together a 64-bit number and encode that in base64, in just 11 characters. Maybe even use some kind of custom timestamp format that uses fewer bits and counts from a more recent epoch, as an unsigned integer (since you’re not going to have site visitors from the past), and get that down to even fewer characters.

That seems to run less risk of the email address getting cut off at some arbitrary length as it gets passed around.

I started getting spam in German to an email address I gave to the town hall of my town. They use multiple domains to send it, but they all have the same link format that redirects to a fake AI-generated dating site. I’ve tried reporting some to the police, as well as the hosting providers, but haven’t heard back at all. I’d like to delete the address, but it’s the one town hall uses to reach me…

The myaddress+shop@gmail.com should be trivial to defeat by a spammer. Its a very simple string remove/replace to get back to a stock email address, or change it to impersonate another service, eg. myaddress+netflix@gmail.com.

It’s only useful for the actual service, after that, you can’t rely on it.

The idea of having them send an e-mail to an address containing their IP is clever, however you need to authenticate that the person who sent the e-mail is either somebody who queried your site, or somebody that got the address from somebody who queried your site or else you could just figure out how to generate that base64 yourself and impersonate somebody else’s IP address which could have catastrophic results if you then fed these IPs into something like a block list and suddenly you’ve blocked Microsoft/Office 365. To be fair, I doubt anybody is going to try and reverse engineer one person’s code to then figure out how to impersonate who sent spam, but if this became a widely distributed program you could just pull off Github then it would be more concerning.

A couple ways to solve this:

1. Sign the information before encoding it in Base64 so you can verify it came from your site and wasn’t just spoofed. This has the upside of being stateless since you don’t need to keep a record of every e-mail you’ve generated but comes with the disadvantage of spending CPU time signing the text which could be exploited as a DDoS.
2. Spit out a random e-mail address and record which e-mail address was given to each IP. Presumably you wouldn’t hold on to this list forever since IPs change owners frequently and so an IP that was malicious 1 month ago could be used by a completely different person now and so you can trim this list down once a month to avoid wasting disk space. You’d probably also want to keep some amount of these requests in memory (maybe 10Mb or so) to avoid ruining your IOPS.

All this said, I think your time is better spent with the using unique e-mail aliases as the author suggested but with 2 changes: 1) use aliases which are not guessable to prevent somebody from making it look like somebody else was hacked (e.g. me+googlecom@ gets compromised, but the spammer catches on and sends from me+microsoftcom@ instead to throw off the scent) and 2) don’t use me+chickenjockey@, use chickenjockey@ or else the spammer can just strip “+chickenjockey” from the address to get the real e-mail address.

As much as I like this approach, I want to hear if the author has at any time successfully sued anyone with it because I seriously doubt it.

That base64 is so long, and doesn’t need to be. An IP address is 4 bytes so it could be represented as simply 8 hex digits (base64 also expands to 8 due to padding).

How the turntables have turned π radians. Maybe. We’ll see.