Subject The installer that used to be served at this path, and the mechanisms that ended the product Covers SMTP · SPF, DKIM and DMARC · CAN-SPAM · Authenticode · SmartScreen We ran it No. We hold no copy and distribute none. Sourcing Archived vendor pages · the U.S. Code · IETF RFCs · Microsoft and mailbox-provider documentation Ledger rows None — email transport sits outside the Ledger’s declared boundary Open questions 4 · §8 Published 2026-08-06 Last verified 2026-08-06

A mail delivery path drawn flat and orthographic: one sender node at the left edge, a fan of five connection lines running across the frame, and a single receiving gate at the right. The one dashed vertical boundary, at 38% of the frame width, marks **unauthenticated ↔ authenticated**. Three of the five paths stop dead at that boundary and two continue through it to the gate, which is the whole difference between a bulk sender of the archived era and a mailbox provider today. No window chrome, no interface, no lettering of any kind: every label the diagram needs is in this caption.

This URL used to be an installer

Two captures of this address in the Internet Archive return a Windows executable: 13,323,061 bytes crawled on 2011-05-15, and 12,684,681 bytes crawled on 2014-02-17. The second capture’s origin headers give a Last-Modified date of 2011-08-08, so the last build the archive holds sat unchanged on the vendor’s server for two and a half years. By 2016-03-05 the path returned 404. The product was TLN-Auto Bulk Email Sender and Search Spider: a bulk sender with an address harvester in the box.

This page is HTML, it will stay HTML, and no deploy of this site contains a file whose bytes are executable. We do not hold that installer, we will not obtain one, and we do not link the archived copy either — an archived 2011 installer is still a 2011 installer. What follows is what the product was sold as, from the vendor’s own archived pages, and the documented mechanisms that ended each thing it sold.

Tenglnet published its Windows Winset utilities at tlwinset.com from roughly 2005 to 2016. The registration lapsed, the address passed through other owners, and it came to this publication in 2026. Working Set has no connection to Tenglnet, holds no copy of its software, distributes none, and has never run any of it.

Verdict UNSAFE-CLAIM What that code means here The advertised capabilities — harvesting addresses from search engines by keyword, and raising the “success rate” of bulk sending against a receiving server — are legal claims we will not test, endorse or explain operationally. We describe what was advertised and what the documented mechanisms do. We publish no procedure. Settled separately This address serves no binary, permanently (§1). That is a property of the deploy, not a judgement.

§1This path serves HTML because the alternative is redistributing a binary nobody can vouch for

Bytes at the original path: 13,323,061 (2011-05-15 capture)
Bytes of executable we serve: 0, at this or any path, permanently
Cost of keeping the path alive: 1 _headers rule, 2 response headers

A file extension is not a file type. Static hosts derive content-type from the extension, so a path ending .exe is served as application/x-msdownload by default and a browser offers it as a download — which is what the Internet Archive’s own headers for both 2011 and 2014 captures show. One rule in _headers pins this path to text/html; charset=utf-8 and adds X-Content-Type-Options: nosniff so no client second-guesses it. That override is verified on a preview deployment before this site ships, against two conditions: the response must declare HTML, and the first two bytes of the body must not be MZ, the signature every Windows portable executable begins with.

That path exists at all because a link does. A third-party backlink index records a Russian download catalogue still pointing at the old installer address; we have not confirmed that placement ourselves and say so rather than assume it. The house rule is that a real page at a strange path beats a redirect, because a redirect answers a question nobody asked. If the header override ever stops holding, that address falls back to a 301 pointing here, to the page you are reading — same subject, same words, still no executable.

§2The archived pages give a price, a size and a licence tier, and those are the only numbers anybody has

Advertised price: $49 professional, $69 enterprise (capture 2013-11-19)
Advertised download: 12 MB, “V2011”; 5.8 MB on the 2010 predecessor
Advertised free tier: 20 messages and 20 searches a day

