I want all mails sent to the list to come from the list's email address...
But, in this case, if the user forgets to sign their name at the
bottom of their mail body, effectively the mail to the list is
anonymous...!
Is there a way to add the user name (or email address) to the top of
each mail so that the mails have the name of the sender, while the
mail itself comes from the list address?
I have looked high and low for an answer, but noone seems to have the solution.
Thank you!
Mal
Hi,
I received the following error this morning. So I rerun configure again with the following command: ./configure --with-cgi-id=apache --prefix=/var/mailman. I'm still getting the same error. Is there any place that I can look for so that I can debug this problem better? Perhaps, looking at the config history file or something. Any other places that I can check the cause of this error?
"Mailman CGI error!!!
The Mailman CGI wrapper encountered a fatal error. This entry is being stored in your syslog:
Group mismatch error. Mailman expected the CGI
wrapper script to be executed as group "nobody", but
the system's web server executed the CGI script as
group "apache". Try tweaking the web server to run the
script as group "nobody", or re-run configure,
providing the command line option `--with-cgi-gid=apache'."
Thanks
Mary
Hello,
I have old mail server (rabbit.mydomain.com) and new mail server (newbie.mydomain.com). I need to migrate mailman from old to new server.
I used the instructions found in this mailing list:
1. Copied all of /var/lib/mailman/lists/ from the old server to the new
one.
2. Fixed the permissions with "chown -R mailman:mailman
/var/lib/mailman/lists/"
3. Fixed the urls for the new one with "/usr/lib/mailman/bin/withlist -l -r
fix_url [listname]"
for each list. (Only necessary if the new server has a different domain
name than the old one - one time I was moving from xcski.com to
list.xcski.com and the other time I was keeping the same list.xcski.com
url.)
4. Copied all /var/lib/mailman/archives/private/*mbox/*mbox to the new
server.
5. Fixed the permissions with "chown -R mailman:mailman
/var/lib/mailman/archives/private"
6. Regenerated the archives using "/usr/lib/mailman/bin/arch [listname]"
for each list. Note that if your archives are big, this process can
consume all the memory in your system and then some, so you may have to
split the mbox files up and regenerate the list archives in peices or use
the "--start" and "--end" options to arch.
But coming on http://newbie.domain.com/mailman I get to http://rabbit.domain.com/mailman/listinfo
Could you help me resolve this problem?
--
Best regards
Alex Trifonov
Hello.
I'm trying to make Mailman to work with Mysql database. I followed this
instructions: http://goo.gl/QkTso and in mail log this is the last line:
postfix/local[13381]: AA4B9B38235: to=<clani(a)xxxxx.xx>, relay=local,
delay=0.39, delays=0.02/0.04/0/0.34, dsn=2.0.0, status=sent (delivered
to command: /usr/lib/mailman/mail/mailman post clani)
But emails are not send to list members. If I change it back to "file
based db" (remove extend.py) mails are delivered.
I'm using Mailman version 2.1.9 on CentOS. There is nothing in the
Mailman logs. I can see that queries in mysql are executed and I also
tested connection to Mysql from python. Everything works, just mails are
not send to members.
Can someone help me please?
--
Klemen Humerca
[www.humerca.com|klemen@humerca.com]
Hi everybody,
I am using mailman 2.1.10 and I think this is really a godsent
application, stable and reliable.
I am experiencing a problem though and I am not sure if it has to do
with the mail server or if it a mailman bug. I cannot remember exactly
when it started, so it is difficult to determine the cause.
In all the mailing lists I am running if somebody sends the mail with an
attachment, the mail disappears. It is not rejected nor bounced, it
seems like it went thru but nothing happens.
If I sent a mail w/attachment from a NOTregistered mail, I receive the
bounce message (both user and admin) and the mail is there, waiting for
approval with its attachment. Once I approve the mail/new user, the mail
disappears. It does not even leave track in the progressive numbering in
the subject. Desaparecido.
I tried to:
1) to disable the content filtering (yes, I always kept it disabled)
2) enable the filtering but erase all file extensions
3) set maximum mail size to 0
4) set maximum mail size to 50000 (attachment was 30K)
Still no luck...
Mails without attachments are just fine.
I would appreciate any advice!!!
thanks in advance//
iacopo
Hi,
I am trying to find a solution for filtering the first-senders ip/host
information out of an email header. (I am running mailman with postfix).
I am already doing the anonymization when sending mail for "normal"
users by setting smtpd_sasl_authenticated_header=yes and then using
header_checks to replace the part of the header where the users ip
address can be found with 127.0.0.1.
For mailman I found the anonymous list option, that will hide the
email-address of the original sender but not his ip address. What I want
to do is leaving the senders email-address in the header but hide the
ip-address (or replace it by the list servers address).
[The reason for this (in case this raises questions) are the data
retention efforts of germany and other countries.]
So my questions would be:
- Is there a possibility for mailman itself to replace the senders
address by lets say the mailservers address (IP not Mail).
- If not, is there a possibility to add any extra header information
(like the Authenticated-Header i mentioned before) by mailman? I would
need some unique string inside the header that can be addressed by my
rexular expression.
Thanks in advance,
Sven.
I am currently using Googlegroups and want to move my group to Mailman. The only thing holding me back is the lack of a good Archive that is searchable by topic or key word. Does anyone have any suggestions what to use to allow my group to do research on old posts with a good easy to search archive?
Thanks
Roy
Hi,
(11/08/28 16:18), S. Patrick Eaton wrote:
> Mark, Kikuchi-san,
>
> Thank you both for the very thorough and helpful responses!
>
> I think the approach would be the one that Kikuchi-san describes, but
> it seems like that might involve making changes that our host might
> not want to make (particularly if it will affect their other users). I
> will check with them and see what they can do for us in that area.
>
> If it turns out that they are unable to upgrade to the
> Japanese-enabled version, would changing the character set for English
> to UTF-8 be enough to prevent this problem from occurring? I suspect
> that might be a bit easier for our host to agree to.
In that case, you should apply the second option which hack the mailman
or system supplied email/charset.py. In this case you should watch the
mailman or system upgrade because it will revert the hack.
>
> Thanks again for the suggestions!
>
> Best regards,
>
> Patrick Eaton
>
--
菊地時夫 tokio.kikuchi(a)gmail.com
2011/3/31 をもって 高知大学 を退職しました。
(旧メールアドレス) tkikuchi(a)is.kochi-u.ac.jp
Hello, everyone.
I'm a long-time user of Mailman, but a first-time poster here. Please
go easy on me while I get my bearings, okay?
I am running a Mailman list for a group of translators who work with
the Japanese language (translating either into Japanese or from
Japanese into another language), and because most of the subscribers
are native speakers of either Japanese or English (although there are
speakers of other languages as well) most of the messages posted to
this list are in either of those languages, and often they mix both
languages in the same message.
I've been having a number of problems with the distribution of digest
messages that I am hoping someone here can help me with.
The first is that, unless the Mailman administrative interface is
changed to Japanese, any Japanese characters included in digest
messages get changed into question mark characters when the digest is
sent out, even if those characters appeared correctly in the message
that was sent out to non-digest subscribers. If the interface is
changed to Japanese, this does not occur; Japanese characters then
appear in the digests the way they should.
This, however, inevitably runs into another problem: When the
interface is changed to Japanese, the distribution of digests
continues for a while, but inevitably it stops at some point and does
not resume until the interface is changed back to English, at which
point all of the messages that had not been distributed in digests
since the last digest was sent get included in the next digest
message, which can be quite massive if the digests have not been
getting sent out regularly for a while.
I've looked through some of the digest-related bugs recorded at
Launchpad, and these give me the impression that this sort of problem
(if not this exact issue) is not entirely unknown to the developers,
and there may even be a solution of some sort already, but I have not
yet found it.
If my understanding of the problem is correct, it seems like some
non-standard characters that are included in some inbound messages
cause problems for the process handling the digests, which for some
reason does not recover if it encounters such problems, unless it is
somehow manually reset (such as when the interface language changes,
as described above). I know that most of the messages sent to the list
are encoded as either UTF-8 or ISO-2022-JP, but I don't really know
which characters might be causing the digests to get clogged up.
I have encountered this very same problem in two Mailman
installations, one running Mailman 2.1.9 and another running Mailman
2.1.12, on two entirely separate hosted environments, so I am
reasonably sure that the problem is specific to Mailman and not to
installation or environment-related issues.
If anyone has any advice or suggestions (in either English or
Japanese!) that might help me solve this problem, I would be very glad
to hear them. Although this is the first time I have posted to this
list about this, it is a problem that has been occurring for quite
some time, so it would be a great relief to be able to get it
resolved.
With many thanks in advance for your time and consideration,
Patrick Eaton