On 2021-01-22 at 18:24 +0000, Laura Atkins via mailop wrote: > I think it’s a great idea. We’ve even discussed putting a RFC > together listing this as best practice but have not found the time to > do it. Updating / superseding 2142 or whatever RFC that is would be > a Good Thing. > > laura
I think it should be a separate RFC about how to an abuse mailbox, or similar, not a new version of 2142. RFC 2142 is about defining standard role mailbox names. I would love to see a RFC saying the obviousness that you must not block receiving at your abuse desk the mails *you* sent. That would also be useful as argument to vendors which don't provide any way to have an abuse mailbox skip normal rules and receive "really bad emails". Note: Some people will vehemently oppose to not placing filters, though. Some threads at RIPE anti-abuse-wg show that. That said, I'm not convinced about simply replacing "ab...@example.com" to "ab...@abuse.example.com". That would by itself be complex for other organizations, and nobody tells you that such system will have a different configuration or be better managed. And Grant proposal of an auto-reponder seems a terrible one: > 2) Configuring <bla>@example.net with an auto-responder (very early > in the stack) stating to use #1. If any, you would want to define some kind of rejection message that provided the equivalent of a "HTTP 301" so that the MTA itself could redirect it to the right mailbox. Beware that the target mailbox MUST be on a subdomain (or the same domain) as the original one. Otherwise, that allows mail bombing. This means an organization couldn't redirect ab...@company.com to s...@externalvendor.com They would have to redirect to something like ab...@abuse.company.com with externalvendor.com providing the MX for that subdomain. Or, alternatively, define a mechanism by which externalvendor.com could opt-in to receive emails redirected from company.com All of that resulting in a too complex architecture. I think the right way to address this would be to include an Abuse- Contact field on security.txt, which would override the default of ab...@example.com Or one might define a separate abuse.txt, specially if there is a need for other additional abuse fields, but otherwise I think abuse handling is similar enough that can be included under the securitytxt umbrella. The relevant draft is at https://tools.ietf.org/html/draft-foudil-securitytxt-10 Best regards Ángel _______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
