> This sort of thing is why every company and every mailing list has a different address for me. Once one is compromised, it goes direct to /dev/null.

It's not just a matter of dev nulling something compromised, but also to make it difficult to know where to send a phishing attack to.

Troy did half of that. He used mailchimp@_______ for this, so it might have been guessed, or leaked elsewhere, and he won't be able to narrow down which.

And if someone sees your facebook@______ leaked elsewhere, it's not a stretch to assume you use mailchimp@_____ or twitter@_____ or...

Should use something totally random. Or maybe first 10 chars of hash(servicename + common salt) so you don't have to keep track of too much. Or something similar with encrypt the service name with your GPG key and take the first 10 ascii of the output.

For the read-only, newsletter-type mailing lists, this makes sense and I do it too. But for mailing lists that are used more as a forum, I like posting with a recognizable, memorable email address. I've gotten some really sweet emails from people who read a post I made and reached out to me directly in the past. I wouldn't want to miss those, spam be damned.

I can receive on all those addresses, so that isn't lost. They are in a subdomain with catch-all and a black-list of abused addresses. I will lose mail if someone responds on an old address that is now pointed at /dev/null, but I doubt I've lost much, if anything, that I'd care about, that way.

I have seen some senders apparently guessing a catch-all is in operation as I've received junk on a few addresses that just look like keyboard mashing. I have ideas for potential workarounds to solve that, but it doesn't happen enough that it has irritated me into pursuing one of those ideas further.

There are currently no two-way mailing lists I'm a member of so that is not an issue. Last time I did interact with a group that way, it just meant making sure my mail client used the right outgoing identity, just as I do when replying to a particular company, so the list didn't see me as an unauthorised sender.

The only other complication was once hitting a shopping site that rejected someaddress@subdomain.domain.tld. They were checking by regex (client-side anyway) that there was only one or two “.”s in the hostname part, and if there were two there were at most three character between them. Assuming they were applying the same validation server-side I didn't bother trying to circumvent that. I could have used another address, but if there was shoddy coding in the join workflow there presumably was everywhere else to, so I didn't actually trust the place enough to interact with it further let alone give it payment details.