--- title: Current configuration description: What is set right now, where, and why. icon: SlidersHorizontal verified: 2026-08-24 --- The state of the mail protection as it stands. Everything here is a setting someone can change in cPanel, which is exactly why the verification date above matters more than the content below. ## Account | Item | Value | |---|---| | cPanel | `https://arome.o2switch.net:2083` | | Account | `sc6mixq8738` on `arome.o2switch.net` | | Domain in scope | `advmfr.net`, 87 mailboxes | `advmfr.com` is **not** on this server: it runs on Google Workspace, and its filtering happens in Google Admin. Its DNS is a separate matter, see [the DMARC fix](/docs/it/email/log). ## Global filters Nine rules, running top to bottom on every incoming message. Managed in [Global Email Filters](/docs/it/email/global-email-filters). The first five are conditional whitelists (`Stop Processing Rules`: a match skips everything below); the last four deliver to the same `/.Quarantine` folder and none stops the others, so a single message can match several. | # | Filter | Condition | Effect | |---|---|---|---| | 1 | `00-wl-advmfr-com` | From contains `@advmfr.com` **and** Spam Status contains `SPF_PASS` | genuine Google-side company mail skips all rules | | 2 | `01-wl-advance-manufacturers` | From contains `advance.manufacturers@gmail.com` **and** `SPF_PASS` | company Gmail, skips all rules | | 3 | `02-wl-export-advmfr` | From contains `export.advmfr@gmail.com` **and** `SPF_PASS` | company Gmail, skips all rules | | 4 | `03-wl-jiraporn-advmfr` | From contains `jiraporn.advmfr@gmail.com` **and** `SPF_PASS` | company Gmail, skips all rules | | 5 | `04-wl-purchase-advmfr` | From contains `purchase.advmfr@gmail.com` **and** `SPF_PASS` | company Gmail, skips all rules | | 6 | `Executables & scripts` | Body matches regex | attachment filenames ending in an executable extension → Quarantine | | 7 | `EXEC` | Body matches regex | attachment filenames ending in a macro-capable Office extension → Quarantine | | 8 | `10-quarantine-score10` | Spam Bar contains `++++++++++` | spam score 10 or above → Quarantine | | 9 | `30-self-spoof` | From contains `@advmfr.net` **and** Spam Status contains `SPF_SOFTFAIL` | mail claiming to come from us that our own SPF record does not authorise → Quarantine | The whitelists are conditional on `SPF_PASS` on purpose: while advmfr.com's DMARC is still broken, a plain From whitelist would be an open door. A forgery without `SPF_PASS` falls through to rules 6-9 (verified by filter trace, 2026-08-24). The trade-offs of whitelisting are in the [action plan](/docs/it/email/action-plan). ### What the attachment rules actually match The question people ask is "would this file have been caught?", so here are the exact extension lists rather than a summary. **Rule 1, executables and scripts:** ```text exe scr pif com bat cmd cpl msi msp hta jar js jse vbs vbe wsf wsh ps1 reg lnk url iso img vhd dll sys ade adp chm inf ins isp mst sct shb vb vxd apk deb dmg ``` **Rule 2, macro-capable documents:** ```text docm dotm xlsm xltm xlam pptm potm ppam sldm xls xll slk iqy ``` Three entries in that second list matter because nothing about them looks dangerous. `xls` is the old binary Excel format, which carries macros without the `m` suffix that marks the modern ones. `slk` and `iqy` are Excel formats that execute on open without containing a macro at all. Both are a known way around exactly this kind of filter. Both rules match on the **body**, against the `name=` or `filename=` parameter of a MIME part. That is why the score rule matters alongside them: a body match is blind to an attachment the sender has encoded, which is [what the baseline audit found](/docs/it/email/log/2026-08-14-audit-phase0) about the filters that preceded these. ### Rule 4 depends on the SPF record `30-self-spoof` catches messages claiming to be from `@advmfr.net` that our own SPF record does not authorise. That is the shape of a supplier-invoice fraud, and the reason the [watchlist](/docs/it/email/suspicious-indicators) exists. It matches on `SPF_SOFTFAIL`. That is a dependency. The SPF record ends in `~all`, which means softfail. **Hardening it to `-all` would make unauthorised mail produce `SPF_FAIL` instead, and this rule would stop matching anything at all**, silently. The audit lists that hardening as a possible future step; whoever takes it must change this rule in the same breath. ### Still planned `00-whitelist-critical` in position 1, so that protected senders skip every other rule. Not in place: it is waiting on the list of critical senders. Position 1 decides whether it works: a whitelist placed anywhere else runs after the rules it exists to override. ### Not yet graduated Rule 3 was to switch from quarantine to permanent deletion after seven consecutive days with zero false positives, at the earliest on 21 August 2026. It has not switched. It still delivers to the folder. ## DNS authentication (SPF: DKIM, DMARC) The three records that let the world verify mail claiming to be `advmfr.net`. They live in the cPanel Zone Editor (the zone is hosted at o2switch, `ns1/ns2.o2switch.net`). | Record | Current value | State | |---|---|---| | SPF (`TXT` on `advmfr.net`) | `v=spf1 ip4:109.234.162.168 +a +mx +include:spf.jabatus.fr ~all` | `~all` = softfail. Hardening to `-all` is planned, see the warning below | | DKIM (`default._domainkey`) | 2048-bit RSA key, signing active on all outbound | ✅ | | DMARC (`_dmarc`) | `v=DMARC1; p=none; rua=mailto:dmarc@advmfr.net` (cPanel adds explicit defaults) | Observation phase. Hardening ladder: `p=quarantine` pct 25/50/100 → `p=reject`, one step per week, each step gated on the weekly digest showing ≥ 98% alignment | **The SPF/filter dependency, spelled out once more:** rule 4 matches `SPF_SOFTFAIL`, which exists *because* the record ends in `~all`. The day SPF becomes `-all`, forgeries produce `SPF_FAIL` instead. The hardening therefore ships together with a companion rule matching `SPF_FAIL`, never alone. The step-by-step is in the [action plan](/docs/it/email/action-plan). ## Quarantine One folder for the whole account, on the system account `sc6mixq8738`. Catching traffic since 2026-08-17. Nothing is deleted from it automatically during the observation phase. Access path in [Quarantine folder](/docs/it/email/quarantine-folder). ## Outbound limit **180 outgoing emails per hour, shared by the entire domain.** Above the limit, mail is first delayed, then destroyed: not bounced, destroyed. The practical consequence is a rule, not a setting: **no bulk mailing from any `@advmfr.net` mailbox, ever.** Company-wide sends go through the Google side (`advmfr.com`), for example a Google Group holding staff personal addresses. This limit is what caused the incident of 17 August. ## DMARC reporting `dmarc@advmfr.net` receives the automatic XML reports from Google, Microsoft and others about who sends mail claiming to be `advmfr.net`. Nobody reads it by hand; a local script digests it weekly. Do not empty it, do not reply to anything in it, and never put it on a whitelist. ## Layers that are not ours Two other filters act on this mail and are unchanged by any of the above: - **The o2switch upstream layer** rejects extreme-scoring mail at SMTP time, before it reaches the account. - **Per-mailbox Spam/Junk folders**, filled by the o2switch antispam, independent of the global filters. Confusing one of these with a global filter is the most common way to misdiagnose a delivery problem.