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] 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-03 Policy Proposal Withdrawn (Resource Hijacking is a RIPE Policy Violation)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Carlos Friaças
cfriacas at fccn.pt
Tue Oct 1 17:59:52 CEST 2019
Hi, After reviewing version 2, i'm not very sure about: 1) "Require intervention by the recipient" Some reports will not require intervention, they work only as a warning for a possible device infection. Some incident response teams may also decide not to process certain categories of reports/incidents. One of our examples is the huge set of reports we receive related to the webcrawling activity that feeds into the portuguese web archive (arquivo.pt). Some networks/servers are more sensible to webcrawling and have automated report generation mechanisms. That's also something that must be considered. We can't expect a manual intervention by the recipient if the sender has an automated process... 2) "Must guarantee that abuse reports and related logs, examples, or email headers are received". I think this one can be tweaked: The recipient domain's policy might be to discard messages bigger than <N> megabytes (we have that in my org's domain, but not on the CSIRT's domain). Hence, i would say to add ", upto a reasonable limit in size" to the sentence. 3) About "5.0 Escalation to the RIPE NCC" It's also important to note that a domain is entirely free to block incoming messages from another given domain. So, if someone receives 500 reports/day from the same mailbox, or from several mailboxes of the same domain, it's perfectly normal to blacklist the sending domain locally... 4) About the 1 year to 6 months change, i'm OK with it as long as it's feasible for the NCC's system -- but i guess the I.A. might clarify that. Final comments: I think the proposal is useful, and it's important to note that if something de-rails (abuse-wise), then the most probable line of action seems to be an ARC, which is already part of the NCC's duties anyway. Regards, Carlos On Tue, 1 Oct 2019, Marco Schmidt wrote: > > Dear colleagues, > > A new version of RIPE Policy proposal, 2019-04, "Validation of "abuse-mailbox"", is now available for discussion. > > This proposal aims to have the RIPE NCC validate "abuse-c:" information more often, and introduces a new validation process that > requires input from resource holders. > > The proposal has been updated following the last round of discussion and is now at version v2.0. Some of the differences from > version v1.0 include: > - Removes ambiguous examples from the policy text > - Defines mandatory elements of the abuse handling procedures > - Removes the prohibtion of automated processing of the abuse reports > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2019-04 > > As per the RIPE Policy Development Process (PDP), the purpose of this four-week Discussion Phase is to discuss the proposal and > provide feedback to the proposer. > > At the end of the Discussion Phase, the proposer, with the agreement of the Anti-Abuse Working Group Chairs, decides how to proceed > with the proposal. > > We encourage you to review this proposal and send your comments to <anti-abuse-wg at ripe.net> before 30 October 2019. > > Kind regards, > > Marco Schmidt > Policy Officer > RIPE NCC > > >
- Previous message (by thread): [anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox")
- Next message (by thread): [anti-abuse-wg] 2019-03 Policy Proposal Withdrawn (Resource Hijacking is a RIPE Policy Violation)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]