[boomlinde]

Just respect "unsubscribe" as the subject of a mail as a request to unsubscribe. Add a List-Unsubscribe header with a mailto link, like

    List-Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>

as per RFC-2369 and use the same mailto link inside the mail body. This is convenient, conventional and solves the problem you describe, while also allowing users to add feedback as they see fit in the body.

I don't see why you have to involve the web at all, but I can tell you that if I have to go through a bunch of bullshit when I want to unsubscribe I'll just mark it as spam instead. However appreciated and anticipated your newsletter is, you have to consider that most newsletter subscriptions are probably either accidental (failed to uncheck some box when signing up for something entirely different) or straight up unsolicited, and people like me will basically purge all their subscriptions without discrimination regularly as the crap builds up.

[zbentley]

> I don't see why you have to involve the web at all

Because List-Unsubscribe is very new and not supported by all email clients or ISPs (inbox service providers). Since adoption is so spotty, most ESPs (email service providers) start from a baseline of a web unsubscribe system and (maybe) supplement that with List-Unsubscribe as well.

This situation will likely improve over time.

[boomlinde]

RFC2369 from 1998 is "very new"? Funny. I guess it's either a matter of perspective.

Adoption of it doesn't matter insofar that you can use the same link in the body as a fallback, which was part of my suggestion.

"ESPs" don't care because cumbersome and convoluted multi-step unsubscribe is a selling point for the majority of people who use such systems. They have moved from simple mail based unsubscribe which was the norm for years.