> On 23 Jan 2021, at 22:56, Ángel via mailop <mailop@mailop.org> wrote: > > 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".
My intention wasn’t to rewrite 2142 but to obsolete it. That poor little informational RFC has been abused by so many people, it’s time to put it out of all our misery. > Note: Some people will vehemently oppose to not placing filters, > though. Some threads at RIPE anti-abuse-wg show that. There are extremely valid reasons to filter mail coming into the abuse mailbox and I would also argue against any blanket ’this mailbox must not be filtered’ claim. > 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. The issue is that in some types of hosted corporate systems the customer (that is, the corporation) does not have the access or ability to exempt certain addresses from any and all filtering. The subdomain hosting is intended to be hosting on a completely separate system with a different set of filters. Part of the spec would be that it was a different system with a different set of email delivery goals. > 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. That type of redirect is in the SMTP spec already. > 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 This actually digs back into the whole DMARC problem. What is the ‘right’ address? There’s been so much consolidation in the ESP space over the years we have ESPs that are actually mashed up bits of 3 or 4 different original companies. If you look in the headers you’ll see multiple domains splattered across things like the 5321.from, originating IP address, list-unsubscribe header, connecting IP address, etc. It’s not always obvious who the right company is. Then there is the recent push for ESPs to set all relevant domains to point to the customer, not the ESP. If someone is using an ESP, but all the relevant domains in the message point to the company, do we really want the company to be the place for abuse complaints? I don’t actually think so, I think the reports need to go to the ESP. But that ESP is a separate company from the ‘original’ one. > All of that resulting in a too complex architecture. Mail is complex. Sometimes the architectural complexity is a result of reality. Pretending mail is simple and can be simply handled doesn’t benefit anyone. > 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. Security is often a completely different functionality than handling spam complaints. > The relevant draft is at > https://tools.ietf.org/html/draft-foudil-securitytxt-10 laura > Best regards > > Ángel > > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Having an Email Crisis? We can help! 800 823-9674 Laura Atkins Word to the Wise la...@wordtothewise.com (650) 437-0741 Email Delivery Blog: https://wordtothewise.com/blog
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
