We Asked a Bird-List Keeper How Somebody Else's Spoonbill Got Her Members Unsubscribed

Moira Twitchett has run the Saltmarsh Rarities mailing list since the days when news of a rare bird travelled faster by email than by gossip in the car park. She is also imaginary, assembled from IETF archives, Mailman documentation and one exasperated cPanel support thread. She regards this as a professional advantage. "No inbox," she says. "Nothing to bounce."

We meet in a bird hide on an equally fictional estuary. It is a wooden shed with a letterbox slot facing the water. She has brought a thermos, binoculars and a ring binder labelled in marker SPRING 2014. DO NOT. Whatever came next has been torn away.

The binder holds a small story. By April 7, 2014, Yahoo had published a DMARC policy of "reject." DMARC is a short public notice a domain posts about its own mail. Yahoo's said, in effect, if a message claims to come from a Yahoo address and can't prove it, refuse it.¹² AOL changed its policy on April 22.³ Mailing lists take one member's message and redistribute it to everyone else, and they often couldn't offer that proof.

The strange part was who paid for it. Often it wasn't the person who posted.

Email's founding documents made room for middlemen like Moira. This May, twelve years after her bad spring, a revised DMARC standard was published. It still leaves receivers with a judgment call.

Start before the trouble. How did the original mail design see a list like yours?

Moira: As an expected guest, which people forget. Jon Postel's 1982 SMTP spec calls relaying an important capability. A receiving server may act as an intermediary, and the spec lays out procedures for forwarding and for expanding mailing lists.⁴ The message-format spec from that same August has a Sender field for when the person transmitting isn't the author. It also suggests Reply-To for discussion groups, so replies go back to the group.⁵

Nobody in 1982 was specifying subject tags or unsubscribe footers, mind. But a middleman standing between you and the author was part of the furniture. There was a chair with our name on it. Possibly a cushion.

When did you realise something was wrong?

Moira: Later than I'd like. Mailman doesn't throw you out over one bounce. It keeps score, like a cricket umpire with a long memory. A hard failure adds one and a soft failure adds a half, and the score can rise only once a day, however many messages bounce.⁶ Cross the threshold and your delivery is disabled. Warnings follow, and eventually removal.⁶

Patient, which is lovely in theory. In practice the damage built up on a calendar, at roughly the speed of a heron deciding whether to strike. A bounce on Monday, another on Wednesday, and nobody notices a thing, because nothing visible has happened yet.

It did send notices. "Your membership has been disabled." A couple of members told me afterwards they'd assumed it was a scam. In fairness to them, that sentence usually is.

What I actually noticed was silence. Someone posts a spoonbill and the usual flurry of replies never comes. On a birding list, that's like announcing free cake and hearing nothing but the wind.

Here's the part that sounds invented. The person whose post caused the bounce wasn't necessarily the one who lost their membership?

Moira: Took me ages to believe it too. Let me do it with birds.

A member with a Yahoo address posts: Spoonbill, north pools, 7 a.m. Her From line says Yahoo. My list does what lists do. It stitches [Saltmarsh] onto the subject, tacks an unsubscribe footer on the bottom and sends the lot to everyone from my server, with the list's own bounce address on the envelope.¹

At the receiving end, DMARC looks at that visible From line. It wants an SPF or DKIM pass that lines up with the author's domain.⁷ SPF vouches for the server that sent the message. DKIM is a cryptographic seal on the message itself. My server passes SPF, but for my domain. Right check, wrong bird. And her Yahoo DKIM seal broke the moment I touched the subject and added the footer.⁸ So the receiver sees a message claiming to be from Yahoo that can't prove it. Yahoo's policy says reject. Out it goes.

Now, whose address gets the failure? The recipient's. Picture a retired schoolteacher on another big provider who has never posted in his life. He just reads, like a well-behaved lurker. His score ticks up.⁶⁸

