[anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox")
- Previous message (by thread): [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox")
- Next message (by thread): [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox")
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
No No
no0484985 at gmail.com
Sun May 10 04:43:30 CEST 2020
*" A statement by the registrant that they are not willing to employ an abuse team would be the best evidence."* ... Followed by swift de-registration of all IP resources. --- On Sat, May 9, 2020 at 8:28 PM Alessandro Vesely <vesely at tana.it> wrote: > On Fri 08/May/2020 21:30:14 +0200 Ángel González Berdasco wrote: > > On 08-05-2020 20:17 +0200, Alessandro Vesely wrote: > >> On Fri 08/May/2020 13:28:10 +0200 JORDI PALET MARTINEZ wrote: > >>> Hi Alessandro, > >>> > >>> As I've indicated already several times (and not just in this > >>> discussion), all the RIRs have forms or other methods to escalate > >>> any issues. > >>> > >>> The proposal is only changing "let's have stats". > >> > >> > >> I read: > >> > >> The RIPE NCC will validate the “abuse-mailbox:” attribute at > >> least annually. Where the attribute is deemed incorrect, it > >> will follow up in compliance with relevant RIPE Policies and > >> RIPE NCC procedures. > >> > >> https://www.ripe.net/participate/policies/proposals/2019-04 > >> > >> The anonymized statistics is mentioned afterward. It seems to result > >> from community escalation and reporting, rather than from the > >> abuse-mailbox validation itself. By my proposal, instead, the output of > >> the validation process is borne out when the abuse address is removed > from > >> the database —and the corresponding IP ranges duly transmitted. > > > > Currently there are already abuse contacts marked as having failed > > validation. > > Maybe it should be tagged in a different way. > > I do not think removing them would be the solution, as that would be > > ambiguous with not having been set at all. Plus, it is also possible > > that it is actually working, and the failure was just a transient > > error. > > > Before removing or marking as invalid an abuse-mailbox, RIPE NCC has to > make > absolutely sure that that is a permanent condition. A statement by the > registrant that they are not willing to employ an abuse team would be the > best > evidence. > > Then someone, possibly external, has to read the database and produce a > list of > the relevant IP addresses, so that MTAs having a suitable policy can > immediately deploy it. > > As for removing vs. marking as invalid, the only consideration is that > tools > for retrieving abuse-addresses via rdap can hardly cope with the latter. > However, they can probably check an exclusion list. So, it would work > both ways. > > > > An individual could contribute to the contact being marked as failed > > (as it's already the case) by notifying RIPE. > > > Is it? How? There is a contact form https://www.ripe.net/contact-form > where > the topic can be selected to be "RIPE Database". However, I happened to > report > a bounce from an abuse address and see a reply from RIPE NCC Support asking > "Could you please let us know which action is requested from our side?" > > The first steps of the validation process could be easily automated. The > failure reporting web form could even show the first and last known dates > when > the reported address was tested. > > > > The rir owner could also trigger a new check to show that it is working > > again. > > Right. That should result in immediate rehabilitation. > > > > And whatever you do with such information, is still up for local > > policy. If am abuse contact is known to have been working last Monday, > > but fails since yesterday, there's a good chance that it has been fixed > > or it will be shortly. If it has never been verified to work and it has > > been failing for seven years, well, there's probably no point in > > notifying them through that address. > > > Transient failures can happen, especially with heavily loaded mailboxes. > However, the state of an abuse-mailbox should be a clear yes/no, not > flipping > too often. > > > > However, all of that would still be a local policy decision, which I > > suspect would be better received. You would set your own arbitrary > > thresholds there, rather than the discussion on after which X time > > should RIPE pull that entry from the db. Plus, not all purposes would > > treat them similarly. > > In case you are reporting an abuse from two hours ago, you may only > > care that it is working *right now*. However, if you were checking > > whether their abuse contact status, as one of multiple points > > evaluating a peering request, trying to guess how problematic your > > prospective neighbour may be, you might prefer seeing that their abuse > > mail has been reachable for the last 6 months. > > > I'd leave to RIPE NCC to determine how to reliably set an abuse contact > status. > If I, as an MTA admin, had to extract data from the RIPE database, trying > to > understand the reliability of abuse-c data, such as the first and last > known > dates it worked, I'd probably give up. OTOH, if I only had to rsync an IP > list > having a very low false positive rate, I'd probably go for it. > > If RIPE NCC remove or mark as invalid just the abuse-c's of acknowledged > non-responding or non-existing abuse teams, then the FP rate ought to be > very low. > > There will always be the case of the MTA which badly contracted with an > unconcerned ISP. Their FP rate will account for the 0.x%, and they will > keep > complaining until they change provider. That's already the way email > works for > those large mailbox providers who can afford a reliable IP reputation > system. > > > Best > Ale > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.ripe.net/ripe/mail/archives/anti-abuse-wg/attachments/20200510/c4d0778f/attachment.html>
- Previous message (by thread): [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox")
- Next message (by thread): [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox")
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]