diff options
| -rw-r--r-- | .gitignore | 5 | ||||
| -rw-r--r-- | LICENSE | 338 | ||||
| -rw-r--r-- | README.md | 73 | ||||
| -rw-r--r-- | docs/specs/2026-09-08-abusectl-design.md | 423 |
4 files changed, 839 insertions, 0 deletions
diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..bd7777f --- /dev/null +++ b/.gitignore @@ -0,0 +1,5 @@ +__pycache__/ +*.pyc +.venv/ +venv/ +HANDOFF.md @@ -0,0 +1,338 @@ + GNU GENERAL PUBLIC LICENSE + Version 2, June 1991 + + Copyright (C) 1989, 1991 Free Software Foundation, Inc., + <https://fsf.org/> + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + + Preamble + + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +License is intended to guarantee your freedom to share and change free +software--to make sure the software is free for all its users. This +General Public License applies to most of the Free Software +Foundation's software and to any other program whose authors commit to +using it. (Some other Free Software Foundation software is covered by +the GNU Lesser General Public License instead.) You can apply it to +your programs, too. + + When we speak of free software, we are referring to freedom, not +price. Our General Public Licenses are designed to make sure that you +have the freedom to distribute copies of free software (and charge for +this service if you wish), that you receive source code or can get it +if you want it, that you can change the software or use pieces of it +in new free programs; and that you know you can do these things. + + To protect your rights, we need to make restrictions that forbid +anyone to deny you these rights or to ask you to surrender the rights. +These restrictions translate to certain responsibilities for you if you +distribute copies of the software, or if you modify it. + + For example, if you distribute copies of such a program, whether +gratis or for a fee, you must give the recipients all the rights that +you have. You must make sure that they, too, receive or can get the +source code. And you must show them these terms so they know their +rights. + + We protect your rights with two steps: (1) copyright the software, and +(2) offer you this license which gives you legal permission to copy, +distribute and/or modify the software. + + Also, for each author's protection and ours, we want to make certain +that everyone understands that there is no warranty for this free +software. If the software is modified by someone else and passed on, we +want its recipients to know that what they have is not the original, so +that any problems introduced by others will not reflect on the original +authors' reputations. + + Finally, any free program is threatened constantly by software +patents. We wish to avoid the danger that redistributors of a free +program will individually obtain patent licenses, in effect making the +program proprietary. To prevent this, we have made it clear that any +patent must be licensed for everyone's free use or not licensed at all. + + The precise terms and conditions for copying, distribution and +modification follow. + + GNU GENERAL PUBLIC LICENSE + TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION + + 0. This License applies to any program or other work which contains +a notice placed by the copyright holder saying it may be distributed +under the terms of this General Public License. The "Program", below, +refers to any such program or work, and a "work based on the Program" +means either the Program or any derivative work under copyright law: +that is to say, a work containing the Program or a portion of it, +either verbatim or with modifications and/or translated into another +language. (Hereinafter, translation is included without limitation in +the term "modification".) Each licensee is addressed as "you". + +Activities other than copying, distribution and modification are not +covered by this License; they are outside its scope. The act of +running the Program is not restricted, and the output from the Program +is covered only if its contents constitute a work based on the +Program (independent of having been made by running the Program). +Whether that is true depends on what the Program does. + + 1. You may copy and distribute verbatim copies of the Program's +source code as you receive it, in any medium, provided that you +conspicuously and appropriately publish on each copy an appropriate +copyright notice and disclaimer of warranty; keep intact all the +notices that refer to this License and to the absence of any warranty; +and give any other recipients of the Program a copy of this License +along with the Program. + +You may charge a fee for the physical act of transferring a copy, and +you may at your option offer warranty protection in exchange for a fee. + + 2. You may modify your copy or copies of the Program or any portion +of it, thus forming a work based on the Program, and copy and +distribute such modifications or work under the terms of Section 1 +above, provided that you also meet all of these conditions: + + a) You must cause the modified files to carry prominent notices + stating that you changed the files and the date of any change. + + b) You must cause any work that you distribute or publish, that in + whole or in part contains or is derived from the Program or any + part thereof, to be licensed as a whole at no charge to all third + parties under the terms of this License. + + c) If the modified program normally reads commands interactively + when run, you must cause it, when started running for such + interactive use in the most ordinary way, to print or display an + announcement including an appropriate copyright notice and a + notice that there is no warranty (or else, saying that you provide + a warranty) and that users may redistribute the program under + these conditions, and telling the user how to view a copy of this + License. (Exception: if the Program itself is interactive but + does not normally print such an announcement, your work based on + the Program is not required to print an announcement.) + +These requirements apply to the modified work as a whole. If +identifiable sections of that work are not derived from the Program, +and can be reasonably considered independent and separate works in +themselves, then this License, and its terms, do not apply to those +sections when you distribute them as separate works. But when you +distribute the same sections as part of a whole which is a work based +on the Program, the distribution of the whole must be on the terms of +this License, whose permissions for other licensees extend to the +entire whole, and thus to each and every part regardless of who wrote it. + +Thus, it is not the intent of this section to claim rights or contest +your rights to work written entirely by you; rather, the intent is to +exercise the right to control the distribution of derivative or +collective works based on the Program. + +In addition, mere aggregation of another work not based on the Program +with the Program (or with a work based on the Program) on a volume of +a storage or distribution medium does not bring the other work under +the scope of this License. + + 3. You may copy and distribute the Program (or a work based on it, +under Section 2) in object code or executable form under the terms of +Sections 1 and 2 above provided that you also do one of the following: + + a) Accompany it with the complete corresponding machine-readable + source code, which must be distributed under the terms of Sections + 1 and 2 above on a medium customarily used for software interchange; or, + + b) Accompany it with a written offer, valid for at least three + years, to give any third party, for a charge no more than your + cost of physically performing source distribution, a complete + machine-readable copy of the corresponding source code, to be + distributed under the terms of Sections 1 and 2 above on a medium + customarily used for software interchange; or, + + c) Accompany it with the information you received as to the offer + to distribute corresponding source code. (This alternative is + allowed only for noncommercial distribution and only if you + received the program in object code or executable form with such + an offer, in accord with Subsection b above.) + +The source code for a work means the preferred form of the work for +making modifications to it. For an executable work, complete source +code means all the source code for all modules it contains, plus any +associated interface definition files, plus the scripts used to +control compilation and installation of the executable. However, as a +special exception, the source code distributed need not include +anything that is normally distributed (in either source or binary +form) with the major components (compiler, kernel, and so on) of the +operating system on which the executable runs, unless that component +itself accompanies the executable. + +If distribution of executable or object code is made by offering +access to copy from a designated place, then offering equivalent +access to copy the source code from the same place counts as +distribution of the source code, even though third parties are not +compelled to copy the source along with the object code. + + 4. You may not copy, modify, sublicense, or distribute the Program +except as expressly provided under this License. Any attempt +otherwise to copy, modify, sublicense or distribute the Program is +void, and will automatically terminate your rights under this License. +However, parties who have received copies, or rights, from you under +this License will not have their licenses terminated so long as such +parties remain in full compliance. + + 5. You are not required to accept this License, since you have not +signed it. However, nothing else grants you permission to modify or +distribute the Program or its derivative works. These actions are +prohibited by law if you do not accept this License. Therefore, by +modifying or distributing the Program (or any work based on the +Program), you indicate your acceptance of this License to do so, and +all its terms and conditions for copying, distributing or modifying +the Program or works based on it. + + 6. Each time you redistribute the Program (or any work based on the +Program), the recipient automatically receives a license from the +original licensor to copy, distribute or modify the Program subject to +these terms and conditions. You may not impose any further +restrictions on the recipients' exercise of the rights granted herein. +You are not responsible for enforcing compliance by third parties to +this License. + + 7. If, as a consequence of a court judgment or allegation of patent +infringement or for any other reason (not limited to patent issues), +conditions are imposed on you (whether by court order, agreement or +otherwise) that contradict the conditions of this License, they do not +excuse you from the conditions of this License. If you cannot +distribute so as to satisfy simultaneously your obligations under this +License and any other pertinent obligations, then as a consequence you +may not distribute the Program at all. For example, if a patent +license would not permit royalty-free redistribution of the Program by +all those who receive copies directly or indirectly through you, then +the only way you could satisfy both it and this License would be to +refrain entirely from distribution of the Program. + +If any portion of this section is held invalid or unenforceable under +any particular circumstance, the balance of the section is intended to +apply and the section as a whole is intended to apply in other +circumstances. + +It is not the purpose of this section to induce you to infringe any +patents or other property right claims or to contest validity of any +such claims; this section has the sole purpose of protecting the +integrity of the free software distribution system, which is +implemented by public license practices. Many people have made +generous contributions to the wide range of software distributed +through that system in reliance on consistent application of that +system; it is up to the author/donor to decide if he or she is willing +to distribute software through any other system and a licensee cannot +impose that choice. + +This section is intended to make thoroughly clear what is believed to +be a consequence of the rest of this License. + + 8. If the distribution and/or use of the Program is restricted in +certain countries either by patents or by copyrighted interfaces, the +original copyright holder who places the Program under this License +may add an explicit geographical distribution limitation excluding +those countries, so that distribution is permitted only in or among +countries not thus excluded. In such case, this License incorporates +the limitation as if written in the body of this License. + + 9. The Free Software Foundation may publish revised and/or new versions +of the General Public License from time to time. Such new versions will +be similar in spirit to the present version, but may differ in detail to +address new problems or concerns. + +Each version is given a distinguishing version number. If the Program +specifies a version number of this License which applies to it and "any +later version", you have the option of following the terms and conditions +either of that version or of any later version published by the Free +Software Foundation. If the Program does not specify a version number of +this License, you may choose any version ever published by the Free Software +Foundation. + + 10. If you wish to incorporate parts of the Program into other free +programs whose distribution conditions are different, write to the author +to ask for permission. For software which is copyrighted by the Free +Software Foundation, write to the Free Software Foundation; we sometimes +make exceptions for this. Our decision will be guided by the two goals +of preserving the free status of all derivatives of our free software and +of promoting the sharing and reuse of software generally. + + NO WARRANTY + + 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY +FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN +OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES +PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED +OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF +MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS +TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE +PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, +REPAIR OR CORRECTION. + + 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING +WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR +REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, +INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING +OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED +TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY +YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER +PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE +POSSIBILITY OF SUCH DAMAGES. + + END OF TERMS AND CONDITIONS + + How to Apply These Terms to Your New Programs + + If you develop a new program, and you want it to be of the greatest +possible use to the public, the best way to achieve this is to make it +free software which everyone can redistribute and change under these terms. + + To do so, attach the following notices to the program. It is safest +to attach them to the start of each source file to most effectively +convey the exclusion of warranty; and each file should have at least +the "copyright" line and a pointer to where the full notice is found. + + <one line to give the program's name and a brief idea of what it does.> + Copyright (C) <year> <name of author> + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License along + with this program; if not, see <https://www.gnu.org/licenses/>. + +Also add information on how to contact you by electronic and paper mail. + +If the program is interactive, make it output a short notice like this +when it starts in an interactive mode: + + Gnomovision version 69, Copyright (C) year name of author + Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. + This is free software, and you are welcome to redistribute it + under certain conditions; type `show c' for details. + +The hypothetical commands `show w' and `show c' should show the appropriate +parts of the General Public License. Of course, the commands you use may +be called something other than `show w' and `show c'; they could even be +mouse-clicks or menu items--whatever suits your program. + +You should also get your employer (if you work as a programmer) or your +school, if any, to sign a "copyright disclaimer" for the program, if +necessary. Here is a sample; alter the names: + + Yoyodyne, Inc., hereby disclaims all copyright interest in the program + `Gnomovision' (which makes passes at compilers) written by James Hacker. + + <signature of Moe Ghoul>, 1 April 1989 + Moe Ghoul, President of Vice + +This General Public License does not permit incorporating your program into +proprietary programs. If your program is a subroutine library, you may +consider it more useful to permit linking proprietary applications with the +library. If this is what you want to do, use the GNU Lesser General +Public License instead of this License. diff --git a/README.md b/README.md new file mode 100644 index 0000000..78eb42f --- /dev/null +++ b/README.md @@ -0,0 +1,73 @@ +# abusectl + +Abuse reporting for phishing mail. Parses a flagged message, extracts its +indicators, resolves who to report each one to, and files the result to a +MISP instance and to public abuse channels. + +**Status: early.** The design is settled and the first part is being built. +Nothing here submits anything yet. + +## What it does + +``` +abusectl parse msg.eml # -> case directory, IOCs offline +abusectl contacts <case> # + abuse contacts via RDAP network, read-only +abusectl report <case> # + report bodies offline + # review the bodies, by hand or in a mail client +abusectl submit <case> # MISP, then the vendors network, writes +``` + +Each subcommand runs on its own and is useful on its own. `parse` triages a +message with no configuration at all; `parse`, `contacts` and `report` +together produce a document you can send by hand with no API key anywhere. + +State lives in a **case directory** rather than in memory, so a review can +take a week and survive a reboot. + +## Two properties that are not negotiable + +**Recipient identifiers are never captured.** Not the `To`, `Cc`, +`Delivered-To` or `X-Original-To` headers, not your Message-IDs, not maildir +paths or account names. They are dropped at extraction rather than stripped at +submission, so the tool cannot disclose an identifier it was never given. +Tracking tokens inside URLs count: parameter values are redacted, parameter +names and paths are kept, because the names fingerprint the kit and the values +identify you. + +**Nothing remote is ever fetched while parsing.** Not the URLs, not the +redirect chains, not remote images. Following a link confirms your address is +live to the sender and fires exactly the tracker the message wanted. Redirect +chains are read from headers and link text, never by following them. + +## Reversible and irreversible + +`submit` writes to MISP first and stops if that fails. MISP is your own +instance and is correctable; a report to AbuseIPDB, URLhaus or VirusTotal +cannot be recalled. The reversible step gates the irreversible ones, and it is +also what answers "have I reported this infrastructure before". + +Every destination carries its own status, so a retry sends only what failed. A +rate-limited vendor does not mean re-reporting to the three that accepted. + +## Design + +`docs/specs/2026-09-08-abusectl-design.md` is the umbrella design. Each part +gets its own spec before it is built. + +## Requirements + +Python 3.11 or newer. `parse` and `report` need nothing else; `contacts` needs +an HTTP client and `submit` needs PyMISP. Development runs from a venv in the +checkout. + +## License + +GPLv2. See `LICENSE`. + +## Development Approach + +This project is developed using AI-assisted tools. Code is generated with the help of AI based on human-provided specifications, design decisions, and iterative feedback. + +All contributions are reviewed, tested, and curated by the maintainer before being included in the codebase. AI is used as a productivity and exploration tool, while human oversight remains central to all decisions. + +The goal is to combine the flexibility of AI-assisted development with standard open-source practices such as transparency, review, and accountability. diff --git a/docs/specs/2026-09-08-abusectl-design.md b/docs/specs/2026-09-08-abusectl-design.md new file mode 100644 index 0000000..7f72b5c --- /dev/null +++ b/docs/specs/2026-09-08-abusectl-design.md @@ -0,0 +1,423 @@ +# abusectl: abuse reporting sidecar, umbrella design + +Status: **agreed 2026-09-08**, in one brainstorming session with the user. +This is the UMBRELLA spec. Each part gets its own spec before it is built; +this one settles the decisions the parts share and would be expensive to +change later. + +Backlog: item 194 in qtmaildir's +`docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md`, which carries the +qtmaildir half and its ordering against items 187 and 190. This document is +the sidecar, and the two repositories are coupled only by the manifest format +below and the command name in qtmaildir's config. + +## Why this exists + +The user is a cybersecurity consultant. They have been phished, and they want +to act quickly and effectively on a campaign that targets them: parse a +flagged message, extract its indicators, find who to report each one to, and +file the result both to their own MISP instance and to the public abuse +channels. Filling a database with phishing attempts is a feature no other mail +client offers, which is a reason this one exists. + +Two of the user's own constraints are SAFETY PROPERTIES rather than +preferences, stated when the item was first written and not to be traded away +for convenience. They are specified in full below: recipient identifiers are +never captured, and no remote content is ever fetched during parsing. + +## Why it is not in qtmaildir + +qtmaildir does no network protocol work at all, by design: fetching and +sending are external scripts, which is why there is no IMAP client, no SMTP +client, and why send is a per-account `send_command` on stdin. This tool needs +RDAP, three vendor REST APIs and mail to abuse desks, which is four outbound +protocols. Building it into `src/` would repeal that rule rather than extend +it. Its ecosystem is Python besides, where `assets/hooks/` already puts the +non-GUI parts of this mail system. + +**The split is architectural and is not a judgement on the feature.** The +review UI lives in qtmaildir, because a reviewable document is exactly what +makes a GUI review possible. + +**A separate repository, not a submodule.** qtmaildir invokes `abusectl` as a +subprocess by name, the way it already invokes `mailsync.sh` and the +`send_command`; nothing in `src/` includes or imports it. A submodule pins a +commit that is not the one that runs, since what executes is whatever is +installed on `$PATH`, and it would cost a two-step clone, an ordering +constraint on every push across two remotes, and an empty directory in the +release tarball, because `git archive` does not include submodule contents. +Compatibility, if it ever matters, is a `format` version in the manifest, the +same discipline `rules.json` already uses across two readers in two languages. + +## Shape + +One tool, subcommands, one repository. Each subcommand reads and writes a +**case directory**, which is where state lives between steps. A review can +therefore take a week and survive a reboot. + +``` +abusectl parse msg.eml -> case dir, IOCs offline, pure +abusectl contacts <case> -> + abuse contacts network, read-only +abusectl report <case> -> + report bodies offline, pure + [ review, in qtmaildir or $EDITOR ] +abusectl submit <case> -> MISP, then vendors network, writes +``` + +Every subcommand is independently runnable and independently useful. `parse` +alone triages a message. `parse` + `contacts` + `report` produces a document +that can be sent by hand, with no API key configured anywhere. + +**The tool stays usable from a terminal.** The qtmaildir dialog is one front +end, never the only one: a message that never came through qtmaildir, or a +session over SSH, must still be workable. Same reasoning as `mailsync.sh` +printing to stdout as well as its log. + +## The one hard ordering rule + +`submit` writes **MISP first** and aborts the vendor fan-out if that write +fails. + +MISP is the user's own instance and is correctable through its REST API +(update, soft-delete, hard-delete); a submission to AbuseIPDB, URLhaus or +VirusTotal cannot be recalled. So the reversible step gates the irreversible +ones. Reporting externally with no local record of having done so, and no +dedup entry to stop a duplicate later, is worse than not reporting at all. + +MISP is also the DEDUP ORACLE. It correlates attributes by value across +events and answers `/attributes/restSearch`, so `submit` can ask whether the +infrastructure has been reported before and skip or attach rather than +duplicate. Writing it before the fan-out is what makes that answer available. + +**Correction is MISP's own web UI**, not a subcommand here. A destructive verb +in a tool run often, guarding data the user cares about, is not worth building +for something MISP already does well. A correction subcommand is possible +later. + +## The case directory + +``` +<cases>/2026-09-08-a3f1/ + source.eml the original, unredacted + manifest.json IOCs, contacts, destinations, per-destination status + bodies/ + abusedb.json + rdap-1.xarf +``` + +The path is configurable. **Nothing deletes cases**: they are the user's +evidence, and a tool that silently bins a report sent last month is worse than +a directory that grows. Cleanup is not built. + +`manifest.json` carries a `format` version. Bodies are separate files because +they are text a human edits; putting them in the manifest would mean editing +escaped strings inside a JSON document, or growing an extract/apply pair, +which is a directory reinvented with extra steps. + +**`source.eml` is unredacted local evidence, and the submit path must never +attach it wholesale.** This is the one route by which the redaction guarantee +below could leak, so it is stated rather than left obvious. The case directory +is sensitive at rest. + +## Redaction, structurally + +**The parser never captures recipient identifiers.** Not stored, not hashed, +not written to the manifest: + +- `To`, `Cc`, `Delivered-To`, `X-Original-To` +- the user's own Message-IDs +- maildir paths and account keys + +The guarantee is that **the tool cannot disclose an identifier it was never +given**. It holds no matter what a later subcommand does, which is why it is +enforced at extraction rather than at submission: a strip-on-submit rule +depends on every future sending path remembering, and this one does not. + +**The report is reviewable and hand-editable before anything is sent.** What +the tool derives and what the user chooses to disclose are separate things. +The user can add facts during review that the tool never held, including how +many of their addresses a campaign hit, which is a fact they supply from their +own knowledge. + +### Tracking parameters are recipient identifiers + +A phishing URL commonly carries the recipient's identity in its query string: +`?e=you@example.org` plaintext, `?u=<base64 of the address>`, or +`?id=<md5 of the address>`, which a wordlist or a targeted guess reverses. +Publishing that to four third parties is the same leak as publishing the `To` +header, hidden one level down. + +It also **deanonymises the reporter to the attacker**. Abuse desks forward +reports to their customers and URLhaus is a public feed, so a kit operator +watching for their own URLs learns which target reported them. For a +consultant the parameter may carry a CLIENT's identifier rather than the +user's own. + +**So: keep scheme, host and path; keep parameter NAMES; redact parameter +VALUES.** + +``` +http://login-example.invalid/verify?id=REDACTED&src=REDACTED +``` + +This costs the report almost nothing. Parameter names are part of the kit's +fingerprint and campaigns correlate on infrastructure, not on per-victim +tokens. The token is unique per recipient BY DESIGN, so it is the one part of +the URL that cannot correlate anything, and keeping it makes dedup actively +worse: two messages from one campaign would look like different URLs. + +**Path segments carry the token too.** `/verify/ZGFuaXhAZXhhbXBsZS5vcmc/` is +common and a query-string-only rule misses it entirely. A path segment that +looks like base64 or a long hex string is FLAGGED FOR REVIEW rather than +silently redacted, since a path may also be meaningful. + +The full URL survives in `source.eml` either way, so the evidence exists +locally; it is simply not what gets published by default, and the review gate +allows pasting one in by hand when a particular desk genuinely needs it. + +## Components + +``` +abusectl/ + cli.py argparse dispatch, exit codes. No logic. + case.py case dir: create, load, save manifest, atomic writes + parse.py .eml -> IOCs stdlib only, pure + contacts.py IOCs -> abuse contacts (RDAP) network, read-only + report.py IOCs + contacts -> bodies pure + submit.py bodies -> MISP, then vendors network, writes + destinations/ one module per target + misp.py abusedb.py urlhaus.py virustotal.py email.py + config.py ~/.config/abusectl/config.toml +``` + +**`case.py` is the spine.** Every subcommand goes through it and nothing else +writes the case directory. It owns the manifest schema and its version, and it +writes ATOMICALLY, temp file plus rename, the way `mailrules.py` saves +`rules.json`. A half-written manifest during a review is a corrupted evidence +record. + +**`parse.py` is stdlib-only and pure.** Bytes in, IOC list out; no socket, no +config read. That is what makes it testable against fixtures with no setup. + +**`contacts.py` and `submit.py` are the only network modules**, and both take +an INJECTED TRANSPORT. Not an abstraction for its own sake: it is the seam +that lets the irreversible path be tested without sending anything. + +**`destinations/` is one module per target**, each exposing the same two +functions, build a body and send one. A fifth vendor is a new file rather than +an edit to `submit.py`. This is the one place a plugin shape earns itself, +because there are four known members with genuinely different APIs. There is +no discovery mechanism; it is a package with four members. + +**`config.py`** reads TOML through stdlib `tomllib`, no dependency. It holds +the cases path, the MISP URL and key, vendor keys, the user's reporting +identity for X-ARF, and the trusted-relay boundary described below. Secrets +live in a file with mode `0600`, checked on load, and **never reach the +manifest or a log**. + +### Deliberately absent + +No database of its own: MISP is the database and case directories are the +local record. No daemon, no queue, no retry scheduler, since retry is the user +running `submit` again. + +### Dependencies by part + +| Part | Needs | +|---|---| +| `parse` | stdlib only | +| `contacts` | an HTTP client | +| `report` | stdlib only | +| `submit` | HTTP client, PyMISP | + +`requirements.txt` is empty until `contacts` is built. **Development runs from +a venv in the repository**, gitignored; packaging and distribution are +deliberately out of scope until the tool does something worth installing. A +SlackBuild in `my-slackbuilds` is the eventual shape, with an nvchecker +stanza, matching every other tool the user runs. + +## Data flow + +``` +msg.eml + | parse creates case, writes source.eml + iocs[] + v +case dir --------------------------------------------------+ + | contacts RDAP per IOC, writes contacts[] | + v | every step +case dir | reads and + | report writes bodies/, destinations[] | rewrites + v | manifest.json +case dir -- [ REVIEW: qtmaildir dialog or $EDITOR ] -------+ + | submit | + +--> MISP ------ fails? STOP, nothing sent --------------+ + +--> vendors + abuse desks, per-destination status +``` + +**Review edits the BODIES, not the IOCs.** Once `report` has run the bodies +are the artifact, so `report` refuses to run again on a case whose bodies were +modified after generation unless forced, by a timestamp check in the manifest. +Silently discarding a review that took twenty minutes is what makes a tool +untrustworthy. + +**`submit` is resumable.** It reads per-destination status and skips anything +already `sent`, so running it twice is safe. This matters because the failure +that will actually be hit is a rate limit, not a bug. + +## Manifest schema + +```json +{ + "format": 1, + "case_id": "2026-09-08-a3f1", + "created": "2026-09-08T12:31:04Z", + "source": "source.eml", + + "iocs": [ + { "id": "ioc-1", "type": "ipv4", "value": "203.0.113.42", + "origin": "received-chain", "confidence": "untrusted-hop" }, + { "id": "ioc-2", "type": "domain", "value": "login-example.invalid", + "origin": "href" }, + { "id": "ioc-3", "type": "url", + "value": "http://login-example.invalid/verify?id=REDACTED", + "origin": "href-html" }, + { "id": "ioc-4", "type": "sha256", "value": "e3b0c442...", + "origin": "attachment", "filename": "invoice.pdf" } + ], + + "auth": { "spf": "fail", "dkim": "none", "dmarc": "fail" }, + + "contacts": [ + { "ioc": "ioc-1", "abuse": "abuse@example.invalid", + "source": "rdap", "handle": "AS64496" }, + { "ioc": "ioc-2", "abuse": null, "source": "rdap", + "error": "no abuse contact published" } + ], + + "destinations": [ + { "id": "misp", "kind": "misp", "iocs": ["ioc-1","ioc-2","ioc-3"], + "body": null, "status": "pending" }, + { "id": "abusedb", "kind": "api", "iocs": ["ioc-1"], + "body": "bodies/abusedb.json", "status": "pending" }, + { "id": "rdap-1", "kind": "email", "iocs": ["ioc-1"], + "target": "abuse@example.invalid", + "body": "bodies/rdap-1.xarf", "status": "pending" } + ] +} +``` + +After a submit in which one destination failed: + +```json +{ "id": "abusedb", "status": "sent", + "sent_at": "2026-09-08T12:40:11Z", "receipt": "8891234" }, +{ "id": "virustotal", "status": "failed", + "attempted_at": "2026-09-08T12:40:12Z", "error": "429 rate limited" } +``` + +### Five schema decisions, and why + +**IOCs carry an `id` and everything references it.** Contacts and destinations +point at `ioc-2` rather than repeating the value, so there is one place to +correct it and a destination cannot drift from the IOC it reports. + +**`origin` on every IOC** names where it came from: `received-chain`, `href`, +`attachment`. During review the user needs to know whether an IP came from a +header to trust or one the attacker wrote. Without it, review is guesswork. + +**`confidence: untrusted-hop`** exists because of the `Received` trap below. +An IP from beneath the trusted-relay boundary is attacker-supplied, and the +manifest says so rather than presenting it as fact. + +**`status` is per destination**, never one status for the case. There is no +single answer when four destinations disagree. + +**MISP is a destination like the others**, with `body: null` because PyMISP +builds its own payload. That keeps `submit` one loop with one ordering rule +rather than a special case beside a loop. + +## Error handling + +**Partial failure is the normal case, not an exception.** Four destinations +can disagree, so each carries its own status and a retry sends only what did +not land. All-or-nothing would be wrong here: the successful submissions +really happened and cannot be recalled, so recording them as failed would make +the next attempt duplicate real reports. + +**A MISP failure aborts before anything irreversible runs**, per the ordering +rule above. + +**A missing abuse contact is not an error.** RDAP publishes none for many +netblocks. The IOC keeps `"abuse": null` with the reason, the destination is +simply not created, and review shows what could not be resolved. + +## Testing + +`parse` is fixtures in, JSON out, so the whole reversible half is testable +offline with no network and no keys. The network parts get their transport +stubbed through the injected seam. + +**Fixtures use `example.org` and `.invalid` addresses and generic +placeholders**, per the user's standing personal-data rule. Real phishing +samples do not go in the repository: they carry the recipient identifiers this +tool exists to keep out of reports, and a repository is potentially public. + +Python conventions follow `assets/hooks/` in qtmaildir: GPLv2 header on every +file, `unittest`, a `test_<module>.py` beside each module, no framework. + +## `parse` in detail: the first part to build + +Extracted: + +- **Sending IP** from the `Received` chain: the last UNTRUSTED hop +- **Sender domains**: `Return-Path`, `From`, `Reply-To` where it differs +- **Href domains and full URLs** from HTML and text parts, decoded, redacted + per the rule above, never fetched +- **Redirect chains** as DECLARED in headers and href text, never followed +- **Auth results**: `Authentication-Results`, and the SPF/DKIM/DMARC verdicts + as the receiving server recorded them +- **Attachment filenames and SHA-256 hashes**, since a hash is reportable and + a filename is an indicator + +Never captured: recipients, the user's Message-IDs, maildir paths, account +keys. + +### Two traps, which is where this kind of parser goes wrong + +**The `Received` chain is attacker-controlled below the user's own +infrastructure.** Headers can be forged wholesale, and only the hops the +user's own MTA added are trustworthy. Without a configured trusted-relay +boundary, the "sending IP" is whatever the attacker chose to write. The +boundary is config; IOCs below it are marked `untrusted-hop` rather than +presented as fact. + +**Never resolve and never fetch.** Not the URLs, not the redirects, not remote +images. Following a link confirms the address is live to the sender and fires +exactly the tracker the message wanted. This is a parser over bytes, and that +is a safety property rather than a performance choice. + +## The qtmaildir half + +Specified in item 194 and built after 187 and 190, which settle what Mark spam +does and put it on the message bar. It is a review dialog over the case +directory: show the bodies, allow editing, show what could not be resolved, +and call `submit` on approval, then show per-destination results with a retry +for the failures. Sized M in the backlog, not the S a plain button would be: +a review dialog is real UI, and the user asked for the review to happen in the +application rather than in an editor. + +The wire contract is this document's manifest plus the `abusectl` command name +in qtmaildir's config, in the shape `[sync] command` and the per-account +`send_command` already use. + +## What each later spec has to settle + +- **`contacts`**: RDAP bootstrap and referral chasing, caching policy, rate + limits, and what happens for a netblock that publishes no abuse contact. +- **`report`**: the X-ARF (RFC 5965) schema version, which fields the user's + reporting identity fills, and the plain-text alternative for desks that do + not parse X-ARF. +- **`submit`**: per-vendor auth and payload shapes, MISP event structure + (one event per case, or per campaign, and how the dedup query decides), + and how mail to an abuse desk is sent, which most likely reuses qtmaildir's + own `send_command` rather than adding an SMTP client. +- **The qtmaildir dialog**: its own item, after 187 and 190. |