Re: [Mailman-Users] 2.1.18 internal documentation suggestions

On Thu, 2014-05-01 at 22:09 -0700, Mark Sapiro wrote: > So it seems clear to me that we're *adding* the From: address to > Reply-To: and the only question is how does first_strip_reply_to affect > this, and the answer is if it's Yes, the Reply-To: we're adding to was > stripped and is empty, and if

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

On 05/01/2014 09:57 PM, Andrew Partan wrote: > > Do you have a setting to change From: user@domain to From: user@domain.INVALID > - that is the hack I would like to use. No, not currently. It is an interesting idea, but it may cause issues in delivery of mail From: a non-existent domain. -- Ma

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

On 05/01/2014 09:33 PM, Stephen J. Turnbull wrote: > Mark Sapiro writes: > > > The transformations for anonymous_list are applied before any of these > > actions, so if actions other than No are applied on an anonymous list, > > they will apply to the anonymized message. > > This may be confus

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

On 05/01/2014 09:26 PM, Lindsay Haisley wrote: > > If first_strip_reply_to = No there are two possible situations which > aren't covered in your (much improved!) self-doc. Either the original > poster included a Reply-To:, or not. If not, then I assume the original > From: address is put into th

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

On Thu, May 01, 2014 at 08:29:30PM -0700, Mark Sapiro wrote: > Here's what I've got. I didn't change the name of the setting, but I > changed its description and all the detail. I now have Do you have a setting to change From: user@domain to From: user@domain.INVALID - that is the hack I would lik

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

