On Thu, 30 Mar 2006, MJ Ray wrote: > > Because I believe it's not a bug but a feature. It can even help to be > > able to unsubscribe someone else who has troubles unsubscribing alone. > > Respectfully, I disagree. This bug is making the PTS > unreliable for co-maintainers.
Several persons complained of the *risk* but you're the first one who tells us that he has been unsubscribed by someone with malicious intent. > > And it's your problem if you don't read carefully the mail that you > > received at your own address (IIRC, they have no special PTS like header > > and thus shouldn't be filtered out from normal e-mail). > > They have an attacker-specified subject line and can be loaded > with content after the stop command, to trigger spam traps. > If you expect users to flag up these messages, how can they > spot them? I'll include a patch which changes the subject to "Unsubscription notice" or something similar. > > BTW, right now we have no other tool to unsubscribe people (even people > > whose email doesn't work anymore) so if you want this feature to be > > implemented you probably should work to solve the other related problems > > before. :-) > > Which other related problems, please? The fact that I'm using the mail interface to unsubscribe email which are bouncing ? and that I couldn't do that anymore if a confirmation was requested ... The best solution would be be to implement the bounce handler (with VERP-like headers) but an intermediary solution would be to extract the unsubscription code into a stand-alone perl script that I can call on master directly. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