Two product generations are visible, and the price moves in every capture. The 2010 download page advertises TLN E-Mail Sender at $49.95 and $29.95, a 5.8 MB download, and three payment routes, one of them an advertising-offer wall that gave the software away for taking up a partner offer. The 2012 purchase page advertises a 12 MB download from three mirrors labelled Europe, America and Asia, under a payment option labelled 39$. The 2013 product page advertises the same 12 MB download as “V2011”, with a licence table: free at twenty sends and twenty searches a day, $49 for one machine, $69 for five. Three captures, three price presentations, and the only number among them we can check independently is the size — the archived file is 12,684,681 bytes, which is 12.1 MiB. Version strings taken from third-party catalogue pages are treated here as unconfirmed until they are matched against a capture of the vendor’s own page.

The harvester was not an add-on. It is in the product name, in the navigation of every page, and in the licence tiers, which meter sends and searches with one number. The advertised inputs were a keyword and a choice of search engine, or a starting URL; the advertised output was a text or spreadsheet file of addresses. That pairing — a list builder and a sender in one purchase — is the whole design, and it is what makes the legal question in §4 the interesting one.

§3Rotating accounts and per-recipient text are engineering aimed at the receiving server, not at the reader

Documented send interval: 1–5 s on a paid server; 10 s advised on a free one
Documented mutation points: 2 — subject suffix and message footer
Accounts per campaign: NOT ESTABLISHED — see §8

One archived help page carries four settings and says what each is for. Rotate several sender accounts, because a public provider may disable a single account sending in bulk. Set the sending interval — one to five seconds through a paid server, ten through a free one — because a short interval gets the account disabled. Turn on automatic subject differentiation, which appends the recipient’s name to the subject so that no two messages in a run carry the same one. Turn on automatic footer differentiation, which appends a per-recipient line to the body for the same reason. Three of the four are addressed to a machine the sender never sees. None of them changes what the recipient is being offered; all of them change what the receiving server can group.

The fourth advertised behaviour is different and deserves credit. Sending each address its own message, so that a recipient sees only their own address in the header, is now how essentially all legitimate bulk mail is delivered: it is what makes a per-recipient unsubscribe link possible at all, and RFC 8058’s one-click unsubscribe assumes it. We think the plainest reading is that one technique of the four was ordinary engineering that survived, and the other three were aimed at a classifier.

§4Address harvesting is an aggravating factor under CAN-SPAM, and not a standalone offence

Statutory damages, state action: up to $250 a message, $2,000,000 cap
Statutory damages, access provider: up to $100 or $25 a message, $1,000,000 cap
Multiplier where an aggravated violation is proven: up to 3×

The conduct section is 15 U.S.C. § 7704(a), and it has five prohibitions: materially false or misleading header information; a subject heading likely to mislead about the contents; no functioning return address or opt-out mechanism; continuing to send more than ten business days after an opt-out; and sending without clear identification as an advertisement, notice of the opt-out, and a valid physical postal address. Those are the rules a commercial message has to clear.

Subsection § 7704(b) is a different thing and is routinely described wrongly. It contains three numbered paragraphs — address harvesting and dictionary attacks, automated creation of multiple email accounts, and relay through unauthorised access — which enumerate four distinct practices if harvesting and dictionary attacks are counted separately. The structural point is in the text of each paragraph: every one of them is defined by reference to a commercial message “that is unlawful under subsection (a)”. Harvesting a list is not made unlawful on its own by this section; harvesting a list and then sending messages that break subsection (a) is. And the harvesting paragraph is narrower still than its reputation: it applies where the address was taken by automated means from a site that, at the time, carried a notice saying it would not transfer addresses.

What the aggravation buys is a multiplier. Under § 7706(f)(3) a state attorney general may recover up to $250 per message with a $2,000,000 ceiling, and under § 7706(g)(3) a provider of internet access service may recover up to $100 per message for falsified header information or up to $25 otherwise, with a $1,000,000 ceiling. Both provisions let a court treble the award where the defendant acted wilfully and knowingly, or where the unlawful activity included one or more of the violations set out in § 7704(b). One asymmetry is worth naming because it complicates the tidy version: § 7706(g)(1) lets an access provider sue on a subsection (b) violation directly, while the state-enforcement subsection does not list (b) among its triggers. We are describing a statute that names a category of feature. We are not asserting that any vendor, including this domain’s former owner, violated any law, and nothing here should be read that way.

§5Authentication moved from optional to load-bearing between that last build and now

