[anti-abuse-wg] 2019-04 Discussion Phase (Validation of "abuse-mailbox")

*" 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: </ripe/mail/archives/anti-abuse-wg/attachments/20200510/c4d0778f/attachment.html>