On 19 Jan 1999 20:11:56 -0000, Russell Nelson wrote:

>Okay, VERP has solved the bounce problem.  Now we need VERB (Variable
>Envelope Recipient in Body) to solve the unsubscribe problem.
>Basically, we need qmail-remote to merge the envelope recipient into
>the message somewhere.  The problem, of course, is *where* to insert

I think the substitution idea is good, but putting it into the message
is Not Good (TM). qmail should not under any circumstances corrupt the
message, which might contain any character sequence.

Putting it into the header circumvents that problem. Also, the amount
of text that has to be parsed is limited this way. Yes, there are
disadvantages (stupid subscribers), but that's less important than
message integrity.

There is rfc2069 which describes how to put unsubscribe info into
headers. I think putting it there, maybe doing VERH expansion like VERP
-@[] or separate tokens for LOCAL and HOST? The flag controlling this
could be if VERP is used for the message.

Currently, VERP expansion is done at the level of qmail-send. VERH
expansion needs to be in qmail-remote (and really also qmail-local).
qmail-send has the info that VERP is used, so it would have to pass the
flag to qmail-{r|l}spawn to qmail-remote/local. There is no reason the
character sequence -@[] should occur in a header. Whatever the magic
token is, it should be legal in a header, since someone might use it
where VERH is not supported. 

For subscribers, you could to a message trailer add "see
List-Unsubscribe: header for info on how to unsubscribe". As Sen Nagata
pointed out on the ezmlm list, rfc2069 may not be such a bad idea, and
good MUAs will rapidly support it once it's used more. ezmlm would
support this "out of the box".


-Sincerely, Fred

(Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)

Reply via email to