Changes for version 0.07 - 2026-03-30
- Bug fixes
- Added Route 7 to abuse_contacts(): reply addresses found in the message body are now looked up in the provider table and generate abuse contacts. This catches a common advance-fee and investment scam pattern where the From: and Return-Path: headers use a spoofed or compromised address (the innocent victim of the fraud), while the real contact address -- a free webmail account chosen by the spammer -- is mentioned explicitly in the body text, e.g. "contact profcindyinvestments@hotmail.com for details". The %TRUSTED_DOMAINS filter is intentionally bypassed for this route: being hosted on a trusted provider (Hotmail, Gmail) is what makes these addresses actionable, since the spammer chose free webmail precisely because it is accessible and anonymous. Recipient domains (To:, Cc:) are still excluded. Only domains present in %PROVIDER_ABUSE generate contacts via this route; unknown domains in the body are ignored. The role string includes the specific address found, e.g. "Reply address in body (profcindyinvestments@hotmail.com)", so the abuse desk knows exactly which account to investigate.
- Fixed abuse_contacts() generating registrar contacts for innocent domains that appear only in spoofable sending headers (From:, Return-Path:, Sender:). These headers are trivially forged; when a spammer uses a victim's address as the envelope sender, reporting the victim's domain registrar is both unhelpful and potentially harmful to the innocent party. The registrar contact is now suppressed when the domain's only source is one of these three headers AND the same domain does not also appear as a URL host. If the From: domain appears in a URL as well, the spammer controls it and the registrar contact is retained. Domains sourced from Reply-To:, DKIM-Signature:, List-Unsubscribe:, Message-ID:, or the message body are unaffected -- those all indicate deliberate spammer choice. Discovered via a real advance-fee spam where qwestoffice.net was spoofed as the sender but profcindyinvestments@hotmail.com was the actual reply address, causing a false report to CSC Global (registrar of qwestoffice.net).
- Fixed abuse_contacts() generating spurious account-provider contacts from SRS-rewritten Return-Path: and Sender: headers. SRS (Sender Rewriting Scheme) addresses are generated by mail forwarders to preserve SPF validity and take the form: localpart+SRS=hash=timestamp=orig-domain=orig-local@forwarder The forwarding domain is not responsible for the spam content and is a false abuse target. Route 4 of abuse_contacts() and form_contacts() now skips any addr-spec whose local part matches +SRS= or +SRS0= (case- insensitive), covering both the standard SRS0 form and the re-forwarded SRS1 variant. Discovered via a real spam message forwarded through groups.outlook.com, which was generating an unwanted "Account provider (return-path: ...@groups.outlook.com)" role and routing an abuse report to abuse@microsoft.com via the wrong route.
- Fixed false positive http_not_https risk flag and spurious Gandi abuse contacts caused by W3C namespace and DTD URLs in HTML email templates. Spam messages sent as HTML frequently contain boilerplate references such as: http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd http://www.w3.org/1999/xhtml These are injected by the ESP's HTML template engine and have no connection to the spam content. Two fixes applied: 1. Added w3.org to %TRUSTED_DOMAINS so it is filtered from the domain intelligence pipeline and does not generate abuse contacts. 2. Added a trusted-domain skip at the top of the URL check loop in risk_assessment() so that http:// references to trusted domains do not raise the http_not_https flag. The skip uses the same $bare (www-stripped) hostname already computed for the shortener check. Discovered via a Gandi autoresponse explaining that W3C receives a high volume of false positive abuse reports for this reason and maintains a FAQ at https://www.w3.org/Help/Webmaster#spam. Note: w3c.org (the consortium's secondary domain) is deliberately not added -- it rarely appears in HTML boilerplate and any w3c.org URL in a spam message would be unusual enough to warrant investigation.
Documentation
analyse a spam/phishing email and send abuse reports to all relevant parties
Modules
Analyse spam email to identify originating hosts, hosted URLs, and suspicious domains