Actually RFC 5322 says that you can't have two consecutive periods.

What RFC 5322 says you can do and what Google will allow you to do with an @gmail.com user part are two different things.

Except in this case, where they're the same thing.

Oops, you're right. Did they also support user+somestring@gmail.com to be equal to user@gmail.com as well?

Yeah, they support +something. Sadly lot of websites don't accept it as a valid email address because of the +.

Found a mailing list ("marketing") service that allowed you to sign up with a +, but any 'unsubscribe' was a link to a URL with your email in it, with the + sign in it, and... the unsubscribe page could magically never find your address to unsubscribe you. I submitted this as a bug report to the service, and was brushed aside. At that time, I also had a couple friends who worked there, and tried to run it up the flagpole there, and I was told about half the folks there didn't understand the problem, and the other half didn't really care, because the + trick was seen as very niche. So I started reporting all the newsletters I got as 'spam' - well after I'd tried to unsubscribe.

Did you try to replace the + in the unsubscribe URL with %2B (the urlencoding of a +)? Because interpreting the URL on the server will almost certainly mean urldecoding the arguments which will turn + into a space.

Doesn’t the browser do this for you?

Nope, cause + used to mean space. So plus symbol has sometimes to be left alone, some times replaced - due to still supporting legacy stuff and the newer RFC that makes + go away.

FWIR, yes. And it didn't work. They had some weird parsing going on to deal with some weird legacy stuff from years earlier, and... it made life more complicated than it needed to be.

I ran in to the exact same thing.

My solution was subscribing "legal+i_bet_you_will_fix_it_now@service.com" to the same list.

You could sign them up using many + emails

I wonder if that's because they know people use + to tag for later spam blocking, or is it just a lazy regex user who needs to read this article?

Our website blocked it inadvertently, we were using ASP.NET Identity which has internal email validation which by default does not accept it. Just flipping a flag in the configuration is enough to allow it, but until someone reported the problem I wasn’t even aware it was blocked.

IME it's the latter, but not because they are lazy, but because email validation is hard. The lazy regex was in the late 90's early 00's when any email that didn't end in .com, .edu or .net failed!

The problem is insufficient laziness. Just check that the email contains an `@` sign, and validate later by corresponding with the address.

    if "@" in email:
      send_confirmation(email)

Which is truly terrible. I mean, here's a valid email that was used in the early 90s:

    sdchema!mhtsa!australia!chris@Nosc

I just wrote a post[1] about using the user+alias@example.com instead of user@example.com. Basically treat your "regular" email address as a spam target, and use user+alias for all wanted communications. The +alias can be a random string, making it harder for spammers to guess.

This works in gmail for both sending and receiving, although sending as you+alias@gmail.com requires messing around in the settings[2] and having to remember to select a non-default From: address in your outgoing mail.

[1]: https://alexshroyer.com/posts/2022-09-01-Default-Honeypot.ht... [2]: https://webapps.stackexchange.com/questions/3598/is-there-an...

If this gained widespread adoption, then spam would just +string and you'd have to allow-list.

Allow-list isn't the worst, but this isn't a long-term solution in and of itself

True, but the nice thing is it that allow-lists can be handled transparently by your email client.

Never saw this +string before? Mark as spam.

Is the +string missing? Spam.

Recognize this +string from your "Sent" folder? Keep.

Signing up for something? Generate a pseudorandom +string and add it to the allow-list.