This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[anti-abuse-wg] Question about spam to abuse inbox
- Previous message (by thread): [anti-abuse-wg] Question about spam to abuse inbox
- Next message (by thread): [anti-abuse-wg] Question about spam to abuse inbox
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jacob Slater
jacob at rezero.org
Fri Feb 26 21:18:25 CET 2021
> > If you predicate sending reports via web form, then report forwarding > from the ISP to its customer should also be done via web form. > The relationship between an arbitrary internet user and an ISP is different from the relationship between an ISP and a customer who is on a contract. I can (and do) require end users of my infrastructure respond to abuse e-mails sent to them in specific ways. If they don't like the terms I've set, they are welcome to take their business elsewhere. The same relationship does not currently exist with abuse reports. At times I also try and > send fake complaints about my IP, to see if they would forward them to > me. All of those messages fall into a black black hole where time is > frozen expectations fade. Lazy. > It is also possible your ISP believes the report is fake and does not forward it on. Alternatively, perhaps their policy is to not forward reports on. They might investigate, deem it incorrect, and delete it. I personally am opposed to banning or discouraging web forms unless we standardize some system. If there is an expectation for human review on the ISP side, there should be an expectation that the sender is human. If we set an expectation for automated sending of abuse reports, limited machine review prior to acceptance should be expected. Solving this is a difficult problem. From my (admittedly limited) experience, I'm in agreement with Alex de Joode - a solution cannot impact certain operational realities of ISPs. Limited machine review - along with automation of abuse reports on the receiving side - is an operational reality. False, inaccurate, incomplete, or just plain malicious abuse reports are just as real as actual abuse reports. I would note a further operational reality: any standard we come up with outside of the current method of communication (email) is likely to never reach large-scale deployment. Even if we make a standard within e-mail (ex. ARF), some ISPs will want (or need) details beyond what would be outlined in the standard. This will inevitably require more non-standard human interaction. Those who do not care to receive abuse reports will fail to respond to them, regardless of what we decide here. - Slater On Fri, Feb 26, 2021 at 3:57 PM Alessandro Vesely <vesely at tana.it> wrote: > On Thu 25/Feb/2021 14:41:00 +0100 Cynthia Revström wrote: > > > I think you have misunderstood my point. > > > >> Would they send such report using their customer's own web form? > > > > No? I don't know what implied that? > > > If you predicate sending reports via web form, then report forwarding > from the ISP to its customer should also be done via web form. That > is, the ISP should jump all the required hoops until it finds out > where and how to fill the appropriate form. However, doing so defeats > the advantage of having the customer automatically identified. > > > >> Yes, doing so requires some work too, but heck aren't we paying for that > > already? > > > > The person sending the abuse report is rarely a paying customer. > > > >> The right thing to do would be to arrange for the abuse mailbox address > > to point (in)directly to the actual user of the IP address. > > > > I am assuming you are referring to having a separate abuse contact for > each > > customer, so like abuse.cust123 at domain and registering it in the RIPE > > Registry/DB? > > > Yes, exactly. That's the extra work required from the ISP. It is > paid by cust123. Presumably, abuse.cust123 at domain forwards to the > abuse address chosen by the customer on signing the contract. Keeping > a copy allows the ISP to monitor how many complaints its customers > receive. > > > > In some cases with large customers maybe but if you are a hosting > provider > > where each customer might only have one or two IPv4 addresses, that can > get > > to an insane amount of handles and make the database really messy. > > > You can keep a record for each IPv4 address with only a few Terabytes. > > I don't think the reason why ISPs tend to neither assign rfc2317 > reverse delegations nor customer specific abuse-mailbox is because > they or the RIPE cannot afford enough disk space to store that data. > > Every now and then I ask my ISP to assign me an abuse-mailbox (which > my previous ISP did, but then they were acquired by a bigger shark > while the RIPE changed format to abuse-c.) At times I also try and > send fake complaints about my IP, to see if they would forward them to > me. All of those messages fall into a black black hole where time is > frozen expectations fade. Lazy. > > > > Also the customer in question is not the only info that is relevant, like > > is it DoS, spam, or port scanning, etc? > > > > But in general I think there are pros and cons to web forms and email > > templates just as there are pros and cons to arbitrarily structured > emails. > > > For a third alternative, I recently added abuseipdb.com to my > end-of-day abuse reporting script. They provide an http API that > allows to specify the most basic info, IP, time, and kind of abuse. > That method has some of the advantages of forms, as it allows > semantically bound fields, and some advantages of email messages, as > it can be automated. > > > Best > Ale > -- > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/anti-abuse-wg/attachments/20210226/d31b031c/attachment.html>
- Previous message (by thread): [anti-abuse-wg] Question about spam to abuse inbox
- Next message (by thread): [anti-abuse-wg] Question about spam to abuse inbox
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]