e-mail matches when auto-assigning (here Ownership claim granted to Org 'Comsat Limitada' for user 'cablecolor')

[arnoldnipper]

DeskPRO https://peeringdb.deskpro.com/agent/#app.tickets,inbox:agent,t.o:7099,vis:6

Ownership of organization was automatically granted to user:

User: 'cablecolor' (desarrollo@cablecolor.cl) Organization: 'Comsat Limitada' (17407) Network: 'Comsat Limitada' AS262213

My understanding / specification was meant to be

• if domain matches org, then user part doesn't matter

• if domain doesn't match org, then e-mail has to be an exact match

For ASN 262213 I get

e-mail: informatica@CABLECOLOR.CL org/owner: Comsat Limitada

Hence e-mail would have to be an exact match.

[vegu]

We are matching the user's domain against any domains in the asn's contact information as specified in https://github.com/peeringdb/peeringdb/issues/141

Since the ticket said that ideally it'd be a perfect match, but a domain match alone would be acceptable as well, we opted for the second route as one negates the other, either we look for an exact match or a domain match.

If the general consensus is that looking for exact matches only is more reasonable, then that is a quick change to make.

if domain matches org, then user part doesn't matter

This is going to be fairly unreliable. From what i understand getting parent organization information from RiR data, such as domains comes up with a lot of misses, to the point where it would almost be the same as just always looking for an exact email match all the time.

[arnoldnipper]

Does that also mean that if there is @{gmail, yahoo, hotmail ...} then the user part is irrelevant as well?

And i don't get your reason for

This is going to be fairly unreliable. Isn't it what currently is implemented?

[arnoldnipper]

Another example: for https://peeringdb.com/org/17411 (DeskPRO https://peeringdb.deskpro.com/agent/#app.tickets,inbox:archive_resolved,t.o:7114,vis:6) I completely fail to see the authentication

User: 'AliMimate' (pitbullali777@gmail.com) Organization: 'Storm Networks for internet service provider Ltd.' (17411) Network: 'iq-stormnetworksiq' AS206893

I see at RIPE e-mail: amer@stormnetworks.net org-name: Storm Networks for internet service provider Ltd. as-name: iq-stormnetworksiq

[vegu]

And i don't get your reason for

This is going to be fairly unreliable. Isn't it what currently is implemented?

Right now it is checking the domains of all emails listed in the ASN's contact information

so desarrollo@cablecolor.cl matched with informatica@CABLECOLOR.CL

Maybe you can clarify what you mean by

if domain matches org, then user part doesn't matter

I assumed you meant matching the user's email domain against the domain associated with the organization owning the asn. While we can get the contact addresses attached to the ASN, retrieving a domain for the owning organization has not proofed reliable from what i understand.

Does that also mean that if there is @{gmail, yahoo, hotmail ...} then the user part is irrelevant as well?

If a gmail email is listed in the ASN's contact details, then yes - which is what seems to have happened with AS206893 - it has "stormnetworksiq@gmail.com" listed as their "Abuse-C Role" contact.

This is an oversight and should be corrected, once we decide on an action.

Right now the obvious choices are:

1) ban certain domains entirely (gmail, yahoo etc.) 2) go to exact email matching always

Both are equally trivial to do.

[arnoldnipper]

As 1. is hard to achieve (there are way too many freemailers) let's go for 2.

For matching domain and org I was thinking of something like removing spaces from the org-name and then simply match the 2nd level domain part against this string.

Example:

Storm Networks for internet service provider Ltd -> StormNetworksforinternetserviceproviderLtd 2nd level (amer@stormnetworks.net) == stormnetworks

match

[vegu]

I agree that trying to ban all freemailers would be unreasonable, however i have to ponder, are free email addresses really that commonly used for ASN contacts outside of the major providers that it would still be an issue after we banned them with the exception of some extreme borderline cases?

If you had to estimate an urgency for this fix, where would you put it at?

[grizz]

Exact match on freemail would work.

Matching on org from taking out spaces seems dubious, we could try doing a domain who's and matching org name, not sure how well that would work either.

[arnoldnipper]

Exact match always wins, regardless whether this is a freemail address or not. From the top of my head ~80% of LACNIC addresses are freemail addresses.

For domain / org matching any heuristic might seem to be dubious. But the heuristic I proposed seems reasonable and not that bad imho.

For the moment let's stick with exact match

Priority to fix: very high

[arnoldnipper]

Another example which proves that my heuristci isn't that bad

User: 'mpickett' (mclean_pickett@intuit.com) Organization: 'Intuit Inc.' (17413) Network: 'INTUIT' AS7384

Email addresses: OrgTechEmail: nadmin@intuit.com OrgAbuseEmail: nadmin@intuit.com RTechEmail: kelvin_yap@intuit.com

I.e. no exact match, but heuristic would have matched

[vegu]

For the moment let's stick with exact match Priority to fix: very high

Made corresponding ticket and implemented this change at https://github.com/peeringdb/peeringdb/issues/181

Ready to be tagged as 2.2.2 and rolled to beta and production whenever