Would a better solution be a uniformed TXT record at the hostname the IP address reverses to?
Perhaps not to an email address but to a web form, where anti-bot captcha-like systems can be in place to better ensure that only legitimate concerns get through? For example, the IP address 91.132.147.157 reverses to mx.mailop.org. Mandate an abuse TXT record for mx.mailop.org, i.e. _abuse.mx.mailop.org, that lists an email address or URL to submit abuse reports. I'm not sure how automated you would want the process to be. You might consider some type of public/private key combination to authenticate a submission to the web form. For example a company like Microsoft might automatically POST to the URL listed in _abuse.mx.mailop.org and include various POST keys in their submission: _submission_domain=microsoft.com _encrypted_text=%%encrypted data%% text=%%unencrypted data%% And then the web form decrypts the data in _encrypted_text by looking for a public key listed in a specific DNS record for the _submission_domain (i.e. _submission_public_key.microsoft.com). If _encrypted_text matches text then the submission is determined to be validated. The web form owner can categorize how much they want to weigh these submissions based on the _submission_domain data key. For example, something from microsoft.com probably means more than a submission from catsanddogs.com. Because anyone would be able to set up a public/private key to automate these form submissions, but this at least lets the web form owner be aware of when a valid concern is published from an important domain. The web form owner can tabulate this data however they see fit. I know coming from the Shared Hosting industry, the owner of the IP address of a server that is sending out email often isn't the same company that's actually using the server to send out mail. An abuse report to the abuse address of the owner of the IP address may get lost before it filters down to the actual company utilizing the server. We can argue semantics of whether this is right or wrong - but I can tell you from real world experience, it happens a lot. By utilizing something like what I've described, you're much more likely to reach the actual company that's using the server that sent out the email. On Thu, Mar 13, 2025 at 12:50 PM Michael Peddemors via mailop < mailop@mailop.org> wrote: > Background: > > Compromised email accounts are on the rise, from almost every sector, > and often it is the same actors and infrastructures that are being used > as a source to send out their malware and phishing from these > compromised accounts. Historically, while we identify these threats, we > have only used it to protect our own customers, albeit we do share some > of this intel with RBL's to make that information more widely available. > > But given the high profile of some of the email servers that are being > abused, eg government email servers, we are considering actually > reporting this information back to the email operators who have the > compromised/abused accounts. > > However, we need to do this in an automated way, that creates real value > for the email operators, while not adding an undue burden to our teams. > > The challenge is that because of the diverse nature of email operators, > that simply sending an email to abuse@ seems unlikely to work in many > cases, and of course.. the recipient has to be assured that our data is > indeed accurate.. > > There are so many different use cases: > > * Small operator with a cPanel server > * Large hosting provider with many shared servers > * Enterprise and Governments still using Zimbra > * Gmail, o365, Apple > * Other large email hosting platforms > * Foreign Operators > > While, it would be nice to see everyone adopting DROP lists, and AUTH > lists, that isn't likely to happen anytime soon.. > > So, assuming we see one of the above types of operators, leaking > dangerous content, where the authenticating IP is on a known threat > database (eg, a bullet proof hoster, or IP associated with a well known > APT actor), the questions are: > > * Should we notify the operator? > * How BEST to notify the operator? > > Of course, we could just reject the email as normal, (but usually the > only person that would even notice is the bad actor themselves), we > could report the email server to an RBL given it is sending dangerous > information (of course, Gmail and o365 might be hard to do that). > > And of course, no use sending alerts, if they will simply be ignored.. > > Like to hear from the community, any and all ideas surrounding the topic > of feedback intel to email operators when they have compromised emails, > from sources that they should block to protect their customers.. > > Comments? > > > -- > "Catch the Magic of Linux..." > ------------------------------------------------------------------------ > Michael Peddemors, President/CEO LinuxMagic Inc. > Visit us at http://www.linuxmagic.com @linuxmagic > A Wizard IT Company - For More Info http://www.wizard.ca > "LinuxMagic" a Reg. TradeMark of Wizard Tower TechnoServices Ltd. > ------------------------------------------------------------------------ > 604-682-0300 Beautiful British Columbia, Canada > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop >
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
