7 Commits

Include renames

Author	SHA1	Message	Date
jcoffey-dev	4ce772d6e5	http: a way to send a write that must not be applied twice ... A POST that failed in transport -- including a timeout while waiting for the answer -- is resent today, and so is one that got a 502 or 504. For a write such as Email/import the server may already have applied the first copy, so the resend can create a duplicate. post_json_once and Request::send_once send it once: a transport failure or a gateway error comes back to the caller, which can check the target before trying again. 429 and 503, which mean the request was not processed, are still retried.	2026-09-30 12:39:57 -07:00
jcoffey-dev	234b3203d7	Scope --allow-invalid-certs to the server the user named ... The flag switched certificate checks off for every connection in the run. That included the Microsoft sign-in endpoints, so a user passing it for a self-signed source also sent refresh tokens, device codes and EWS client secrets over unverified TLS. It also covered the export target, and any host a server redirected to or named for its API, uploads or downloads. It now applies only where the user pointed it: the host of --url, for the source of an import or the target of an export. For an Exchange import with no --url, it covers the mailbox's own domain, where on-premises Autodiscover looks, and then only the EWS endpoint Autodiscover finds. The Microsoft and Google sign-in and cloud hosts are always verified, with or without the flag. Each HTTP client keeps a verifying agent and, only when the flag applies, a second one that accepts invalid certificates, and picks per request by host. The sign-in modules no longer take the flag at all. Autodiscover v2, which is Microsoft's own service, is always verified.	2026-09-30 11:31:44 -07:00
jcoffey-dev	7fbcf5031e	Take the registry capability from the server's session ... Registry calls (x:Account, x:Domain and the rest of the x: types) were always sent under urn:stalwart:jmap. inbuxa advertises the same registry as urn:inbuxa:jmap:registry, so the capability now comes from the connected server: Session::registry_urn() picks urn:inbuxa:jmap:registry when the session advertises it, else urn:stalwart:jmap, so Stalwart servers still work as a source. A request carrying an x: call against a server that advertises neither fails with a MissingCapability error naming both, treated like any other connection-level failure, instead of sending a capability the server never offered.	2026-09-30 10:09:10 -07:00
Maurus Decimus	1cc633f39c	v1.0.8 (fixes #29 fixes #30 fixes #31)	2026-08-16 12:29:05 +02:00
Maurus Decimus	4102b5f4ae	Include correct JMAP capabilities in using	2026-06-19 11:05:04 +02:00
Maurus Decimus	b173805212	v1.0.0	2026-05-30 08:09:57 +02:00
Maurus Decimus	576073f8c9	Initial commit	2026-05-29 18:02:15 +02:00