That makes four parties: the author, the domain that published the policy, the provider that refused delivery and the subscriber whose score rose.¹⁸ None of them did anything... well, I won't say wrong. None of them did anything unusual.

John Levine described exactly this on the IETF list on April 7. On his church list, one Yahoo member's post drew rejections from several providers, Yahoo included.¹ Yahoo, refusing a Yahoo user's message, on Yahoo's own instructions. I laughed. Then I went and checked my bounce scores.

Was Yahoo wrong to do it?

Moira: I wanted it to be. It would have been so much tidier. Yahoo told PCWorld it was experimenting with protection against phishing and spoofing.² AOL said it had seen more spam using spoofed AOL addresses, and that its investigation involved unauthorised access to user information, address-book contacts included.⁹ If someone is using your name to con your aunt, you'd want a lock on the door too.

What stings is that AOL's own FAQ calls sending through other servers a common, legitimate practice for mailing lists.⁹ They knew perfectly well we were standing behind that door.

And the lock had limits. When DMARC became an RFC the following year, it said plainly that it didn't cover lookalike domains or misleading display names.⁷ A fraudster could still sign himself "Yahoo Support" from some other domain entirely. Meanwhile my spoonbill was turned away at the gate.

So what did you do?

Moira: I chose what to break. Mailman's own developers said every mitigation disrupted expectations or degraded something.¹⁰ It was a menu where every dish came with a side of regret:

• Rewrite From to the list's address, keep her name and put her real address in Reply-To.¹⁰ Mail got delivered. Replying stopped working the way people expected.
• Wrap her message as an attachment inside a list message.¹⁰ Some mail programs made a proper hash of displaying it.¹¹
• Touch nothing. Drop the subject tag and the footer so her signature survives.¹¹
• Refuse Yahoo posters and ask them to get another address.¹¹ Very welcoming. Very birdwatcher.
• Switch off bounce processing.¹¹ Members keep their seats. They still miss the spoonbill.¹¹

The first one is the one that bothers me. In 1982 there was a field built for exactly this: Sender, meaning I carried it, she wrote it.⁵ To get her message delivered in 2014, I had to put my list's address in From, the author line.

Couldn't you just upgrade?

Moira: (snorts into the thermos) I was on shared hosting, dear. Mailman 2.1.18 came out on May 3 with more DMARC options, and its policy lookup needed a separate library called dnspython.¹² I didn't choose my Mailman version. My host did, through its release channel. In mid-April, cPanel staff said there was no date yet for the fix to reach the stable channel.¹³ And in earlier versions, a site administrator had to switch on From-rewriting before a list owner could use it at all.¹¹ One man on that thread wrote that he simply lacked the privileges.¹³

I had the keys to the list. Not to the building.

Another list owner, Tim Wegner, made his list anonymous while he waited on his host, and asked people to sign their posts in the body of the message.¹⁴ Like postcards. Wish you were here, signed, someone.

Did anyone see this coming?

Moira: Yes. In writing. In 2011.¹⁵

