The same threat actor has leaked larger amounts of data from LinkedIn dated 2023. They claim this new data contains 35M lines and is 12 GB uncompressed.
The same threat actor has leaked larger amounts of data from LinkedIn dated 2023. They claim this new data contains 35M lines and is 12 GB uncompressed.
That’s annoying! It’s not been my experience, out of curiosity do you have any theories why your domain/aliases got blocked?
For my domain it was put on a spam list that various ISPs use.
When I spoke with one ISP they said it’s because I had an open email address situation going, where a spammer can send a spam email out to a third party and on the reply address to they can make up anything as an email address for my domain name and it would be ‘valid’ because my domain email server was set up to receive all emails that you described.
And because of that I got put on a global spam list which many ISPs use. At the time I didn’t even know about my domain being on the list, I just noticed a big drop in emails I was receiving.
FYI this happened over a decade ago, so I do not know if that is the current practice today. But better to make sure any email addresses to your domain that is not valid does not go through. No “catch all” bucket situation.
That’s not because you have a wildcard. That’s because you need to implement DKIM, DMARC, and SPF records to prevent others from using your domain name to send mail.
MTAs use those standards to verify if somebody is permitted to send email for your domain. If you don’t have those set then you can get what that ISP described.
Well I used a third party service to host my domain, and as far as I can remember (like I said this was over a decade ago, maybe almost two decades), everything was set up correctly at that time.
Not trying to dispute what you said, but I can at least speak towards that as far as we knew at the time we had the domain set up correctly on our end, the stuff we could control.
The only thing is we had a catch-all bucket setting turned on for emails to be forwarded to an internal email address of our domain.
There has never been a correct way to deploy these services, just increasingly complex, featurefull, and or secure ways to do it
You forgot one way.