[Mailman-Users] Configure Repy-To header for confirmations

[Mark Sapiro]

Dennis Putnam wrote:
>
>Mark Sapiro wrote:
>> Still, if you can use VERP_CONFIRMATIONS, it would make the code
>> modifications simpler because of the way the address is generated. The
>> difference is without VERP_CONFIRMATIONS, the message is
>>
>> From: list-request at ...
>>
>> with
>>
>> Subject: confirm xxxxxxxxxxxxxxxxxx...
>>
>> and with VERP_CONFIRMATIONS it is
>>
>> >From list-confirm+xxxxxxxxxxxxxxxxxx... at ...
>>
>> with
>>
>> Subject: Your confirmation is required to ...
>>
>> Of course, if the local part suffix is included in the length
>> restriction, this only makes it worse and can't be used.
>>  
>Since I don't know what the implications of VERP_CONFIRMATIONS are, I
>have reason to not try it. :)


The implication is exactly what I said above. The aditional implication
is that a reply which is addressed to
list-confirm+xxxxxxxxxxxxxxxxxx... at ... has to be delivered the same as
if it were addressed to list-confirm at ...


>The length restriction is on the mailbox name or rather the user name
>(everything that precedes the '@').


Since Mailman doesn't use mailbox delivery, why do you have an issue
with these names at all?


>> Does the munging need to be done for all lists in the installation? Is
>> it done in the same way for each list? I.e. is list-request always
>> mapped to listreq or does the mapping vary depending on list. Can the
>> mapping be deduced programmatically, or would it have to be looked up in
>> a table?
>> 
>Actually no. There is only 1 list that otherwise exceeds this limit. The
>mapping can be deduced programmatically. It is simply the list name
>prepended to 'req' rather than prepended to '-request'.


I'm not convinced you even need to do this. How does your MTA actually
deliver to Mailman?

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan