in emails, unsubscribe links should not react to HTTP HEAD requests

[Stephane Martin]

Welcome emails from mailman include a URL to perform unsubscribing.

ex: https://lists.schneier.com/cgi-bin/mailman/options/crypto-gram/XXX%40XXX?login-unsub=Unsubscribe

If you perform a HTTP HEAD request on that URL, it triggers the unsubscribe process, and an unsubscribe confirmation email is sent to the user.

This shouldnt happen: HTTP HEAD method is not HTTP GET. Its supposed to only return headers, not to trigger an action on web server.

I have anti-malware software that checks every HTTP link in received emails. When such a link is found by antimalware, it does a HTTP HEAD request on the URL to check the mimetype (if mimetype show a windows executable, an alert is sent). But this HEAD request in understood by mailman as a *real* unsubscribe request, so mailman sends a confirmation to the actual user (who is lost).

(Strictly speaking, the behaviour is wrong even with a HTTP GET request: GET should not trigger a webserver action too...)

[Mark Sapiro (msapiro)]

There are a few issues here. First, the unsubscribe URL in your example is not sent in the standard welcome message. The standard message contains only something like

If you ever want to unsubscribe or change your options (eg, switch to or
from digest mode, change your password, etc.), visit your subscription
page at:

  http://example.com/mailman/options/user%40example.net

without the login-unsub fragment. Your installation has modified the subscribeack.txt template on a per-list, per-domain or sitewide basis to add the login-unsub fragment.

That notwithstanding, your point about a HEAD request on the URL is valid and I will fix this, but I will still allow GET. In theory this really should be only a POST from the options login page, but it is well known and widely used to put such URLs in list message headers or footers as unsubscribe links, so disallowing GET would be too disruptive.

[Stephane Martin (stephane-martin)]

good enough for me, thank you!