• Arbitrations
• a20140119.1

• Case Number: a20140119.1
• Status: close
• Claimants: Marcus M (as OAO)
• Respondents: Michael G

• initial Case Manager: EvaStöwe

• Case Manager: MartinGummi

• Arbitrator: EvaStöwe

• Date of arbitration start: 2014-02-23
• Date of ruling: 2014-04-03
• Case closed: 2014-09-09
• Complaint: CCA 2.5.2 Violation (Michael G)
• Relief: TBD

Before: Arbitrator EvaStöwe (A), Respondent: Michael G (R), Claimant: Marcus M (as OAO) (C), Case: a20140119.1

History Log

• 2014-01-19 (issue.c.o) case [s20140119.45]
• 2014-02-09 (iCM): added to wiki, request for CM / A
• 2014-02-09 (iCM): send notification mail to (C), (R)
• 2014-02-11 (iCM): got NDR for primary address of R
• 2014-02-23 (CM): I'll take care of this case as CM and select Eva Stöwe as A
• 2014-02-23 (A): init mail to C, R
• 2014-02-23 (mailing-system): NDR for primary address of R
• 2014-02-23 (A): asks internal auditor if A / CM may / should try to contact R via other known addresses
• 2014-03-18 (A): reminds interenal auditor about last mail
• 2014-03-18 (internal auditor): to contact R via other known addresses would be a CCA3.5 violation
• 2014-03-19 (A): comments answer from internal auditor
• 2014-03-20 (A): orders support to block account of R
• 2014-03-20 (A): informs R about block of account
• 2014-03-20 (mailing-system): NDR for primary address of R
• 2014-03-24 (A): asks support if account of R is blocked, because there was no response
• 2014-03-24 (Support): account of R is blocked now, cannot find previous mail [comment: CM got the mail]
• 2014-03-24 (Support): other support member cannot find mail, as well
• 2014-03-29 (R): contacts support with secondary email address because he cannot log into his account
• 2014-03-29 (Support): answers R with link to arbitration case
• 2014-03-29 (Support): reports back to A about reaction of R
• 2014-03-29 (A): contacts R via primary mail address and the secondary mail address R contacted support with (init information included, again)
• 2014-03-29 (mailing-system): NDR for primary address of R
• 2014-03-29 (R): responses to As mail with primary address, he is astonished that his primary address should not work
• 2014-03-29 (R): askes for the NDR error description to be able to detect the source for the issue
• 2014-03-29 (R): reports that he has found the problem. It looks like the configuration of the mail server of cacert.org does not work correctly with forwarding
• 2014-03-29 (Support): answers R with a description of the problem
• 2014-03-29 (R): (primary) reports that he has tested a little bit and found the problem with the mail server of cacert.org, sends a problem description, also declares to have solved the issue
• 2014-03-30 (A): after another discussion in the background contacts the internal auditor again about the CCA 3.5 violation issue when members are contacted with secondary email addresses by arbitration or support
• 2014-03-30 (A): contacts email-admins about the found issue
• 2014-03-30 (A): reports to R (primary only) that A has contacted email-admins and asks for a replay to this mail to show that the primary address is working completely, again - asks if OAO was contacted
• 2014-03-30 (R): (primary) answers that OAO was in CC of last mails, but not specially contacted
• 2014-03-30 (A): orders Support to remove block on Rs account
• 2014-03-30 (A): gives a better problem description to email-admins
• 2014-03-30 (Support): reports unblock of Rs account
• 2014-03-30 (infrastructure admin): confirms the problem of the email-server, provides an mail-account with said forwarding, to check the issue oneself
• 2014-03-30 (A): writes to test-address
• 2014-03-30 (mailing-system): NDR
• 2014-03-30 (A): reports NDR to email-admins, infrastrucutre-admin, CM
• 2014-03-31 (PolO): posts a CCA 3.5-change proposal on policy group list
• 2014-04-01 (OAO): reports that he has contact to R (external chat)
• 2014-04-03 (A): ruling send to C, R, email-admins, CM
• 2014-04-05 (A, email-admin): VoiP-Session to identify and discuss the problems, partly joined by C as Support team member, C gets allowance from A to search support-mail-inbox for missing mail
• 2014-04-05 (email-admin): considers the email-system-behavoir as a feater not a bug, asks infrastructure-admin for his view (encrypted to A, infrastructure-admin)
• 2014-04-05 (C as Support): identified missing mail from A to support team in support-mail-inbox
• 2014-04-14 (infrastructure-admin): answers email-admin that other email providers handle the issue with SPF, does not mind how it is done in the short term but advised to use SPF on the long term (answer to encrypted mail)
• 2014-05-02 (A): asks mail-admin and infrastructure-admin for some result or else for an information of the members
• 2014-05-26 (A): asks mail-admin and infrastructure admin to show some results and to inform the users
• 2014-05-27 (email-admin): technical comment
• 2014-05-27 (A): emphasize to inform the users
• 2014-06-09 (A): reminds mail-admin and infrastructure admin to inform users
• 2014-06-09 (infrastructure admin): preparing to do so
• 2014-07-06 (A): asks for progress
• 2014-07-06 (infrastructe admin): it is on the TODO-list, time limited
• 2014-07-18 (A): setting deadline to 2014-08-03 to inform the members
• 2014-07-29 (email-admin): talk about next steps to inform the users
• 2014-07-29 (infrastructure-admin): identify the mail server problem 2nd time
• 2014-07-30 (A): clarify the problem with the email setup
• 2014-08-09 (CM): ask about next steps
• 2014-09-09 (email-admin): send information to current email-users; send execution notificattion to A
• 2014-09-09 (A): informs participants of this case about execution and thanks them for their help
• 2014-09-09 (CM): close case