Required of large senders: SPF pass, DKIM pass, DMARC at least p=none, alignment
Complaint ceiling: 0.30% spam rate at Gmail and at Yahoo
Rejection code at Outlook.com: 550 5.7.515, enforcement from 2025-05-05

Nothing in RFC 5321 verifies who sent a message. The envelope sender is whatever the client typed, which is why a bulk sender in 2011 could treat deliverability as a game of cadence and phrasing. Three later specifications moved the question from what does this message look like to who owns the domain it claims: RFC 7208 (SPF, April 2014, replacing the experimental 2006 specification) authorises sending hosts for a domain; RFC 6376 (DKIM, September 2011 — the same year as this file’s last build) signs headers and body with a key published in the signing domain’s DNS; and DMARC ties both to the domain a reader actually sees in the From: header. DMARC itself was informational for eleven years and became a Standards Track specification, RFC 9989, in May 2026, obsoleting RFC 7489.

The three identifiers a message carries, and the check each one feeds, divided by one dashed boundary: set by the sender ↔ checked by the receiver. The envelope sender feeds SPF; the DKIM d= tag feeds signature validation; the From: header is the one a person reads, and DMARC passes only when it aligns with a domain that already passed one of the other two. Left of the line is text a sending program chooses. Right of the line is a question about domain ownership, and no amount of rewriting the left column answers it.

Then the largest consumer mailbox providers made those specifications a condition of entry. Google requires senders of more than 5,000 messages a day to personal Gmail accounts to publish SPF and DKIM, publish DMARC at a policy of at least p=none, align the From: domain with the SPF or DKIM domain, support one-click unsubscribe on marketing mail, use TLS, and keep the spam rate reported in Postmaster Tools below 0.30% — in force since 2024-02-01. Yahoo published matching requirements from February 2024, including honouring unsubscribes within two days and the same 0.30% ceiling. Microsoft announced the same authentication floor for Outlook.com on 2025-04-02 with enforcement from 2025-05-05, routing non-compliant mail from high-volume domains to Junk, and published the rejection string it uses when it declines the message outright: 550 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.

The documentation implies the rest. A spam rate is computed from recipient complaints, so a longer sending interval does not move it. A signature covers the headers and the body, so per-recipient subject and footer text is signed either way and changes nothing about whether the message authenticates. And the thresholds are stated per sending domain, so rotating accounts underneath one domain does not lower the volume the domain is measured at, while rotating the domain forfeits the reputation the sender needs. The old techniques were answers to the question does this look like bulk. Nobody asks that question first any more.

§6A fifteen-year-old unsigned installer is an unbounded risk with a bounded reward

Cost of an expired signing certificate: 0 if the signature is timestamped; treated as unsigned if not
Cost of no file reputation: 1 SmartScreen warning, on every download
Whether this file was signed at all: NOT ESTABLISHED — see §8

Authenticode signs a binary with a certificate that expires. Microsoft’s documentation is direct about what that means: Without a time stamp, the signature becomes invalid when the signing certificate expires, and Windows will treat the binary as unsigned. A countersignature fixes the moment of signing, so a signature can be verified even after the signing certificate has expired or been revoked. The same page states that SHA-1 signatures are deprecated and distrusted by current Windows for code signing, which is a second way an old binary can be signed and still not count. So the interesting question about a 2011 installer is not whether it carried a signature. It is whether the signature was timestamped, with what algorithm, and by a timestamping authority whose chain still validates — three properties that decay independently of the file.

We cannot answer any of that for this file, because answering it would mean obtaining and parsing the binary, and we do not do that. What is documented is what Windows does with a file it does not recognise. Microsoft Defender SmartScreen checks downloads against a list of files that are well known and downloaded frequently and warns when a file is not on it; the overview states that where a URL, file, app or certificate has no established reputation, the item is marked as a higher risk and presents a warning to the user. Defender’s potentially-unwanted-application criteria name three categories by behaviour, and one of them is Evasion software that actively tries to evade detection by security products.

Our judgement, labelled as judgement: the risk of running an unmaintained system-level installer from a vendor that stopped publishing a decade ago is unbounded, because nobody — not us, not the vendor, not the catalogue that still links it — can tell you what is inside it now, and the reward is bounded at zero, because §5 describes an internet in which the product’s central capability does not function. The right number of 2011 installers to run in 2026 is none, and that conclusion needs no accusation against anyone to hold.

