Contact
The issue tracker is the way to reach us: github.com/mattkerr09/docket-site/issues. It is read by the person who writes the code, it is public so the answer helps whoever asks next, and — unlike the email address this page used to advertise — messages sent to it actually arrive.
There is no support email. That is a deliberate correction rather than an omission, and the reason is the more useful half of this page.
The address that did not work
Until today the footer of all 25 pages of this site offered
hello@docketseo.app. That address could not receive mail, and never had.
Delivering mail to a domain means looking up its MX record. docketseo.app has
none. RFC 5321 §5.1 says a
sender that finds no MX record falls back to the domain's address record — which for this
site is GitHub Pages, whose servers do not answer on port 25. So every message went out,
found nowhere to go, and bounced.
Nobody noticed because a bounce goes to the sender, not to us. This is the exact failure Docket is built to catch and did not: a channel that is advertised, believed, and dead. It is now a check we run on our own build, and it will be a check in the app.
Where to send what
| If you want to | Use |
|---|---|
| Report a wrong or confusing finding | Open an issue with the URL you audited and the check ID —
it is printed next to every finding, like index.byte_cap |
| Report a crash or a bug | Open an issue with your macOS version and what you were doing |
| Ask whether Docket does something | Check the full check list first, then ask |
| Request a feature | Open an issue. The known gaps are listed on the about page — no need to file those again |
| Report a security problem | Please do not open a public issue. Use GitHub's private advisory form |
What a good bug report contains
A finding you disagree with is the most valuable thing you can send, and the difference between a report that can be acted on and one that cannot is usually one line:
- The URL you audited. Not a description of it — the address, so the same crawl can be run.
- The check ID. Every finding carries one. It names the exact function that produced the output, which turns a search into a lookup.
- What you expected instead, and why. If a specification or a vendor's own documentation says otherwise, a link to it settles the question immediately. Docket's checks cite their sources for the same reason.
What to expect back
One person reads the tracker, so there is no response-time promise here — an invented one would be the same category of thing as the address that bounced. What is promised is that a report naming a specific URL and check ID gets a specific answer, and that if Docket is wrong the correction gets written down where the mistake was made.
Common questions
How do I report a finding I think is wrong?
Open an issue on GitHub with the URL you audited and the check ID printed beside the finding. Those two things let the same crawl be reproduced, which is the difference between a report that can be fixed and one that cannot.
Is there a support email address?
No. The site previously listed hello@docketseo.app, which could not receive mail: the domain has no MX record, so senders fell back to the GitHub Pages address record, where nothing answers on port 25. Every message bounced. The issue tracker is used instead because messages sent there arrive.
How do I report a security issue?
Not in a public issue. Use GitHub's private security advisory form on the repository so the problem can be fixed before it is described publicly.