Changing the received time on an outgoing authorized email message?
When authorizing a moderated list posting is it possible to change the date/time on the outgoing authorized list message to the time it was approved instead of the message showing the time it was first received by mailman?
Thanks
Paul
On 8/1/07, Paul Key wrote:
When authorizing a moderated list posting is it possible to change the date/time on the outgoing authorized list message to the time it was approved instead of the message showing the time it was first received by mailman?
I'm not aware of any ability to do this with Mailman, although there are aspects of the moderation interface that I don't use. You might be able to make changes to the message, re-submit the message as the originator, and then go through the moderation process again.
Other than that, I don't see any obvious solution to this problem that doesn't involve writing custom code. However, you should check the Mailman patches page on SourceForge to see if anyone else has had this problem and created a suggested solution.
-- Brad Knowles <brad@shub-internet.org>, Consultant & Author LinkedIn Profile: <http://tinyurl.com/y8kpxu> Slides from Invited Talks: <http://tinyurl.com/tj6q4>
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
Brad Knowles wrote:
On 8/1/07, Paul Key wrote:
When authorizing a moderated list posting is it possible to change the date/time on the outgoing authorized list message to the time it was approved instead of the message showing the time it was first received by mailman?
I'm not aware of any ability to do this with Mailman, although there are aspects of the moderation interface that I don't use. You might be able to make changes to the message, re-submit the message as the originator, and then go through the moderation process again.
See FAQ at <http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.009.htp> for more on this.
Other than that, I don't see any obvious solution to this problem that doesn't involve writing custom code.
Correct, however mailman does currently add an X-Mailman-Approved-At: header to the approved post with the local time of approval. For some purposes at least, this might suffice (now that you know it's there).
You could also modify the code in Mailman/ListAdmin.py that adds this header to mung the Date: header instead if that's really important, but my opinion is the poster's original date should be preserved.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
I am trying to determine why emails to lists sometimes take well in excess of an hour....sometimes 4....
Is there anyway to determine where the issue lies?
regards
Steven Jones Senior Linux/Unix/San System Administrator APG -Technology Integration Team Victoria University of Wellington Phone: +64 4 463 6272
On 8/2/07, Steven Jones wrote:
I am trying to determine why emails to lists sometimes take well in excess of an hour....sometimes 4....
Is there anyway to determine where the issue lies?
Look at the logs. Correlate the message-ids in the MTA logs (sendmail, postfix, whatever) with the message-ids in the Mailman logs (presumably in /usr/local/mailman/logs, or elsewhere as appropriate for your installation), and then do the same for the outbound traffic (going back to the MTA logs with the ids of the messages as they are generated by Mailman).
That's about the only way I know of.
-- Brad Knowles <brad@shub-internet.org>, Consultant & Author LinkedIn Profile: <http://tinyurl.com/y8kpxu> Slides from Invited Talks: <http://tinyurl.com/tj6q4>
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
Brad Knowles wrote:
On 8/2/07, Steven Jones wrote:
I am trying to determine why emails to lists sometimes take well in excess of an hour....sometimes 4....
Is there anyway to determine where the issue lies?
Look at the logs. Correlate the message-ids in the MTA logs (sendmail, postfix, whatever) with the message-ids in the Mailman logs (presumably in /usr/local/mailman/logs, or elsewhere as appropriate for your installation), and then do the same for the outbound traffic (going back to the MTA logs with the ids of the messages as they are generated by Mailman).
That's about the only way I know of.
Also see <http://mail.python.org/pipermail/mailman-users/2007-July/057755.html>
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Thanks to both, I don't think its DNS as the mailman server is smarthost'd in sendmail to go to a outgoing smtp server....so why it would do dns lookups I don't know...
regards
Steven Jones Senior Linux/Unix/San System Administrator APG -Technology Integration Team Victoria University of Wellington Phone: +64 4 463 6272 Mobile: +64 27 563 6272
-----Original Message----- From: Mark Sapiro [mailto:msapiro@value.net] Sent: Thursday, 2 August 2007 4:25 p.m. To: Brad Knowles; Steven Jones; mailman-users@python.org Subject: Re: [Mailman-Users] Messages take over an hour to pass throughmailman
Brad Knowles wrote:
On 8/2/07, Steven Jones wrote:
I am trying to determine why emails to lists sometimes take well in excess of an hour....sometimes 4....
Is there anyway to determine where the issue lies?
Look at the logs. Correlate the message-ids in the MTA logs (sendmail, postfix, whatever) with the message-ids in the Mailman logs (presumably in /usr/local/mailman/logs, or elsewhere as appropriate for your installation), and then do the same for the outbound traffic (going back to the MTA logs with the ids of the messages as they are generated by Mailman).
That's about the only way I know of.
Also see <http://mail.python.org/pipermail/mailman-users/2007-July/057755.html>
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 8/2/07, Steven Jones wrote:
Thanks to both, I don't think its DNS as the mailman server is smarthost'd in sendmail to go to a outgoing smtp server....so why it would do dns lookups I don't know...
It all depends on the MTA configuration of whatever machine Mailman is connecting to port 25 and doing the initial delivery. That's the machine you need to check. As far as this is concerned, there's nothing within Mailman itself that you can check or fix -- this is an MTA issue instead.
-- Brad Knowles <brad@shub-internet.org>, Consultant & Author LinkedIn Profile: <http://tinyurl.com/y8kpxu> Slides from Invited Talks: <http://tinyurl.com/tj6q4>
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
Hi,
My management want to move our listing function to Exchange 2k10....however we have a need to maintain the archives on the existing mailman server so ppl can search them.
Is it possible to disable all of mailman's functions except search/browsing of the archive?
regards
Steven
Steven Jones wrote:
My management want to move our listing function to Exchange 2k10....however we have a need to maintain the archives on the existing mailman server so ppl can search them.
Is it possible to disable all of mailman's functions except search/browsing of the archive?
If the archives are public, all you need is Mailman's archives/ directory (both archives/private/ and archives/public/) and the pipermail alias in your web server. The rest can go unless there is some CGI for searching.
If (some of) the archives are private, it's a little trickier because you have to maintain the 'private' CGI and the lists for authentication.
In either case, perhaps the simplest approach is to stop Mailman and not start it again, remove the Mailman aliases or whatever the MTA uses to deliver to Mailman, and remove the 'listinfo' and perhaps other wrappers from Mailman's cgi-bin/ directory leaving maybe only 'private' and anything relating to archive searching.
You may or may not also want to remove Mailman's crontab so password reminders aren't sent.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Mon, Sep 06, 2010 at 06:18:52PM -0700, Mark Sapiro wrote:
Steven Jones wrote:
My management want to move our listing function to Exchange 2k10....however we have a need to maintain the archives on the existing mailman server so ppl can search them.
Is it possible to disable all of mailman's functions except search/browsing of the archive?
If the archives are public, all you need is Mailman's archives/ directory (both archives/private/ and archives/public/) and the pipermail alias in your web server. The rest can go unless there is some CGI for searching.
If (some of) the archives are private, it's a little trickier because you have to maintain the 'private' CGI and the lists for authentication.
Both of those assume that you(r managers) don't want to send the Exchange list mails to the archive, too. (perhaps, say, for continuoty reasons).
In either case, perhaps the simplest approach is to stop Mailman and not start it again, remove the Mailman aliases or whatever the MTA uses to deliver to Mailman, and remove the 'listinfo' and perhaps other wrappers from Mailman's cgi-bin/ directory leaving maybe only 'private' and anything relating to archive searching.
If continuing the archive were to be the case, I'd ditch existing subscribers, control new subscriptions, add the Exchange address as an allowed sender and sort out implicit (if needed), carrying on from there.
I've not played with Exchange 2010 lists. Are they any good? RFC compliant? Handling bounces?
You may or may not also want to remove Mailman's crontab so password reminders aren't sent.
:) but maybe not the archive building...
-- "applying logic to English slang is never a sound idea" -- Stephen Fry
Adam McGreggor wrote:
On Mon, Sep 06, 2010 at 06:18:52PM -0700, Mark Sapiro wrote:
You may or may not also want to remove Mailman's crontab so password reminders aren't sent.
:) but maybe not the archive building...
If by archive building, you mean cron/nightly_gzip, I suggest removing that from all installations. All it does is gzip the periodic pseudo-mailbox (e.g. 2010-September.txt) so that the gzipped file is the "Downloadable version" linked on the archive TOC page. It saves no space because the un-gzipped version is retained (in fact, it uses additional space for the gzipped version), and the gzipped version is up to 24 hours behind and is thus usually incomplete.
The only advantage is a possible saving of bandwith when one downloads the file, but this seems like an artifact from an earlier time.
It might be worth it to gzip older files and remove the corresponding un-gzipped files, but this is not what is done by cron/nightly_gzip.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hi,
<rant>
"They" dont want to create new mailman lists "anymore" as they have to be created by a Linux systems administrator (ie be root to edit /etc/aliases)...so 15mins a week is too much work...so they want to do it with "user admins" that are incapable of anything but AD/gui type work...and I wouldn't give them the root password....
8><--------
Both of those assume that you(r managers) don't want to send the Exchange list mails to the archive, too. (perhaps, say, for continuity reasons).
8><--------
...I assume not as Mailman has to go as they dont want to keep creating new lists. Users might want it, in fact I bet they will...that would be funny.
6 years ago they complained about the cost, the un-reliability and in-flexibility of Communigate and linux admins had to edit files by hand to change things for them...so I installed Mailman. Mailman has served them almost faultlessly for free in that 6 years (apart from probably my f*ups) so the TCO has been incredibly low....
I will say that I have also has superb support from this list and Mark in particular over that time period, I will thank you all for that.......that has been priceless and shows up many commercial vendors...
8><-----------
I've not played with Exchange 2010 lists. Are they any good? RFC compliant? Handling bounces?
8><----------
Oh that's a nightmare I wont go into....someone wants it changed so it will I suspect get changed....even if it doesn't work very well and costs more time, but hey I don't do MS stuff and especially not Exchange so it wont be my little nightmare....I have advised them time and time again what they have is probably the best they can get especially considering its cost.
</rant>
regards and again, thanks
participants (7)
-
Adam McGreggor -
Brad Knowles -
Mark Sapiro -
Mark Sapiro -
Paul Key -
Stephen J. Turnbull -
Steven Jones