Private Part

• Link to Arbitration case a20140119.1 (Private Part), Access for (CM) + (A) only

EOT Private Part

original Dispute

• Dear arbitrators,
  
  I tried to reach (R) under his primary email address taken
  from the last permission review:
  [email-address]
  
  I got the attached error report as the mail could not be delivered to
  (R) due to his mail settings.
  
  There for I file as dispute as Organisation Assurance Officer against
  (R) for not keeping his primary email address in good
  working order.

Discovery

Summary of events

(R) who is a member of the OA-team could not be contacted by (C) in his role as organization assurance officer (OAO) by his primary email-address. The OAO filed a CCA 2.5 violation dispute.

(A) could not contact (R) via the primary email-address and got an NDR multiple times.

As there was no other allowed way found to try to get the attention of (R), a block on the account of R was ordered.

When (R) tried to log into the account again, he could not log in and contacted support with a secondary email-address.

When contacted by (A) again (via the secondary email-address R got in contact with support), (R) declared that he thought is primary email-address to be working fine and that he got mails with it, all the time. (R) searched for the issue and found it with the forwarding configuration of the cacert.org email-system which he tried to use.

(A) ordered the account-block to be released, after checking that the primary email-address was working fine.

The email-admis were contacted about the problem and the issue was confirmed by the infrastructure admin. It was also tested by (A).

(R) got in contact with (C) as OAO.

conclusion

The issue was more one of the cacert email system which (R) thought to be correct. He had no idea that something was wrong as he received mails on his primary email-address from senders not writing with @cacert.org addresses.

(R) cannot be thought to be responsible for the failure of his primary email address. Further, he helped a lot to find the problem and was good spirited to solve all issue with his address.

Because others may be affected by the issue, as well, the problem with the email-system should be solved, soon. If this is not possible, it would be a good idea if users of the system would be informed about it in a sensible way.

additional remarks

The idea to block the account as a first step to get the attention of someone not answering the primary email-address showed to be working in this case. While this does not have to be the case in all cases it may be a good idea to try it again in other cases, as it is a comparably harmless solution.

It would be even better if one could try other known email addresses. Sadly, this has currently to be considered to be a CCA 3.5 violation, as it states:

[...]

Notifications to you are sent by CAcert to the primary email address registered with your account. You are responsible for keeping your email account in good working order and able to receive emails from CAcert. 

[...]

If this is changed in the future, there could be better ways to proceed in CCA-violation cases where the primary email-address is not working. This cannot be predicted from this case. But arbitrators in similar cases may want to consider this.

Ruling

I hereby come to the following ruling for a20140119.1:

While the primary email address from the respondent was not working, he should not be considered to be responsible for this.

As the email address only did not work for cacert.org-addresses because of a bad configuration of the CAcert email system, email admins should be ordered to either fix the problem soon, or to inform the users about the issue.

A/CM should provide email admins with a description of the issue and a description of another email-issue that occurred in this case.

If the users are informed, the case may be closed without a final solution to the email issues, as affected members can fix the setup of their email addresses, then. The email admins should be able to solve the issues without supervision by arbitration.

Cologne, 2014-04-03

Execution

• 2014-04-03 (A): send ruling to C, R, email-admins, CM
• 2014-04-05 (A, email-admin): VoiP-Session to identify and discuss the problems, partly joined by C as Support team member, C gets allowance from A to search support-mail-inbox for missing mail
• 2014-04-05 (email-admin): considers the email-system-behavoir as a feater not a bug, asks infrastructure-admin for his view (encrypted to A, infrastructure-admin)
• 2014-04-05 (C as Support): identified missing mail from A to support team in support-mail-inbox
• 2014-04-14 (infrastructure-admin): answers email-admin that other email providers handle the issue with SPF, does not mind how it is done in the short term but advised to use SPF on the long term (answer to encrypted mail)
• 2014-05-02 (A): asks mail-admin and infrastructure-admin for some result or else for an information of the members
• 2014-05-26 (A): asks mail-admin and infrastructure admin to show some results and to inform the users
• 2014-06-09 (A): reminds mail-admin and infrastructure admin to inform users
• 2014-06-09 (infrastructure admin): preparing to do so
• 2014-07-06 (A): asks for progress
• 2014-07-06 (infrastructe admin): it is on the TODO-list, time limited
• 2014-07-18 (A): setting deadline to 2014-08-03 to inform the members
• 2014-07-29 (email-admin): talk about next steps to inform the users
• 2014-07-29 (infrastructure-admin): identify the mail server problem 2nd time
• 2014-07-30 (A): clarify the problem with the email setup
• 2014-08-09 (CM): ask about next steps
• 2014-09-09 (email-admin): send information to current email-users; send execution notificattion to A
• 2014-09-09 (A): informs participants of this case about execution and thanks them for their help

Similiar Cases

• CategoryArbitration

• CategoryArbCaseCCAViolation