diff options
| author | Danilo M. <danix@danix.xyz> | 2026-09-08 13:24:57 +0200 |
|---|---|---|
| committer | Danilo M. <danix@danix.xyz> | 2026-09-08 13:24:57 +0200 |
| commit | 30d2fe0b495405cbecb3b544fd6c49cb6a32eebb (patch) | |
| tree | 09a8fa835279ebaa8256d8bee5b41adeb9757d62 /tests/fixtures | |
| parent | e65e598f4fbdcdfdd0b837abe3c794862f66a3e6 (diff) | |
| download | abusectl-30d2fe0b495405cbecb3b544fd6c49cb6a32eebb.tar.gz abusectl-30d2fe0b495405cbecb3b544fd6c49cb6a32eebb.zip | |
plan: take the provider ranges from SPF, not from memory
Every range in the first draft was wrong. They had been written from
memory, and the correct source is each provider's own SPF record, which
is the list of addresses it declares it sends from.
Gmail is the clearest case: the table claimed eleven IPv4 ranges and
_spf.google.com publishes two. Fastmail, Proton and the rest were wrong
in the same way. Outlook and Zoho are added since they were queried
anyway, and the transcription commands are recorded in a comment so the
next check is a copy-paste rather than a search.
Google's goog.json is deliberately NOT the source, though it looks like
one: it lists all Google infrastructure, over a hundred ranges, and using
it would trust every Google-hosted service as part of the user's own mail
path. _spf.google.com is the mail-sending answer.
The table is IPv4 only. An IPv6 hop from one of these providers does not
match and the user is asked instead, which is the safe direction: a hop
wrongly trusted means the real sender is never reported.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KphFXTc2QajxXsHWyvGJ4R
Diffstat (limited to 'tests/fixtures')
0 files changed, 0 insertions, 0 deletions
