Before: Arbitrator MarioLipinski (A), Respondent: CAcert (R), Claimant: Joost Steijlen (C), Case: a20100527.1

History Log

Discovery

Investigation of A: 

The two emails originating from the same third party (s20100527.120 and s20100618.5) are not related. Different ticket numbers of the other party, mail headers indicating that both are automatic replies and the mail contents supporting this - they are not referring to the real issue but are rather broadly worded to generally handle requests to the third party - are the evidence which lead me there. So I come to the conclusion that there was no complaint from the third party, but auto generated mails.
However, these two mails can be handled within one arbitration since they are handling the same issue. Looking at the mail subject which is a reply to "[CAcert.org] Email Probe" leads to the assumption that someone added a domain name (or an email address) of the third party to his account. It can be assumed, that this failed and the general protection in place using ping mails works.

Since there is no complaint from the third party and no evidence from our side accessible by the regular means (which domain was tried to add (this is not necessarily the primary domain of the third party), which user tried to add these domain) I reject further investigation on this view unless there becomes a complaint from the third party or information identifying related entities available.

Generally I'd like to encourage support to secure information which might become important during an arbitration and which could become unavailable by being changed by a user or timeout. But in this case a dispute necessarily has to be filed and no further action that has not been ordered by an arbitrator has to be taken by CAcert Support. Said this, I would approve the procedure proposed here, but note that it will not necessarily result in usable information as the domain which was tried to add might be not the primary domain which becomes obvious from the mail.

Thinking about this more generally, from arbitration point of view, the process of adding domains (and email addresses) has to be more auditable. Software team is encouraged to provide input on current implementation or development efforts to rethink the procedure described here. Each automatic mail sent out has to contain an unique identifier by subject and sender/return address. So if a mail is returned CAcert itself can identify: what domain/email, what account, when a possible abuse was tried to be commited. Depending on the volume this handling can be done by support or has to be automated. This also requires a log of the ping mail actions to be kept to identify abuse. The domain/email address additions/verifications for me require auditing functionality to identify abuse and so to protect CAcert from abuse in the long term.

Input 1 from cacert-devel mailing list: 

The process on ping tests for adding email addresses and/or domains
is 2 folded.

First is to add 
1. for domain pings
   to table 'domains' the domain name and a hash key
2. for email pings
   to table 'email' the email address and a hash key

Then there is a background process, who deletes records
with timestamp differences >= 172800 (sec) => 48 hours = 2 days
see sourcecode /scripts/removedead.php

        $query = "delete from `domains` where `hash`!='' and
                        (UNIX_TIMESTAMP(NOW()) -
UNIX_TIMESTAMP(`created`)) >= 172800";
        mysql_query($query);

        $query = "delete from `email` where `hash`!='' and
                        (UNIX_TIMESTAMP(NOW()) -
UNIX_TIMESTAMP(`created`)) >= 172800";
        mysql_query($query);

There are also other maintenance tasks in this script ...

The testserver image includes a cron table of jobs:
# m h dom mon dow
 17 *  *   *   *           hourly
 25 6  *   *   *           daily
 47 6  *   *   7           weekly
 52 6  1   *   *           monthly

From the Webdb documentation
https://wiki.cacert.org/SystemAdministration/Systems/Webdb
under
https://wiki.cacert.org/SystemAdministration/Systems/Webdb#Cron_jobs
there is the definition:
/home/cacert/www/scripts/removedead.php, to be run every hour 

So it can be assumed, that such an abusive email or domain creation
will be automaticly removed after about 48-49 hours
and therefor any evidence about this abuse gets lost.

Input 2 from cacert-devel mailing list: 

[Citing original mail]
Support team doesn't really have access to any useful information, AFAIK.

https://wiki.cacert.org/Support/Triage skim for "abuse reports";

What happens is that a URL is put in the ping mail going out to a user. If the user decides this is an abuse, they can click that URL and send a mail. But the mail that arrives at Support@ does not contain enough information to be useful.

Also, there is no interface in the system that I know of to help. So effectively, Support can do nothing. 

[Citing proposed system changes]

OK, we certainly need something like that. Right now, we can't handle abuse except when reported out of band, such as occurred in the 2009 Arbitration. 

[Citing]

Another issue related is that the checking of domains verification is this: in CPS, domain checking requires *TWO* checks, not one. So the system as it is is not in compliance with CPS.

https://wiki.cacert.org/PolicyDecisions#p20090105.1

Ruling

Regarding this particular case, no action should be taken.

If Support gets a request where it is foreseeable for the support engineer that there might be evidence available which might be interesting during an arbitration, disappear in future (e.g. by automatic system deletion, user changes) he may secure the information. All information must be forwarded to arbitration. As long as not authorized by an arbitrator the support engineer is not authorized to take any further action regarding the case. This also authorizes the procedure as proposed by C:

"Establishing [...] CAcert Support [...] to secure a few pieces of evidence of suspected abuse, while they have the possibility to do so. [...] 2. The evidence in this particular issue being the account number which is only available while the ping is active. (Neither timed out nor acknowledged) 3. Establishing in this particular issue as described in [1] 4. Noting as attaching a note (containing the account number, or possibly the URL from [1]) to the OTRS ticket. 5. Kicking it towards arbitration for an arbitrator to decide whether there will be a followup, and what that followup will entail.

[1] Search for "%[domain]" domains in the support interface and you get a list of domains (and hyperlinks to accounts) which end in "[domain]". The support team member noting which account number is associated with that domain is trivial, and at this point does not yet reveal any further information. (Though the user account is literally one-click away.) The team member simply hovers over the link and makes note of the "&userid=???" part of the URL."

This empowers support quite a lot, but first of all support engineers are ABCd, well picked and well trained, so we can (and do) give them some trust and they have the system privileges anyhow. Secondly, they then have no power anymore to act, there is arbitration control.

CAcert Inc. and its vicarious agents should update their systems to be able to track abuse considering the comments from the discovery which also have been extended and forwarded to cacert-devel.

Arbitrations/a20100527.1 (last edited 2011-06-27 20:11:04 by MarcusMängel)