(She taps a highlighted page. It is RFC 6377, which describes an earlier signing-policy mechanism and one subscriber's post getting another subscriber removed. The highlighter has nearly gone through the paper.)

This May, RFC 9989 described your problem again, in section 7.4. Does that feel like vindication?

Moira: Hang on, I've flagged it... right. Receivers MUST NOT reject a message solely because a domain publishes p=reject. They have to weigh the policy alongside other knowledge and analysis, and without that they should treat failing mail as quarantine.¹⁶ And domains whose users might post to lists SHOULD NOT publish reject at all.¹⁶ I'd frame that and hang it in the hide.

For the uninitiated, in standards language MUST NOT is a rule. SHOULD NOT is a strong suggestion you may ignore if you're prepared to explain yourself.

Section 5.4 admits that bending the rules for interoperability can let more abusive mail in.¹⁶ It also says SHOULD NOT where sections 7.4 and 8 say MUST NOT,¹⁶ which I'd guess means somebody argued about it for a very long time. And it still calls sender rewriting the established workaround.¹⁶ So the middleman is still bending the From line. Now there's a standard that admits it.

The old spec already let receivers use their own judgment.⁷ Twelve years on, they're obliged to. Whether anyone actually does is another matter. A specification isn't a delivery receipt.

What didn't come back?

Moira: The messages. Re-enabling someone's membership doesn't refill their inbox. You get your seat back in the hide, and the bird's gone.

I don't know how many people just... drifted off. I never counted. I'm not sure I could have.

(She lifts the binoculars, then lowers them.)

The spoonbill was gorgeous, apparently.

Footnotes

1. John Levine, IETF discussion-list message, April 7, 2014. https://mailarchive.ietf.org/arch/msg/ietf/J-IsfA0Lb-6T_NeMD1ENKZyb9tA/ ↩ ↩² ↩³ ↩⁴

2. Lucian Constantin, "Yahoo email anti-spoofing policy breaks mailing lists," PCWorld, April 8, 2014 (updated April 9). https://www.pcworld.com/article/444768/yahoo-email-antispoofing-policy-breaks-mailing-lists.html ↩ ↩²

3. Salvador Rodriguez, "AOL changes email policies to thwart spam from spoof accounts," Los Angeles Times, April 22, 2014. https://www.latimes.com/business/technology/la-fi-tn-aol-email-policies-spam-spoof-accounts-20140422-story.html ↩

4. Jonathan Postel, RFC 821: Simple Mail Transfer Protocol, August 1982. https://www.rfc-editor.org/rfc/rfc821.html ↩

5. David H. Crocker, RFC 822: Standard for the Format of ARPA Internet Text Messages, August 1982, §4.4. https://www.rfc-editor.org/rfc/rfc822.html ↩ ↩²

6. GNU Mailman 2.1, List Administration Manual: Bounce Processing (documentation updated 2019). https://www.list.org/mailman-admin/node25.html ↩ ↩² ↩³

7. RFC 7489: DMARC, March 2015 (now superseded). https://www.rfc-editor.org/rfc/rfc7489.html ↩ ↩² ↩³

8. RFC 7960: Interoperability Issues between DMARC and Indirect Email Flows, September 2016. https://www.rfc-editor.org/rfc/rfc7960.html ↩ ↩² ↩³

9. AOL incident and spoofing FAQ, 2014. https://s.aolcdn.com/os/memberservices/faq.html ↩ ↩²

10. GNU Mailman, "Mailman and DMARC." https://wiki.list.org/DEV/DMARC ↩ ↩² ↩³

11. GNU Mailman FAQ on Yahoo-policy bounces and automatic unsubscription. https://wiki.list.org/DOC/What%20can%20I%20do%20about%20members%20being%20unsubscribed%20by%20bounces%20of%20Yahoo%20user%27s%20posts%20for%20DMARC%20policy%20reasons%3F ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

12. Mark Sapiro, Mailman 2.1.18 final release announcement, May 3, 2014. https://mail.python.org/pipermail/mailman-announce/2014-May/000193.html ↩

13. "Yahoo's new DMARC policy causing Mailman bounces," cPanel community thread, April–May 2014. https://support.cpanel.net/hc/en-us/community/posts/19626400792471-Yahoo-s-new-DMARC-policy-causing-Mailman-bounces ↩ ↩²

14. Tim Wegner, "Proposed temporary fix for list problems," May 21, 2014. https://lists.wedgeblade.net/archives/list/dialogue%40lists.wedgeblade.net/thread/AO7BYUHZMYZAKYCJXW3VG6XJ35MDT7RM/ ↩

15. RFC 6377: DomainKeys Identified Mail and Mailing Lists, September 2011, §5.2. https://www.rfc-editor.org/rfc/rfc6377.html ↩

16. RFC 9989: DMARC, May 2026, §§5.4, 7.4, 8. https://www.rfc-editor.org/rfc/rfc9989.html ↩ ↩² ↩³ ↩⁴ ↩⁵