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
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
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 for
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 substituting listabc
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
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
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 list
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...
and
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: confirm
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.
Since
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
11 matches
Mail list logo
