sendermap 0.1.2__tar.gz → 0.1.3__tar.gz

{sendermap-0.1.2 → sendermap-0.1.3}/ARCHITECTURE.md

@@ -137,7 +137,8 @@ Assembly
   -> SenderMap + Run
   story.write: the paragraph from the map; no query
   reconcile.with_claimed: the claimed names against the services; no query
-  -> render.text | render.markdown | to_dict JSON | web stream
+  -> render.view: one View, findings first, each thing said once; no query
+  -> render.text | render.markdown (both from the View) | to_dict JSON | web stream
 ```
 
 Each source returns an `Observed`: claims, unknowns, findings, gaps and what it checked. Sources never raise
@@ -208,7 +209,8 @@ for the check and a private one a moment later (DNS rebinding) is not caught.
 | `sources/networks.py` | Naming SPF IP ranges by the ranges services publish, then by network owner |
 | `sources/ct.py` | Certificate transparency: the only reader of certificate logs. Reads them once per map through a provider list (Cert Spotter always, crt.sh with `--ct`), each with its own tries, timeout and one-day disk cache, into one set of names; with `--ct`, each logged name resolved and matched by the same catalog matchers as the DNS sources |
 | `sources/subdomains.py` | Finding sending subdomains from a wordlist and the names `ct.py` read |
-| `render/text.py`, `render/markdown.py` | The terminal and Markdown views; both show the gaps and what was asked at each name, as the web page does, and group unrecognised IP ranges by network |
+| `render/view.py` | The View every view renders: findings first, then services by tier with one evidence line per kind and the setup in one clause, then what was not recognised, checked and asked, counted unless evidence is set; and the helpers only views use (unknowns grouped by network, the claimed parts, the CT lines, the resolver words) |
+| `render/text.py`, `render/markdown.py` | The terminal and Markdown views of the View; they hold no logic about the map. `tests/snapshots` holds both, for every corpus case, with evidence off and on |
 | `cli.py` | The `sendermap` command, and `sendermap mcp`, which starts the MCP server |
 | `mcp_server.py` | The MCP server: its two tools, two resources and instructions, and the summary of a map |
 | `testing.py` | Recording and replaying DNS answers and pages, and replaying a recorded case |
@@ -222,7 +224,7 @@ These live in `catalog.py` and the sources, and each has a test.
   longest pattern wins: `u161779.wl030.sendgrid.net` is Klaviyo, not SendGrid.
 - A DKIM key belongs to a service by CNAME first. `selector1` and `selector2` name nobody
   without the Microsoft CNAME. Next, a backed only selector (`rules.backed_only_selectors`, each
-  with a proof: `s1` and `s2` for Klaviyo) credits its one vendor only when SPF, MX or an NS
+  with a proof: `s1` and `s2` for Klaviyo, `mailing` for Optimizely Campaign) credits its one vendor only when SPF, MX or an NS
   delegation already shows that vendor, and nobody otherwise. Next, a selector on the list of a
   service that SPF, MX or an NS delegation already shows is that service's. Last, the name table, except for generic names (`default`, `mail`,
   any two-letter name not explicitly allowed).
@@ -233,7 +235,7 @@ These live in `catalog.py` and the sources, and each has a test.
   A redirect is ignored when the record has `all`. Inside a service's own record nothing more
   is credited, except inside a flattening service's record (EasyDMARC), which copies the
   domain's own senders.
-- A hosted SPF service (Valimail, OnDMARC, EasyDMARC) or a macro include is reported as a note,
+- A hosted SPF service (Valimail, OnDMARC, EasyDMARC, DmarcDuty) or a macro include is reported as a note,
   since it can authorize services without naming them.
 - A subdomain delegated by NS is the service's when its NS records name the service's
   nameservers (`delegation_ns`), as Klaviyo's recommended setup delegates `send.example.com` to
@@ -352,8 +354,8 @@ Checked's class as `denial`.
   set of networks, an owner name and a list of publishers are one line, "2 ranges and 1 address
   in AS16509 (Amazon Web Services)", with the publishers once after it, then the ranges, the first
   record and "+ N more" (every record with `--evidence`). `render.grouped_unknowns` does this
-  for the text and Markdown views by reading the value networks.py writes, and app.js does the
-  same with the same pattern, `render.NETWORK_VALUE`. A range with no network, one alone in its
+  for every view by reading the value networks.py writes, with the pattern
+  `render.NETWORK_VALUE`. A range with no network, one alone in its
   network, one whose networks have different names, and any unknown that is not an IP range stay
   single lines.
 - Every provider's answer becomes rows of (name, not before, not after) that go through one
@@ -459,8 +461,8 @@ DKIM or SPF and a note for a bounce or tracking CNAME. A service whose only clai
 only is one note asking whether the account is still used, and nothing about what its setup
 lacks. Broken raises nothing new: the key and SPF findings already exist. Every view shows one
 line per setup under its service, "Setup at <where>: SPF present, DKIM missing (selector1 and
-selector2 no such name), bounce CNAME not needed.", built by `setup.line` and, on the web page,
-by the same words in app.js. An optional item that is missing reads "not used (optional, <what
+selector2 no such name), bounce CNAME not needed.", built by `setup.line`; the web page shows
+the same words, rendered on the server. An optional item that is missing reads "not used (optional, <what
 was asked>)" in every view, so a reader does not take an optional record for a fault; its state
 in JSON stays `missing`, with its detail and evidence.
 
@@ -532,7 +534,7 @@ claimed in. Blank names are left out and a name written twice the same way count
 claimed is no reconciliation: `null` in JSON and no section in any view. Every view shows a
 CLAIMED SENDERS section with all four parts, "none" for an empty one, each found service with
 its tier and, when the client wrote another name, "claimed as" with their words. The text and
-Markdown views build it with `render.claimed_parts`, and app.js with the same words.
+Markdown and HTML views build it with `render.claimed_parts`.
 
 The web site caches maps by domain only; the claimed names a request carries are applied to the
 cached map for that response and kept nowhere. The page passes its own `?claimed=` on to the API,
@@ -690,7 +692,10 @@ recorder keeps the answers, not those requests.
   `tests/test_listing.py` validates `server.json` against the registry's 2025-12-11 schema, kept
   in `tests/fixtures/`, and holds the README line and `llms.txt`.
 - **Web site**: a FastAPI app. `GET /api/map?d=` returns the map as JSON, `GET /api/map.md?d=`
-  as Markdown, and `GET /api/map/stream?d=` streams progress then the map as server-sent events.
+  as Markdown, `GET /api/map.html?d=` as the HTML fragment the page shows, and
+  `GET /api/map/stream?d=` streams progress then one `map` event carrying the map and that
+  fragment. The page's HTML comes from `render/html.py`, the same View the command line shows;
+  app.js sets it as it came and draws the ring map, and holds no rendering logic of its own.
   Each takes `claimed`, a comma separated list, for the map's reconciliation.
   Uvicorn's access log is turned off when the app starts, so no query string is logged; a test
   runs a real server and checks that a request logs nothing. Visitor addresses are held in

{sendermap-0.1.2 → sendermap-0.1.3}/CHANGELOG.md

@@ -11,6 +11,24 @@ fails before anything is published.
 
 ## Unreleased
 
+## 0.1.3 (2026-10-23)
+
+- The terminal and Markdown views render one view model (`render/view.py`) and say each thing once: findings come first, each service shows one evidence line per kind ("DKIM keys: selector1, selector2 (both 2048 bit, by CNAME)") and its setup in one clause ("setup complete", or only what is missing), an item a finding names is said in the setup by its state alone, and What was asked gives counts. Full records and the names asked print with `--evidence`, the names in Markdown as a last section, Appendix: names asked. The Markdown senders table gains a Setup column, and its Setups section goes. Allbirds' Markdown view falls from 111 lines to 76.
+- The site renders the same view as the command line. The page's HTML is rendered on the server from the one View (`render/html.py`), every string escaped there, and app.js keeps only the form, the stream, the ring map and the buttons, so the page holds no third copy of the rendering logic and no longer shows the old layout (services before findings, a setup line per record). Each service's records in full and the names asked sit inside details elements. The stream's `map` event now carries `{"map": ..., "html": ...}`, and `GET /api/map.html` returns the fragment with the same limits and cache as `/api/map`.
+- The terminal view is easier to read. Each service is a block: its name and category, then one line per kind of record with the labels in a column, then its setup, coloured by whether it is complete. Wrapped lines keep their indent everywhere, so a long finding, gap or record no longer runs back to the left margin. The story prints one sentence per line.
+- Short DKIM keys at one name are said once: "Six DKIM keys at goop.com are 1024-bit: selector1, s1, s2, smtpapi, mandrill and key1", not six findings with the same advice. The JSON still has one finding per key.
+- Checks that are opt-in or turned off (crt.sh without `--ct`, `--no-web`, `--no-subdomains`) move out of Not checked into a short Not run section at the end, without the request they would have made. Not checked now holds only questions that were asked and got no usable answer. The story still names them.
+- The absence for a zone with no DKIM selectors says it in one sentence: "_domainkey.bounce.allbirds.com does not exist, so the 27-name sweep was skipped; the 8 names its MX, SPF and delegations point to were asked as a check, and none exists".
+- A subdomain that is a CNAME to the domain or to another sending subdomain is no longer mapped as a sending subdomain of its own. www.github.com, gist.github.com and shop.github.com are aliases of github.com and answer with its SPF and MX, so Microsoft 365 and Google Workspace showed at each with a missing DKIM key there: nine findings for setups no one made. An alias to a name outside the domain still counts, since its records are nowhere else in the map.
+- A zone that answers no such name for `_domainkey.<domain>` while a key sits under it is now a note, not a gap. Every selector is still asked there, so nothing went unchecked, but the story read "one DKIM selector that could not be read". The note says what the DNS host does wrong: under RFC 8020 that answer covers every name below it. functionalmedicinecoaching.org, on Bluehost's nameservers, answers this way.
+- A record that a likely service's setup lacks is a note, not a warning, and says to check the service still sends first. goop.com showed "Cloudflare Email Routing at goop.com has no SPF" as a warning from a DKIM key name alone, while its mail goes to Google.
+- A domain that does not exist in DNS says so: a finding, "The domain does not exist in DNS", and a story that leads with it, instead of "No sending service shows in DNS" as for a real domain with no mail set up. The map stops there: one lookup, not about 210.
+- A pasted value is refused unless it is a hostname: an IP address (`192.0.2.1` was mapped as a domain), a wildcard, characters a hostname cannot hold, a label of more than 63 characters or a numeric top-level domain now reads "not a domain" on the command line, the site and the MCP server alike, and a malformed name no longer raises an IDNA error.
+- The MCP tool's text reply lists findings most severe first, with short keys at one name said once, as the other views do. It listed them in the order the sources raised them.
+- 16 services added and 15 patterns for known ones, each with a live proof, from a run over 50 domains not mapped before (DTC brands, B2B software, universities, nonprofits, media). Marketing: Conversica, Maropost, Engaging Networks, ActionKit, Extole, Communicator, ClickDimensions, SPIRAL, FreshMail, Oracle Responsys. Transactional: SocketLabs (email-od.com). Business apps: Braintree, Tipalti, Impartner, and Wix's website host. Hosted SPF: DmarcDuty, read like Valimail. Known services: Qualtrics's qemailserver.com include and MX, Amazon SES's us-west-2 inbound, Postmark's bounce MX, Campaign Monitor's createsend.com include and inbound MX, Klaviyo's klaviyomail.com and Customer.io's customeriomail.com includes, GetResponse's _spf.getresponse.com, Freshdesk's fwdkim1 return path, Epsilon's epsl1.com, 250ok's report address under Validity Everest, Mailgun's report address and Stripe's custom email return path. Across the 50 domains, unknowns fall from 700 to 560.
+- Intercom's and Atlassian's return path CNAMEs are read: `outbound.intercom` and `atlassian-bounces` join the labels every map asks. Klaviyo gains km1 and km2, IONOS s2-ionos, and Optimizely Campaign `mailing` as a backed only name, credited and asked only where SPF or MX already shows Optimizely.
+- Listrak added (marketing): its `esp1.co` SPF include, bounce MX and tracking CNAME, and its network AS394396, each with a live proof. goop.com's bounce. and email. subdomains read as Listrak, not as seven unknowns.
+
 ## 0.1.2 (2026-10-15)
 
 - 31 services added and 10 patterns for known ones, each with a live proof, from a run over 50 large domains (retail, software, universities, charities, news, government). Marketing: Oracle Eloqua, Epsilon, Adobe Campaign, Microsoft Dynamics 365 Customer Insights, Blackbaud Luminate Online, Salsa Labs, Alida, Netigate, Hivebrite. Security gateway: Trend Micro Email Security, with an MX setup from its docs. Support, alerts and business apps: Khoros, Everbridge, Greenhouse, Red Points, Trustpilot, Cvent, Kibo Commerce, Docebo, ADP, SAP SuccessFactors, Fundraise Up, Q4, Madgex, Clinch. SPF flattening: AutoSPF, read like EasyDMARC. DMARC reports: DMARCLY, Report URI, Netcraft, Inbox Monster, Validity Everest, SendForensics. Known services: Sailthru's aspmx.sailthru.com and MX, Campaign Monitor's createsend.com tracking, Mandrill's inbound MX, HubSpot's MX hosts, Amazon SES's eu-west-1 inbound and Mail Manager MX, Squarespace's squarespace-mail.com, and Oracle's spf_c.oraclecloud.com. Across the 50 domains, unknowns fall from 1,008 to 727.

sendermap-0.1.3/CLAUDE.md

@@ -0,0 +1,38 @@
+# Sendermap
+
+## Architecture
+
+Sendermap is a library first. All DNS lookups, SPF and DMARC parsing,
+MX and DKIM evidence gathering, and the reasoning that maps evidence
+to sending services live in the sendermap package and nowhere else.
+
+The CLI, the MCP server, and any web front end are thin callers. They
+accept a domain, call the package, and present the result. They hold
+no DNS or parsing logic of their own.
+
+## Do not repeat yourself
+
+Before writing any new lookup or parsing code, check whether the
+package already has it. If it does, reuse it. If dns-audit has it,
+port it into the package once rather than copying it.
+
+Design the package so dns-audit and the APRF reader can import it
+later and drop their own DNS code. One engine per job.
+
+## Code quality
+
+This is a portfolio project. Readable names, short functions,
+docstrings on public functions, type hints throughout, tests for
+every parser. Keep public functions small and pure where possible.
+
+## Working style
+
+Show the package layout, one line per module, before writing code.
+Finish one thing before starting the next. Ask when a design choice
+is genuinely Neil's call; otherwise make the call and say what you
+chose. Prefer the repeatable solution over the one-off.
+
+## Writing
+
+No em dashes anywhere. Plain directives, not rules phrased as never.
+No emoji in README or docs. Lead with the point and say it once.

{sendermap-0.1.2 → sendermap-0.1.3}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: sendermap
-Version: 0.1.2
+Version: 0.1.3
 Summary: Type a domain, see every service that sends email as it, with the public evidence for each.
 Project-URL: Homepage, https://github.com/marmot7775/sendermap
 Author: Neil Anuskiewicz