Dennis Putnam wrote:
>
>Thanks for all this effort. I chose MailList.patch2.txt. Unfortunately I
>did get errors:
>
>patching file ./MailList.py
>Hunk #1 FAILED at 75.
>Hunk #2 FAILED at 190.
>2 out of 2 hunks FAILED -- saving rejects to file ./MailList.py.rej
>
>Note that there is no file ./MailLi
Thanks for all this effort. I chose MailList.patch2.txt. Unfortunately I
did get errors:
patching file ./MailList.py
Hunk #1 FAILED at 75.
Hunk #2 FAILED at 190.
2 out of 2 hunks FAILED -- saving rejects to file ./MailList.py.rej
Note that there is no file ./MailList.py.rej. All I changed
(intent
Dennis Putnam wrote:
>
>Mark Sapiro wrote:
>> The attached MailList.patch.txt patch (with an appropriate value for
>> MAGIC_LENGTH) or something like it should do what you want for the
>> -request address.
>>
>> The attached MailList.patch2.txt patch is a slight modification that
>> handles substit
Mark Sapiro wrote:
> The attached MailList.patch.txt patch (with an appropriate value for
> MAGIC_LENGTH) or something like it should do what you want for the
> -request address.
>
> The attached MailList.patch2.txt patch is a slight modification that
> handles substituting listabc for list-abcdef
Dennis Putnam wrote:
>The MTA that delivers to mailman is postfix but as I said above, the
>issue is that I have to use fetchmail. As far as mailman is concerned it
>is indeed going to list-request so the actual address used by list
>members is transparent to mailman. That is why I need to munge t
Mark Sapiro wrote:
> Dennis Putnam wrote:
>
>
> The implication is exactly what I said above. The aditional implication
> is that a reply which is addressed to
> [EMAIL PROTECTED] has to be delivered the same as
> if it were addressed to [EMAIL PROTECTED]
>
Then that won't work either.
>
> Si
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: [EMAIL PROTECTED]
>>
>> with
>>
>> Subject
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: [EMAIL PROTECTED]
>
> with
>
> Subject: confirm xx...
>
Dennis Putnam wrote:
>
> OK, to be clear the problem is one of mailbox name length. Another
> list member replied privately and questioned that so I will repost
> that information here.
>
> The number characters in my list name plus the '-request' is 6
> characters too many. I could change the li
Thanks for the reply.
OK, to be clear the problem is one of mailbox name length. Another list
member replied privately and questioned that so I will repost that
information here.
The number characters in my list name plus the '-request' is 6 characters too
many. I could change the list names but
Dennis Putnam wrote;
>
>I am having a problem getting the reply-to header configured for
>confirmations. Due to some email restrictions from my ISP I cannot use
>the default (i.e. [EMAIL PROTECTED]). Thus when a user
>tries to reply to a confirmation, it bounces (it needs to be
>[EMAIL PROTECTED]).
I am having a problem getting the reply-to header configured for
confirmations. Due to some email restrictions from my ISP I cannot use
the default (i.e. [EMAIL PROTECTED]). Thus when a user
tries to reply to a confirmation, it bounces (it needs to be
[EMAIL PROTECTED]).I can't find this in the doc
12 matches
Mail list logo
