Mark Sapiro ha scritto:
Manlio Perillo wrote:
As a response to the set show command, I obtain:
delivery off (a causa degli errori il Wed, 12 Apr 2006 01:21:46 -)
cause of errors on
I've tried to send a delivery on command, but this seems not to work.
What's the problem?
On Thu, 2006-04-27 at 22:46 -0500, Brad Knowles wrote:
If the previous value of the Sender: field is being lost, then
that should be corrected. At the very least, the value should be
saved in an Old-Sender: or Previous-Sender: or some other
suitable renamed sender field.
Probably
Manlio Perillo wrote:
But I do this later, without effects.
Do you get any reply at all to your email?
Maybe I have to unsubscribe/subscribe?
Can you visit your options page on the web and set delivery on there?
--
Mark Sapiro [EMAIL PROTECTED] The highway is for gamblers,
San
Mark Sapiro ha scritto:
Manlio Perillo wrote:
But I do this later, without effects.
Do you get any reply at all to your email?
Yes:
- Risultati:
Impostata opzione delivery
- Finito.
- Results:
delivery option set
- End.
But a later set show gave always delivery off.
I apologize if this has been asked before, but I have googled day in and day
out so, if you could point me in the right direction:
All digests include the email information for each email such as:
Message: 1
Date: Tue, 25 Apr 2006 09:57:37 -0400
From: Apache [EMAIL
Manlio Perillo wrote:
But a later set show gave always delivery off.
snip
I still don't understand the problem.
Mailman tried to send a response to my (ISP) MTA and failed?
Maybe these are related. What are the bounce settings for the list?
Does disable occur on the first bounce? Berhaps the
Louis M. wrote:
All digests include the email information for each email such as:
snip
Where can I go to remove it. Even if it is a global change.
see the mm_cfg.py options MIME_DIGEST_KEEP_HEADERS and
PLAIN_DIGEST_KEEP_HEADERS (described in Defaults.py).
--
Mark Sapiro [EMAIL PROTECTED]
On 4/28/06 6:06 AM, Barry Warsaw [EMAIL PROTECTED] wrote:
On Thu, 2006-04-27 at 22:46 -0500, Brad Knowles wrote:
If the previous value of the Sender: field is being lost, then
that should be corrected. At the very least, the value should be
saved in an Old-Sender: or Previous-Sender: or
At 12:04 PM -0400 2006-04-28, Barry Warsaw wrote:
That's fine. I'm not going to worry about changing that, since at some
point the FAQ should be moved to the new Wiki. (Any volunteers?)
The current FAQ Wizard has the advantage of simplicity and
tracking all previous changes (in
On Fri, 2006-04-28 at 12:37 -0500, Brad Knowles wrote:
The current FAQ Wizard has the advantage of simplicity and
tracking all previous changes (in case things need to be rolled
back). Wikis, by their nature, are considerably more complex and at
least some of them don't track
John W. Baxter wrote:
Probably, indeed. But what happens if that header was already taken in
the process that brought the message to mailman for distribution to the
list?
As I noted in my previous response, I believe that the correct field (if
Mailman were to add a Sender: header) to add
Don't forget to consider things like SPF, which I think uses the sender field.
Whatever is used for
SPF _must_ be the domain of the mailman box, or you're gonna run into a pack of
trouble.
...Trouble similar to a current problem I am having with AOL: they are bouncing
all email with the
On 2006-04-27 at 22:46-05 Brad Knowles [EMAIL PROTECTED] wrote:
At 10:40 AM -0500 2006-04-27, Neal Groothuis wrote:
Again from RFC 2822 3.6.2, the Sender: header should contain the
address of the agent responsible for transmitting the message,
meaning that a person who sends mail to the
Dallas Bethune wrote:
For our uses just
changing that list-bounces address to something less ominous looking
would help.
It definitely looks to me as if something needs to be done. I think
perhaps offering 3 options either to the list admin on a per-list
basis with a site default or just a
Christopher Adams wrote:
I am doing the install as a member of the Mailman group.
I have made sure that the installation directory can be written to by that
group.
I have run 'configure' and 'make' successfullly.
When I run 'make install', I get the following:
[EMAIL PROTECTED]
Now that I have a few minutes to breath ;) I'll try to summarize my
thoughts on this, and then perhaps go back later and follow up to
specific points later in the thread.
I'm sympathetic to ripping out the Sender: field munging. It was always
primarily a workaround for buggy MTAs. If the
On Fri, 2006-04-28 at 13:05 -0500, Neal Groothuis wrote:
As I noted in my previous response, I believe that the correct field (if
Mailman were to add a Sender: header) to add would be Resent-Sender.
Please see RFC 2822, section 3.6.6.
Whatever else we decide, I don't agree, or at least,
On Fri, 2006-04-28 at 14:08 -0400, Bob [EMAIL PROTECTED] wrote:
...Trouble similar to a current problem I am having with AOL: they are
bouncing all email with the
FROM: address of a specific AOL user, when mailman delivers the
messages to -any- aol or cs.com
address.
Have you tried
At 7:50 PM -0400 2006-04-28, Barry Warsaw wrote:
On Fri, 2006-04-28 at 13:05 -0500, Neal Groothuis wrote:
As I noted in my previous response, I believe that the correct field (if
Mailman were to add a Sender: header) to add would be Resent-Sender.
Please see RFC 2822, section 3.6.6.
I am hosting a list (running on 2.1.7) that is missing unsubscription requests
on the 'admindb' page.
The list is configured to have moderated unsubscription requests, so people
don't have to confirm their unsubscriptions, which seems to cause a lot of
problems.
I know the unsubscription
Edward Muller wrote:
I know the unsubscription request was made because:
a) they show up in the 'vette' log
b) Some people are sending angry emails to the return address of the list.
a) is good evidence. As far as b) is concerned, can people who can't
deal with an unsubscribe confirmation be
21 matches
Mail list logo