§7One address sold a PC utility suite and a bulk mailer, and in that trade the pairing was ordinary

Product lines on this domain: 3 — utility suite, mailer, and an unrelated vision-therapy program
Shared page furniture: 1 ICP number, 3 mirrors, 1 menu of 30+ locales
Contact addresses observed: 7 addresses on 4 mail domains

Put the mailer’s purchase page beside the Windows 8 utility page and the furniture is identical: the same three download mirrors labelled Europe, America and Asia, the same payment block, the same ICP registration number 10025419, the same language menu of more than thirty locales. The mailer’s 2013 product page lists a messaging contact of a live.cn address — the other product line’s brand, in the mailer’s contact field. Seven distinct contact addresses appear across five of the captures we fetched, on four different mail domains, and the company name in the copyright line changes between the 2010 and 2013 captures. We report the inconsistency as an inconsistency. Article 1 holds the vendor record and does not resolve it either, because it is not resolvable from the archive.

What the pairing was ordinary in is the distribution model rather than the ethics of either product. A small vendor with one website template, a thirty-language menu and a listing on hundreds of download catalogues could add a second product for the cost of a second directory, and the catalogues indexed whatever was submitted to them. That mechanism is the subject of article 12, and it explains something better than motive does: the same infrastructure that put a Windows tune-up utility on catalogue sites in nine languages put a bulk mailer there too, and neither placement was an endorsement of anything.

§8Standing, and what we could not settle

Primary sources read: 16, each dated in §9
Archive captures fetched by us: 6 pages, 2010-07-19 to 2013-11-19, plus 2 binary response headers
Corrections since publication: 0 — first publication 2026-08-06

Standing 2026-08-06 Documented Two archived captures of the binary at this path, 13,323,061 and 12,684,681 bytes, served as application/x-msdownload, with an origin Last-Modified of 2011-08-08 and a 404 at the path by 2016-03-05; the advertised prices, sizes, licence tiers and mirrors; the four settings on the archived help page; the five prohibitions of § 7704(a), the three paragraphs of § 7704(b) and each one’s dependence on a subsection (a) violation; the damages and trebling provisions of § 7706(f)(3) and (g)(3); the publication status and dates of RFC 5321, 6376, 7208, 8058 and 9989; the Gmail, Yahoo and Outlook.com sender requirements with their dates and thresholds; the Authenticode timestamping, SmartScreen and PUA documentation. Inferred That interval tuning cannot move a complaint-based spam rate, that per-recipient text mutation is irrelevant to a signature that covers the body, and that per-domain thresholds defeat account rotation — each follows from the provider requirements and the RFCs cited in §5, and from nothing else. Our judgement That three of the four archived settings were aimed at a classifier and the fourth was ordinary engineering that survived; that a 2011 system-level installer from a defunct vendor is an unbounded risk with a reward of zero; that a real page at this path serves a reader better than a redirect. Not established (1) Whether the archived binary was ever Authenticode signed, timestamped or SHA-256 signed — determining that means obtaining and parsing the file, which we will not do, so the question stays open permanently. (2) How many sender accounts the product rotated, or was expected to rotate: the archived help page advises using more without naming a number, and no capture we fetched gives one. (3) Whether the download catalogue recorded as linking this path still does — the placement comes from a third-party backlink index and we have not observed it. (4) The exact Windows release and enforcement date at which SHA-1 code signing stopped being trusted: the current Microsoft page states the deprecation but the page it points to for the enforcement history returned HTTP 404 to us on 2026-08-06, so we state the deprecation and omit the date.

§9Sources and method, with the date each was read

Primary sources: 16 — statute, RFCs, vendor and provider documentation
Archive sources: 7 entries, all fetched at their capture URLs
Sources we could not open: 1, HTTP 404 on 2026-08-06

Method, in one sentence: every number on this page was taken either from an archived capture we fetched ourselves at the URL given, or from the organisation that publishes the thing being described — the U.S. Code from the House of Representatives site, the specifications from the RFC Editor, the sender requirements from each mailbox provider, the Windows behaviour from Microsoft — and the four things we could not settle are named in §8 rather than smoothed over.

