- Status Closed
-
Assigned To
cbay - Private
Opened by Bajinder - 24.09.2026
Last edited by cbay - 30.09.2026
FS#496 - Cross Customer Contacts and Calendar via Account Rename
Vulnerability Information
Name of Vulnerability
A Radicale collection is addressed by the mailbox address, not by the account that owns it, and renaming an account never destroys the collection while the freed account name becomes registrable again within about a minute. The next holder of an account name therefore inherits the previous customer's address book and calendar in full, through the ordinary webmail interface and with their own password.
Vulnerability Category
Access Control Issues, Exposure of Sensitive Member Information, per the qualifying list on the bug bounty page.
Cross-customer disclosure of personal data belonging to a different customer.
CVSS 3.1: 8.1 High (`AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N`)
Confidentiality: High. The full contents of another customer's address book and calendar are exposed, including names, email addresses, telephone numbers, event titles, locations, and notes.
Integrity: High. The inheriting customer does not merely read the collection, they own it, and anything they write is visible to the other party while both hold the address.
Availability: None.
Scope: Unchanged. The vulnerable component and the impacted component are both the CardDAV and CalDAV service.
I have deliberately not claimed Scope Changed and have deliberately not scored this Critical. The stored mail itself does not cross, which I state as a measured fact below.
Description
Two facts combine. Neither is a defect on its own, and both are yours to change.
First, a Radicale collection is keyed by the mail address and by nothing else. The account that owns the address is not part of the path and is not consulted.
```text
PROPFIND https://caldav-<account>.alwaysdata.net/<address>/
207, the address IS the collection
PROPFIND https://caldav-<account>.alwaysdata.net/<account>/
403, the account name is NOT
```
Second, the free mailbox `<account>@alwaysdata.net` is derived from the account name and its local part is readonly in your own panel. Whoever holds an account name therefore necessarily holds the credential that authenticates that collection.
The defect is what happens between those two facts.
When an account is renamed, the old address stops being served but its collection is never destroyed. The name is then released, and I measured it becoming registrable again after 46 seconds by any customer on a free plan.
The new holder creates the account, sets their own mailbox password, and Radicale hands them the collection that the previous customer left behind.
THIS IS NOT A DESIGN POSITION
Your own code is the evidence.
Ace collections, which I verified separately, are cleaned up when the name is freed after 6 minutes and 33 seconds. The cleanup path exists and works.
Rename simply does not invoke it. This is why I am reporting this as a bug rather than as a consequence of releasing a name.
WHAT THIS REPORT DOES NOT CLAIM
I am not reporting that account names are public or enumerable. Your scope notes say account names are accessible in many ways, and I accept that completely.
The disclosed material here is not the name. It is the previous owner's PIM data, which is not derivable from the name by any means.
WHAT THIS REACHES THAT A CUSTOMER CANNOT ALREADY REACH
A customer cannot access another customer's PIM data by any other route.
I ran the control on the node:
* The UID is the tenant's own.
* `/home` is `drwxr-x–x`, so it cannot be listed.
* The store is readable from the tenant filesystem.
* There is no API path to it.
* Customer A's API token returns 404 on Customer B's objects.
The only way to read this data is to hold the address, and holding the address is exactly what a rename gives away.
Vulnerable Instances
```text
PROPFIND / GET / PUT
https://caldav-<account>.alwaysdata.net/<address>/addressbook/
PROPFIND / GET / PUT
https://caldav-<account>.alwaysdata.net/<address>/calendar/
```
The same collections are rendered in the Contacts and Calendar tabs of:
`https://webmail.alwaysdata.com`
The issue is reachable by any authenticated customer on a free plan. No paid plan or special role is required.
BEFORE YOU ASK
The same person registered both customers, and that is not relevant to the authorization boundary.
Your records will show that one researcher created both. What matters is that your control plane models them as two customers with no permission grant between them and enforces that separation everywhere else.
Customer A's API token against Customer B's account ID returns 404, byte identical to a nonexistent ID.
The account pickers are disjoint, and Customer B does not appear in Customer A's customer selector at all.
The boundary crossed here is the one your platform draws. What crosses that boundary is contacts and calendar data.
Steps to Reproduce
Total cost: EUR 0.
Two unrelated customers were used, each of whose `/permissions/` page lists only itself.
All times are UTC, 2026-09-24.
Both accounts were ours and both have since been deleted.
1. Create the test data
As Customer B, write two objects into the collection of the free address held by Customer B's account:
```text
PUT …/<addressB>/addressbook/<uid>.vcf
A vCard with a name and mobile number
PUT …/<addressB>/calendar/<uid>.ics
An event with a summary, location and description
```
2. Rename the account
As Customer B, rename the account, which vacates the name.
Recorded at `08:27:22Z`.
3. Re-register the released account name
As Customer A, a different customer with no relationship to B, create a brand new free account using the name B just vacated.
Accepted at `08:28:32Z`.
The name became registrable again after 46 seconds.
4. Set the new mailbox password
As Customer A, set the mailbox password on the new account to a value chosen by A.
5. Read the collection
As Customer A, read the collection.
At `08:31:51Z`:
```text
GET …/<addressB>/calendar/<uid>.ics
200, returns B's event description
GET …/<addressB>/addressbook/<uid>.vcf
200, returns B's name, email address and mobile number
GET …/<addressB>/calendar/<never>.ics
404, NEGATIVE CONTROL
```
The same vCard is then visible in the Contacts tab of `webmail.alwaysdata.com` for Customer A.
Proof of Concept
Controls
All controls were run in the same window because a 200 response on its own does not prove ownership transfer.
Only the current holder's password authenticates.
Against the previous owner's password, a wrong password, an empty password, and a different address's credential, the requests all returned 401 or 403, with IMAP agreeing in the same minute.
Fresh address control
A fresh address opens empty.
I created an account on a name whose collection had never previously existed. The collection returned no objects, so a 200 response on a reclaimed name is not simply what every new account sees.
The mechanism
The mechanism was independently re-verified by a second tester on a live unrelated account.
```text
PROPFIND https://caldav-vk7research.alwaysdata.net/vk7research
200
PROPFIND https://caldav-vk7research.alwaysdata.net/vk7research/
403
PROPFIND …/zznever4471@alwaysdata.net/
wrong password on the correct address 401
a different customer's address with this password
```
IT IS BIDIRECTIONAL
In a second run over the rename path, the collection came back to the original holder.
This shows that this is not a stale read of a cached copy. Both parties are operating on one live collection.
THE MAILDIR DOES NOT CROSS
I am stating this as a limit of the demonstrated impact.
The new holder's INBOX, Drafts and Sent were all 0 messages.
Stored mail is not affected.
Contacts and calendar are.
Impact
Any customer who renames an account, for any reason, silently donates their entire address book and calendar to whoever registers that name next.
Renaming is an ordinary, encouraged, reversible-looking operation, and nothing in the interface indicates that personal data remains behind the released name.
The window is not a race. The collection persists indefinitely, so every account name ever vacated by a rename still has its collection waiting.
The disclosed data is third-party personal data in the GDPR sense, belonging to people who are not the customer and never interacted with the inheriting customer.
This includes names, email addresses, telephone numbers in the previous owner's contacts, and attendees and notes from their meetings.
The inheriting customer also gains write access, so they can insert or alter entries that the previous owner's client will sync.
I did not go looking for a real customer's vacated name, and I did not read any data belonging to anyone outside my own two test accounts.
The generalisation is argued from the mechanism, not exercised against a real customer's data.
Recommendation
1. Make RENAME invoke the same collection cleanup that DELETE already performs. This is the direct fix, and the code already exists. It is simply not called on the rename path.
2. Alternatively, and more robustly, key the collection by an immutable internal account identifier rather than by the mail address, and map the address to that identifier at request time.
3. Hold a released account name in quarantine for long enough that the previous collection is cleaned up before the name can be reissued, rather than reissuing it in under a minute.
4. Audit for collections whose address has no current owner and purge orphaned collections. I encountered orphaned collections during this test and list them in the private annex so they can be removed.
5. Unrelated but adjacent, I also found rename residue in DNS: a dangling `<name>.alwaysdata.net` A record pointing at `185.31.41.11` with no owner. A never-existent control name returns NXDOMAIN, so this appears to be rename residue. This also answers the earlier report about `webmaster.alwaysdata.net`, which is residue of the same kind.
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
Hello,
Thanks for the report. Can you confirm that the issue is fixed?
Kind regards,
Cyril
Hello Cyril,
No. I reproduced it end to end this afternoon, including the cross customer half, and none of the five recommendations appears to have been applied.
I retested on 2026-09-24 between 13:09Z and 13:19Z from 117.253.56.133. Note the egress IP changed since the report, which said 117.255.15.131.
THE MECHANISM IS UNCHANGED
A collection is still addressed by the mail address and the owning account is still not consulted.
THE FULL CHAIN, RERUN TODAY ON FRESH OBJECTS
Everything below is on two accounts we own. All times UTC, 2026-09-24.
13:12:37Z customer A, user 489835, creates the free account a17mail1 13:14:19Z A writes a vCard and a VEVENT into a17mail1@alwaysdatad back 200 and 200 13:14:37Z A RENAMES a17mail1 to a17mail9, which vacates the address 13:14:53Z the collection does NOT follow the account. a17mail9@ is empty and the canary returns 404 at the new address 13:15:20Z the VACATED address still serves the collection in fuwith its FN, EMAIL and TEL, and the VEVENT returns 200 with its SUMMARY, LOCATION and DESCRIPTION 13:17:02Z customer B, user 489840, a DIFFERENT customer whose /ly itself, takes the freed name 13:17:15Z B does a PROPFIND with B's OWN mailbox password and gted in the collection 13:17:42Z B reads both of A's objects in full, 200 and 200, and then WRITES its own object into the same collection, PUT 201So the rename still does not purge, the collection still does not fonext holder of the name still inherits the previous customer's
contacts and calendar with their own password and with write access.
CONTROLS, all in the same window, because a 200 on its own proves nothing.
That fourth line matters together with the first. B is not reading this because B is related to A. B is reading it because B holds the address, and A, who created
the data, is locked out of it in the same minute.
RECOMMENDATION BY RECOMMENDATION
On 4 I want to be exact rather than helpful to my own case. When I reclaimed a17mail1 its collections existed but held no objects, and I am NOT presenting that as
surviving data, because that particular address only ever had Roundc CardDAV objects. I cannot tell from the outside whether you purged
it or whether it was always empty. That is why I proved the defect with objects I planted today instead.
On 5 the residue is measurable. These all still resolve to 185.31.41.11 with no account behind them, and a name that never existed returns NXDOMAIN as the control:
a17mail1, a17mail2, a17mail3, a17mail8, and webmaster, which is the lier report.
What about now?
not fixed
Hello Cyril,
No. I reproduced it end to end this afternoon, including the cross customer half, and none of the five recommendations appears to have been applied.
I retested on 2026-09-24 between 13:09Z and 13:19Z from 117.253.56.133. Note the egress IP changed since the report, which said 117.255.15.131.
THE MECHANISM IS UNCHANGED
A collection is still addressed by the mail address and the owning account is still not consulted.
THE FULL CHAIN, RERUN TODAY ON FRESH OBJECTS
Everything below is on two accounts we own. All times UTC, 2026-09-24.
13:12:37Z customer A, user 489835, creates the free account a17mail1 13:14:19Z A writes a vCard and a VEVENT into a17mail1@alwaysdata.net, PUT 201 and 201, read back 200 and 200 13:14:37Z A RENAMES a17mail1 to a17mail9, which vacates the address 13:14:53Z the collection does NOT follow the account. a17mail9@alwaysdata.net addressbook is empty and the canary returns 404 at the new address 13:15:20Z the VACATED address still serves the collection in full. The vCard returns 200 with its FN, EMAIL and TEL, and the VEVENT returns 200 with its SUMMARY, LOCATION and DESCRIPTION 13:17:02Z customer B, user 489840, a DIFFERENT customer whose /permissions/ page lists only itself, takes the freed name 13:17:15Z B does a PROPFIND with B's OWN mailbox password and gets 207 with A's vCard listed in the collection 13:17:42Z B reads both of A's objects in full, 200 and 200, and then WRITES its own object into the same collection, PUT 201So the rename still does not purge, the collection still does not follow the account, and the next holder of the name still inherits the previous customer's
contacts and calendar with their own password and with write access.
CONTROLS, all in the same window, because a 200 on its own proves nothing.
That fourth line matters together with the first. B is not reading this because B is related to A. B is reading it because B holds the address, and A, who created
the data, is locked out of it in the same minute.
RECOMMENDATION BY RECOMMENDATION
On 4 I want to be exact rather than helpful to my own case. When I reclaimed a17mail1 its collections existed but held no objects, and I am NOT presenting that as
surviving data, because that particular address only ever had Roundcube contacts and never had CardDAV objects. I cannot tell from the outside whether you purged
it or whether it was always empty. That is why I proved the defect with objects I planted today instead.
On 5 the residue is measurable. These all still resolve to 185.31.41.11 with no account behind them, and a name that never existed returns NXDOMAIN as the control:
a17mail1, a17mail2, a17mail3, a17mail8, and webmaster, which is the one left over from the earlier report.
I think the problem is that those mailboxes had already been renamed before the fix. Can you try with new accounts?
Note that I'm only trying to fix the vulnerability, not necessarily implement all your recommendations.
Hello Cyril,
That was a fair challenge and you were right to make it, so I redid the whole thing on names that have never existed. It still reproduces.
Understood on the second point as well. I am only answering the question of whether the vulnerability is fixed below, and I have dropped the recommendation by
recommendation scorecard from my previous message. Recommendations 3, 4 and 5 are yours to take or leave and I am not pressing them.
WHY YOUR HYPOTHESIS WAS REASONABLE, AND WHY IT DOES NOT HOLD
You were right that my earlier runs reused a17mail1, whose collection predated your fix, so that test could not distinguish your explanation from mine. This one
uses two names that had never been allocated at all, and an account created after your fix was live.
PRE FLIGHT, 14:11:57Z, before anything was created. Both names were proven unallocated, with a positive control:
THE RUN, all times UTC on 2026-09-24
So a name that never existed before your fix, an account created after your fix, and one rename is still enough to hand the next holder the previous customer's
contacts and calendar with write access.
CONTROLS. I repeated every probe three times rather than once, for a
ONE THING I WANT TO FLAG MYSELF, BECAUSE IT COULD HAVE MISLED BOTH OF US
Immediately after B took the name, and before B had set its own mailbox password, I got an unstable reading: B's password returned 401 while A's old password
returned 207, and the vCard and the VEVENT disagreed with each other I did not report that. It resolved completely once B's mailbox
password was actually set, and the figures above are the stable ones, each measured three times. I mention it so that if you reproduce this yourself and see a
mixed result in the first few seconds after a rename, you know it ispropagation and not the finding.
I also did not get a clean reading on whether the collection followsme in this particular run, for the same password propagation reason.
My earlier run did establish that it does not follow, but I am not resting anything on it here. The finding is what happens at the address that was vacated.
WHAT I DID NOT TOUCH
No third party data was read, inferred or recorded at any point. Both accounts are ours.
DISCLOSURE AND CLEANUP FOR THIS RUN
Account zzq496a0f1009, id 501869, was created and has been DELETED. Customer A owns only vk7research again. Customer B was renamed to zzq496a0f1009 for about two
minutes and has been renamed back to zzr1sticky0921.
All three objects I created were deleted and I verified the collecti
Passwords set during this run, please treat as disclosed: account seb9wLm2X on the deleted account, mailbox password D496mb#Zq4rT9wVp2 on
the deleted account, and mailbox 635949 on zzr1sticky0921@alwaysdata.net is now E496mb#Bq9vRt4Xz.
The name zzq496a0f1009 is vacant again and its now empty collection is orphaned, which is the defect itself rather than something I can clear from my side.
Hi, any update?
Hi Cyril,
Any developments?
Can you try again, with newly created accounts?
Hello Cyril,
No. I rebuilt the whole thing this afternoon on accounts and names that were created today, and it still reproduces. I ran it twice, in both
directions, because I did not want the answer to depend on how the next holder happens to acquire the name.
Retested 2026-09-29 between 13:09Z and 13:30Z. Our egress IP has moved again and is now 49.36.168.43. The report says 117.255.15.131 and my previous
message said 117.253.56.133, so please use today's value when you correlate your logs.
PRE FLIGHT, BEFORE ANYTHING WAS CREATED
Every name used below was checked before it was created, so none of them can be carrying a collection left over from an earlier run of mine or from
anything that predates a change on your side.
THE MECHANISM IS UNCHANGED, 13:15Z
I held the host constant at caldav-vk7research.alwaysdata.net for every probe in this message, so the only things that vary are the address in the
path and the credential. The host is not what decides the answer.
RUN 1, ALL TIMES UTC 2026-09-29. NEW ACCOUNT, NEW NAME, NAME RELEASED BY A RENAME
13:16:05Z customer A, user 489835, creates the free account zzq496g0929. New account, new name, new mailbox 13:17:08Z I hash the two canary objects and commit the digests to my own log before either is planted 13:17:1xZ the brand new collection is EMPTY, 0 objects, then A writes a vCard and a VEVENT into zzq496g0929@alwaysdata.net. PUT 201 and 201, read back 200 and 200 13:17:40Z A RENAMES zzq496g0929 to zzq496h0929, which vacates the address 13:18:19Z the collection does NOT follow the account. At the new address the canary is 404 and the address book is empty 13:18:43Z customer B cannot CREATE a second free account, "Vous ne pouvez pas avoir plus de 1 produit(s) de ce type" 13:18:45Z customer B, user 489840, a different customer, takes the freed name by renaming its own account, 65 s after A released it 13:19:01Z B sets B's OWN mailbox password on the address 13:19:17Z B reads A's vCard and A's VEVENT in full, 200 and 200, and repeats it three times 13:20:5xZ B WRITES its own object into the same collection, PUT 201, and the listing then shows both objects 13:22:02Z B DELETES A's two objects, 200 and 200. The inheriting customer holds read, write and delete, not just readWhat B saw at 13:19:17Z was the whole record: FN, N, EMAIL, TEL and NOTE from the vCard, and UID, SUMMARY, LOCATION and DESCRIPTION from the event.
CONTROLS, same window, each repeated three times, because a 200 on its own proves nothing.
Those first two lines matter together. B is not reading this because B is related to A. B is reading it because B holds the address, and A, who
created the data, is refused at the same address in the same minute.
RUN 2, THE INHERITING PARTY CREATES A BRAND NEW ACCOUNT, AND THE TWO CUSTOMERS SWAP ROLES
Run 1 had the inheriting party arrive by rename, only because the free product quota refused it a second account. That is a detail of my test rig
and not of your platform, so I ran the whole thing again the other way round, with the roles reversed and with the claim made exactly the way step 3
of the original report describes it.
CONTROLS, same window, each repeated three times.
So a brand new account, created today, on a name that had never been allocated before today, reads the previous holder's contacts and calendar.
THE ONE THING I MEASURED TODAY THAT I HAD NOT MEASURED BEFORE
In the same run, on two names created minutes apart by the same two customers, I released one name by RENAME and the other by account DELETE, with a
canary planted in each collection first. The two paths do not behave the same way.
name released by RENAME, zzq496g0929 13:17:40Z released with a vCard and a VEVENT in the collection 13:19:17Z next holder reads both in full, 200 and 200, and can write and delete 13:30:21Z the name still resolves to 185.31.41.11 with no account behind itname released by account DELETE, zzq496h0929 13:21:48Z canary planted, PUT 201, read back 200 13:22:34Z the account is deleted 13:23:08Z the name is registrable again 34 s later, and I take it with a new account 13:24:02Z the collection is EMPTY. PROPFIND 207 with zero objects, the canary returns 404, measured three times and in the one DNS batch I ran while that name was unowned, between the delete and the re claim, it answered NXDOMAIN while zzq496g0929, released by rename, answered 185.31.41.11 in the same batchThe delete path destroys the collection and cleans up the DNS. The rename path does neither. That is the same contrast the report described, but this
time both halves were measured in one sitting, on fresh objects, which is why I am confident the answer to your question is no rather than not yet.
TWO THINGS I WANT TO FLAG MYSELF
In the minute between the rename and the moment the new holder sets a password, the credential state is unstable. At 13:18:1xZ the previous owner's
password still authenticated at both the old and the new address. I am resting nothing on that window, and every figure above was taken after the new
holder's own password was set and was repeated three times. I mention it because if you reproduce this and look too early, you will see a mixed
result that is propagation timing and not the finding.
In run 1 the inheriting party acquired the name by rename rather than by creation. Run 2 exists precisely so that the answer does not depend on that.
ONE POSSIBILITY WORTH RULING OUT FIRST
On
FS#495, and on three reports in the round before that, the fix had been pushed but not yet applied in production at the moment I retested. If thatis the case here as well, say so and I will retest rather than assume. I would rather run it again than argue about it.
DISCLOSURE AND CLEANUP FOR THIS RETEST
No data belonging to any third party was read, inferred or recorded at any point. Everything above is on two accounts we own.
Accounts created and then DELETED by us today: zzq496g0929 renamed to zzq496h0929, id 503019; zzq496h0929, id 503020; zzq496j0929, id 503022.
Customer B was renamed away from zzr1sticky0921 twice, for about four and a half minutes in total, and has been renamed back. Customer A owns only
vk7research again and customer B owns only zzr1sticky0921. I verified both.
Five of the six canary objects were deleted by me and I verified each collection reads back with zero objects. The sixth was destroyed by your own
account delete path, which is the control described above.
I set passwords on our own mailboxes during the run. All but one were on accounts that have since been deleted. The exception is mailbox 635949 on
zzr1sticky0921@alwaysdata.net, which is ours and which I reset three times today. I am not printing any of those values here because this tracker
publishes tasks, and I can send them privately if you want them.
I caused no uncaught 500s on this report.
Residue I left behind and cannot clear from my side, because it is the defect itself: zzq496g0929.alwaysdata.net still resolves to 185.31.41.11 with
no account holding the name, and its now empty collection is orphaned. The names released by DELETE left nothing behind.
It seems you actually connected to CalDAV before the rename was actually done, which could explain the bug.
Can you try again now?
Hello Cyril,
No, it still reproduces, and this time the run was built specifically so that no CalDAV connection happens anywhere near the rename.
I understand why you asked. My previous message flagged, on my own initiative, that in the minute following a rename the credential state is unstable and
that the previous owner's password still authenticated at both addresses for a short while. That observation was about credential propagation, not about
the collection, and I rested nothing on it. But it was the only loose thread in that message, so I have removed it entirely rather than argue about it.
Retested 2026-09-29 between 14:31Z and 15:42Z. Egress IP 49.36.168.43, the same as this afternoon.
HOW THIS RUN WAS BUILT
One address, one collection, and a large measured gap on BOTH sides of the rename, with zero CalDAV traffic to that address in between.
HOW LONG YOUR RENAME ACTUALLY TAKES
I measured this before touching CalDAV, using only your control plane, so that the answer does not depend on my reading of the DAV service.
So by your own interfaces the rename was complete within 12 seconds.nting DNS as a completion signal here, because the name the
account was renamed back to was still resolving while the account was called something else. That is the DNS residue in recommendation 5 of the report and
it cannot honestly double as proof of anything.
THE COMPLETE CALDAV REQUEST HISTORY OF zzq496p0929@alwaysdata.net FOR THIS RUN
This is every single request made to that address by anyone, from before the name existed to the end of the run. There is nothing else.
14:31:51Z PROPFIND 403 pre flight, with a VALID credential for another address. The name had never been allocated 14:35:14Z PROPFIND 207 the brand new address, nd 0 in calendar 14:35:28 to 35:31Z PUT PUT 201 201 previous holder writes a vCard and a VEVENT GET GET 200 200 previous holder reads bk I timed this block as a whole, so I give it as a range rather than invent per request seconds ................................ no CalDAV request to th62 minutes and 26 seconds 14:46:01Z the RENAME happens inside that silence, with no CalDAV request within ten minutes either side 15:37:57Z onwards PROPFIND 207 the NEW holder's first , 51m56s after the rename GET GET 200 200 and the previous customer's two objectsThe post rename check I ran at 14:46:38Z, the one that shows the collection does not follow the account, was made against the account's NEW address
zzr1sticky0921@alwaysdata.net, not against the vacated one. Its addrempty and the canary returned 404 there.
THE RESULT
15:34:59Z customer A, user 489835, a different customer, POSTs a brand new free account on the freed name 15:35:02Z accepted, 302 by 15:37:45Z the account is fully provisioned. It appears in A's own tenancy selector as account_zzq496p0929 and it carries its own mailbox, 638236, whose local part ders readonly 15:37:45Z A sets A's OWN mailbox password 15:37:57Z A's first CalDAV request. PROPFIND returns 1 vCard immediately GET on both, 200 and 200, returning the previous customer's FN, N, EMAIL, TEL and NOTE, and the event's after UID, SUMMARY, LOCATION and DESCRIPTIONBefore planting anything I hashed the two objects as your service seose digests to my log. The new holder's read returns them
byte for byte:
The new holder then PUT its own object into the same collection, 201 both. It is a live collection, not a cached copy of one.
CONTROLS, EACH REPEATED THREE TIMES, IN THE SAME WINDOW
Those first and last lines are the ones I would look at. The new holder reads this data purely because it holds the address. The customer who wrote the
data is refused at that same address in the same minute, and the newaddress that customer now holds.
THE RENAME AND DELETE DIFFERENCE SHOWED UP AGAIN INSIDE THIS RUN
At 15:41:39Z I deleted the account that had just taken the name. By 15:41:52Z zzq496p0929.alwaysdata.net returned NXDOMAIN. In the same DNS batch,
zzq496g0929.alwaysdata.net, a name I released by RENAME at 13:17Z to85.31.41.11 with no account behind it.
Your delete path cleans up. Your rename path does not. That is the wnd it is why I keep saying the fix is to make rename call
what delete already calls.
What about now?
Finally its fixed
And also can you help me with FS#486 bec there is no response to it
Thanks, you can now claim your bounty by opening a support ticket.