docs(agents): calendar-user-address-set advertises a login name, not an address #41

Merged

jlxq0 merged 1 commit from docs-cuas into main

2026-09-02 01:08:12 +00:00

jlxq0 commented

2026-09-02 01:03:08 +00:00

Owner

Documentation only. Recorded so the next person does not re-derive it.

Stalwart builds the property from the login name rather than from the account's addresses:

crates/dav/src/principal/propfind.rs   vec![Href(format!("mailto:{}", account.name()))]
crates/common/src/cache/principals.rs  impl AccountCache { fn name() -> &str { self.name.as_ref() } }
crates/common/src/auth/mod.rs          AccountCache { name: Box<str>, addresses: Box<[EmailAddress]>, ... }

name and addresses are separate fields and name() returns the first, so the set is always one element and that element is a login name. Every principal on this server has name != emailAddress, which makes the advertised value mailto:julian and its equivalents rather than a mailbox.

Verified at the deployed tag rather than at the one the work was diagnosed on. v0.16.19 runs, not v0.16.14, and I had read main. Both files are byte-identical between main and v0.16.19 on the three lines that matter, checked at each ref rather than assumed to be close.

What it explains. No client can pick an address from the set, because the set contains something no client can use, so each sends the address its own account was configured with. Two Macs on one principal sending different organizers follows from that, and the iPhone needs no special mechanism.

Framing, which was a correction rather than a preference. This is a property of the server we run and not a bug awaiting a patch: reporting it upstream is not available to us, so nobody is waiting for anything, and the second framing would have implied somebody was.

Marked unmeasured: the live PROPFIND. All of this reads the code that serves it, blocked on the same CalDAV credential as #16 and #19.

Documentation only. Recorded so the next person does not re-derive it. **Stalwart builds the property from the login name rather than from the account's addresses:** crates/dav/src/principal/propfind.rs vec![Href(format!("mailto:{}", account.name()))] crates/common/src/cache/principals.rs impl AccountCache { fn name() -> &str { self.name.as_ref() } } crates/common/src/auth/mod.rs AccountCache { name: Box<str>, addresses: Box<[EmailAddress]>, ... } `name` and `addresses` are separate fields and `name()` returns the first, so the set is always one element and that element is a login name. Every principal on this server has `name != emailAddress`, which makes the advertised value `mailto:julian` and its equivalents rather than a mailbox. **Verified at the deployed tag rather than at the one the work was diagnosed on.** `v0.16.19` runs, not `v0.16.14`, and I had read `main`. Both files are byte-identical between `main` and `v0.16.19` on the three lines that matter, checked at each ref rather than assumed to be close. **What it explains.** No client can pick an address from the set, because the set contains something no client can use, so each sends the address its own account was configured with. Two Macs on one principal sending different organizers follows from that, and the iPhone needs no special mechanism. **Framing, which was a correction rather than a preference.** This is a property of the server we run and not a bug awaiting a patch: reporting it upstream is not available to us, so nobody is waiting for anything, and the second framing would have implied somebody was. **Marked unmeasured**: the live `PROPFIND`. All of this reads the code that serves it, blocked on the same CalDAV credential as #16 and #19.

jlxq0 added 1 commit

2026-09-02 01:03:08 +00:00

docs(agents): calendar-user-address-set advertises a login name, not an address

CI / cargo (pull_request) Successful in 55s

Details

CI / docker (pull_request) Successful in 59s

Details

480894a238

Stalwart builds the property from account.name(), and AccountCache carries name
and addresses as separate fields with name() returning the first. So the set is
always one element and that element is a login name. Every principal on this
server has name != emailAddress, which makes the advertised value mailto:julian
and its equivalents rather than a mailbox.

Verified identical at main and at v0.16.19, the deployed tag, rather than at
0.16.14 which is the version the calendar work was diagnosed on and not the one
that runs.

That explains why no client picks an address from the set: it contains
something no client can use, so each sends the address its own account was
configured with. Two Macs on one principal sending different organizers follows
from that, and the iPhone needs no special mechanism.

Recorded as a property of the server we run rather than as a bug awaiting a
patch, because reporting it upstream is not available to us and the second
framing implies somebody is waiting for something.

The live PROPFIND stays unmeasured and is marked as such. All of this reads the
code that serves it, blocked on the same credential as #16 and #19.

jlxq0 merged commit 3aabcd44c0 into main

2026-09-02 01:08:12 +00:00

jlxq0 deleted branch docs-cuas

2026-09-02 01:08:13 +00:00

jlxq0 referenced this pull request from a commit

2026-09-02 01:08:13 +00:00

Merge pull request 'docs(agents): calendar-user-address-set advertises a login name, not an address' (#41) from docs-cuas into main