(And if they do, if anyone is actually reading the mail coming to those addresses.)
I used to but I got so much spam and 0 actually legit mails to these addresses on my own domains so I stopped accepting externally incoming mails for those names/aliases.
I still run those names for many domains I operate. Only info@ gets the spam. The others are quiet - but I've actually gotten real emails (in 2022 even) to postmaster and hostmaster.
These types of addresses are actually used by corporate anti-spam software and they are called "honeypots". The idea being you setup a inbox with no public email address and report any IP Addresses sending it emails. There is no legitimate reason someone should be emailing these addresses, so it's an obvious flag that someone is being naughty.
> Denial of service attacks (flooding a mailbox with junk) will be easier after this document becomes a standard, since more systems will support the same set of mailbox names.
I've managed a number of RFC 2142 mailboxes and while they all got spam (the dumb spammers would even send to abuse@!) it wasn't any worse than the other published email addresses on those systems and the volume was spam was still less than what our typical user would see (since nobody using postmaster@ used it to sign up for everything under the sun).
The spam we got was often useful for abuse handling and spam filtering too. It was a good thing!
Every network should have an abuse@ address. Web forms are pretty popular these days too, but every extra hoop you force reporters to jump through can cut down on the reports you get of problems on your network. It's worth dealing with the spam to make sure you're getting notified as quickly as possible.
Those addresses are role addresses; depending on what services you are providing, you should have have those addresses, and you should read them. They are often aliased to root@. They are not called "honeypots".
A honeypot is an email address that should never get email, typically because the only way a spammer can capture the address is by scraping a web-page. Role addresses don't need to be scraped; they're well-known.
I will often provide the email address postmaster@hashbang.com for people insisting they need an email address who have no legitimate reason doing so. (hashbang.com resolves to localhost. Thanks twocows...)
I suspect spammers might have given up on that. I get almost nothing for webmaster at a domain that receives plenty of spam and phishing attacks on other email addresses, and a constant barrage of spam into the web contact form.
What would explain my experience? My first guess is that spammers aren’t proactively probing these anymore, and just hit them if they’re found like any other address.
Hardly, and especially no to the GDPR. As a US citizen operating my own US site, doing no business with the EU, I do not care nor am I required to comply with EU law that has no bearing on a US citizen like me.
> As a US citizen operating my own US site, doing no business with the EU, I do not care nor am I required to comply with EU law that has no bearing on a US citizen like me.
It's actually a bit more complicated than that. Our expensive GDPR lawyers have made it clear there is still some amount of risk.
The example was of a German citizen booking American hotels for their vacation. Under the wording of the GDPR law, if their data was breached, the hotel could be held liable under a German court.
Now, the realisticness of this actually going to court or there being any meaningful penalty has not really been tested, but it's our corporate policy not to be the first ones to do so. So even for signup forms targeting Americans for American events, legal has asked us to specify to always collect country information (so we know what GDPR rules to process this person under) or include a dumb disclaimer that people from certain countries should not sign up.
I used to but I got so much spam and 0 actually legit mails to these addresses on my own domains so I stopped accepting externally incoming mails for those names/aliases.