Mark Sapiro writes: > dmarc_moderation_action is unreliable. If the DNS lookup times out, the > message is assumed unaffected by DMARC. Ouch. I suppose you could hard-code a list of miscreants, er, domains that have used p=reject and fall back on that (including a check for a change in policy

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

Mark Sapiro writes: > from_is_list (general): Replace the From: header address with the list's > posting address to mitigate issues stemming from the original From: > domain's DMARC or similar policies. That's good! [snip my suggestion :] > The following actions are applied to all list mess

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

On Thu, 2014-05-01 at 20:29 -0700, Mark Sapiro wrote: > first_strip_reply_to = Yes will remove all the incoming Reply-To: > addresses but will still add the poster's address to Reply-To: for all > three settings of reply_goes_to_list which respectively will result in > just the poster's address, th

Re: [Mailman-Users] DMARC From munging: Keep original sender

On 05/01/2014 08:05 AM, Mark Sapiro wrote: > On 05/01/2014 07:54 AM, Ralf Jung wrote: >> >> I just noticed that stripping reply-to headers was enabled on the list >> in question, and that this is not the default (as I originally thought >> it was - I wasn't the one who initially set up these lists)

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

On 04/30/2014 11:58 PM, Stephen J. Turnbull wrote: > Why not just deprecate > list_is_from in favor of dmarc_moderation_action? > I don't think I can for two reasons. One is technical. dmarc_moderation_action is unreliable. If the DNS lookup times out, the message is assumed unaffected by DMARC

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

Here's what I've got. I didn't change the name of the setting, but I changed its description and all the detail. I now have from_is_list (general): Replace the From: header address with the list's posting address to mitigate issues stemming from the original From: domain's DMARC or similar polici

Re: [Mailman-Users] ht://Dig integration patches with Mailman 2.1.12/RHEL 6.5

On 05/01/2014 05:55 PM, Mark Sapiro wrote: > > I can't help at all with RPM packaging, but I can tell you that this > diff is for a user crontab designed to be 'configured' into crontab.in > and then installed as a user crontab in, e.g. /var/spool/mailman That should have been /var/spool/cron/ma

Re: [Mailman-Users] ht://Dig integration patches with Mailman 2.1.12/RHEL 6.5

On 05/01/2014 04:30 PM, Greg Earle wrote: > > I have the indexing and ht://Dig patches for 2.1.12 and I'm trying > to integrate it into a custom RPM build, like its predecessor. Basing > it on mailman-2.1.12-18.el6.src.rpm. I can't help at all with RPM packaging, but I can tell you that this di

Re: [Mailman-Users] accessing relay mailman server from its own network

On 05/01/2014 11:31 AM, Anne Wainwright wrote: > > I still have dyndns addresses showing on the numeric/alpha address > listing both locally and from outside I do not understand "the numeric/alpha address listing" Where specifically do you see these? > I have changed DEFAULT_URL_HOST in mm_cf

[Mailman-Users] ht://Dig integration patches with Mailman 2.1.12/RHEL 6.5

At work I'm dealing with migrating a legacy production system that uses Mailman 2.1.9 with ht://Dig integration on a RHEL 5.x box. I'm trying to migrate it to a RHEL 6.5 system with Mailman 2.1.12-18. I have the indexing and ht://Dig patches for 2.1.12 and I'm trying to integrate it into a custom

Re: [Mailman-Users] Mailman error (2.1.16): "low level unrecoverable exception"

On 05/01/2014 10:06 AM, Robert Heller wrote: > > I also found a *fatal* error in Tagger.py at line 74: > ... > TypeError: change_header() got an unexpected keyword argument 'Delete' That's a known bug which was fixed in 2.1.17 . > I deleted the

Re: [Mailman-Users] accessing relay mailman server from its own network

Hello, Mark, A year has gone by and the system has run well. This was with the ip address set for users on the network in the 'hosts' file and with the 'absolute=1' setting in admindb.py Recently I changed my dns provider (from dyndns to activedns) and was back reviewing what had happened here be

Re: [Mailman-Users] Mailman error (2.1.16): "low level unrecoverable exception"

At Thu, 01 May 2014 08:31:05 -0700 Mark Sapiro wrote: > > On 05/01/2014 08:21 AM, Robert Heller wrote: > > At Wed, 30 Apr 2014 14:34:51 -0700 Mark Sapiro wrote: > >> > >> Did you totally remove the Centos package or try to 'upgrade' it. The > >> latter is not at all straightforward. See the FAQ

Re: [Mailman-Users] Mailman error (2.1.16): "low level unrecoverable exception"

On 05/01/2014 08:21 AM, Robert Heller wrote: > At Wed, 30 Apr 2014 14:34:51 -0700 Mark Sapiro wrote: >> >> Did you totally remove the Centos package or try to 'upgrade' it. The >> latter is not at all straightforward. See the FAQ at >> . > > That page relates to upgra

Re: [Mailman-Users] Mailman error (2.1.16): "low level unrecoverable exception"

At Wed, 30 Apr 2014 14:34:51 -0700 Mark Sapiro wrote: > > On 04/30/2014 11:30 AM, Robert Heller wrote: > > What does this error message mean? "low level unrecoverable exception" > > > It means something really bad happened. One of the Mailman web CGIs > threw an exception and the CGI driver sc

Re: [Mailman-Users] DMARC From munging: Keep original sender

Hi, >> I just noticed that stripping reply-to headers was enabled on the list >> in question, and that this is not the default (as I originally thought >> it was - I wasn't the one who initially set up these lists). Stripping >> happens after From munging, so this explains my issue. After disablin

Re: [Mailman-Users] DMARC From munging: Keep original sender

On 05/01/2014 07:54 AM, Ralf Jung wrote: > > I just noticed that stripping reply-to headers was enabled on the list > in question, and that this is not the default (as I originally thought > it was - I wasn't the one who initially set up these lists). Stripping > happens after From munging, so thi

Re: [Mailman-Users] DMARC From munging: Keep original sender

Hi, thanks for the fast reply. >> Strange enough, I found code in Mailman/Handlers/CookHeaders.py which >> adds the original sender to reply-to (which I was about to suggest), but >> that header does not end up in the mail. >> What I would expect to happen is (with from munging): >> * reply_goes_

Re: [Mailman-Users] DMARC From munging: Keep original sender

On 05/01/2014 05:46 AM, Ralf Jung wrote: > > Strange enough, I found code in Mailman/Handlers/CookHeaders.py which > adds the original sender to reply-to (which I was about to suggest), but > that header does not end up in the mail. It should. > Is this a known problem? Am I doing something wr

Re: [Mailman-Users] DMARC From munging: Keep original sender

On Thu, 2014-05-01 at 14:46 +0200, Ralf Jung wrote: > I am currently experimenting with the From munging of Mailman (2.1.16) > to make my lists DMARC-compliant. This is generally working, there is a > problem though: I found no way so far to tell, from the mail that's > ultimately delivered to the

[Mailman-Users] DMARC From munging: Keep original sender

Dear all, I am currently experimenting with the From munging of Mailman (2.1.16) to make my lists DMARC-compliant. This is generally working, there is a problem though: I found no way so far to tell, from the mail that's ultimately delivered to the users, who was the original sender. No matter whe

Re: [Mailman-Users] Private mailing list reply watcher

The situation (let's call it situation S) I want to detect is as follows: 1.) not-member writes to a private mailing list which serves as a contact point 2.) member writes a reply to the list (usually by hitting reply-to and not reply-all in his mail client) Depending on the circumstances, this c

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

Mark Sapiro writes: > I'm not sure what to change at this point. I really don't want another > change in the attribute name, but maybe. Yeah, I know. On the other hand, now that it really matters, this is probably the last chance to make such a change. > I'm also not sure about alignment as