Internet Archive, CDX index and response headers for the path tlwinset.com/mail/tools/AlmsSetup.exe — two captures with HTTP 200 and mimetype application/x-msdownload (2011-05-15, 2014-02-17), a 404 at 2016-03-05. web.archive.org/cdx/search/cdx?url=tlwinset.com/mail/tools/AlmsSetup.exe. Read 2026-08-06. The binary itself is deliberately not linked.
Archived vendor product page, tlwinset.com/mail/index.htm, capture 2013-11-19 — prices, licence tiers, 12 MB figure, feature list, contacts. Fetched 2026-08-06.
Archived vendor purchase page, tlwinset.com/mail/buynow.htm, capture 2012-03-21 — the three mirror labels. Fetched 2026-08-06.
Archived vendor download page, tlwinset.com/mail/Download.htm, capture 2010-07-19 — the earlier product generation, its prices and 5.8 MB figure. Fetched 2026-08-06.
Archived vendor page, tlwinset.com/mail/spider.htm, capture 2010-07-20 — the harvester’s advertised inputs and outputs. Fetched 2026-08-06.
Archived vendor help page, tlwinset.com/mail/set.htm, capture 2010-07-20 — the four sending settings and the reason given for each. Fetched 2026-08-06.
Archived vendor page, tlwinset.com/wineb/xiazai.htm, capture 2012-01-08 — the shared page furniture, ICP number and mirror labels. Fetched 2026-08-06.
Office of the Law Revision Counsel, 15 U.S.C. § 7704. uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title15-section7704. Read 2026-08-06.
Office of the Law Revision Counsel, 15 U.S.C. § 7706. uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title15-section7706. Read 2026-08-06.
J. Klensin, Simple Mail Transfer Protocol, RFC 5321, October 2008. rfc-editor.org/rfc/rfc5321.txt. Read 2026-08-06.
D. Crocker, T. Hansen and M. Kucherawy, eds., DomainKeys Identified Mail (DKIM) Signatures, RFC 6376, September 2011. rfc-editor.org/rfc/rfc6376.txt. Read 2026-08-06.
S. Kitterman, Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1, RFC 7208, April 2014, obsoleting RFC 4408. rfc-editor.org/rfc/rfc7208.txt. Read 2026-08-06.
J. Levine and T. Herkula, Signaling One-Click Functionality for List Email Headers, RFC 8058, January 2017. rfc-editor.org/rfc/rfc8058.txt. Read 2026-08-06.
T. Herr and J. Levine, eds., Domain-Based Message Authentication, Reporting, and Conformance (DMARC), RFC 9989, Standards Track, May 2026, obsoleting RFC 7489 and RFC 9091. rfc-editor.org/rfc/rfc9989.txt. Read 2026-08-06.
Google, Email sender guidelines — requirements for senders of 5,000 or more messages a day, in force 2024-02-01. support.google.com/a/answer/81126. Read 2026-08-06. And Yahoo, Sender best practices, enforcement from February 2024. senders.yahooinc.com/best-practices/. Read 2026-08-06.
Microsoft Defender for Office 365 blog, Strengthening Email Ecosystem: Outlook’s New Requirements for High-Volume Senders, 2025-04-02, updated 2025-04-29. techcommunity.microsoft.com. Read 2026-08-06. And Microsoft, Time Stamping Authenticode Signatures, ms.date 2026-07-16 (learn.microsoft.com/en-us/windows/win32/seccrypto/time-stamping-authenticode-signatures); Microsoft Defender SmartScreen overview, ms.date 2026-04-23; and Block potentially unwanted applications with Microsoft Defender Antivirus, ms.date 2026-07-02. All read 2026-08-06.
Could not open: the Microsoft page linked from the timestamping article for the history of Windows enforcement of SHA-1 certificates returned HTTP 404 on 2026-08-06, so no enforcement date is stated here.

Previous What Windows 8 changed that broke the tweak industry — the surfaces a Vista-era tweak suite wrote to, and which release moved or removed each one.

Next Windows 10 or Linux, from both sides of the sentence — both claims checked against mechanisms rather than allegiances, with a conditional verdict and the condition named.