Re: [Mailman-Users] 2.1.18 internal documentation suggestions

[Stephen J. Turnbull]

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 that is a technical term in the
 > DMARC spec and may be more technical than we want here.

Sure.  But "from rewriting" is something we do for other reasons
(anonymous lists), and saying that message/rfc822 encapsulation is
"from rewriting" seems way too inaccurate to me.

 > > [FIXME: Should this respect the MIME vs. legacy encapsulation
 > > ('digest') setting?  If 'yes', that setting should move to General
 > > or so?]
 > 
 > I don't want to go the FIXME route. It's too hard for this release.

OK.

 > Also, are you suggesting doing this for all messages based on what is
 > now Digest options-> mime_is_default_digest or doing it per user based
 > on the user's "Get MIME or Plain Text Digests?"

Per user, because of the issues we've heard about specific MUAs having
trouble with MIME encapsulation.

 > Also, this (legacy encapsulation) really only differs from the Munge
 > >From option in that a few headers are copied to the body of the message
 > and non-text/plain part are scrubbed, and I don't know how valuable it
 > would be.

True.  I mention it because we've had PRs about MIME encapsulation
already.

 > >  > header munging settings below with the exception of adding "via
 > >  > real_name" to the display name in the From: for an anonymous list and
 > > 
 > > ??  Adding real name to From in an *anonymous* list?
 > 
 > real_name refers the the list attribute which is the list name with
 > possibly different capitalization, but I see it should be changed.

OIC.  I don't think you need to mention it here; Mailman should just
DTRT.  If it's an anonymous list, the list owner should configure
'From' correctly, that's all.

 > Hold is not an option for dmarc_moderation_action. it is the action
 > which applies to messages From: a domain with DMARC policy p=reject an
 > optionally p=quarantine. The possible actions are Accept, Munge From,
 > Wrap Message, Reject or Discard

I don't understand why we need both this and list_is_from?  The latter
is a clear violation of RFC 5322, acceptable only because it's one of
the approaches the DMARC proponents (and Yahoo!) suggest for mailing
lists faced with a DMARC DoS attack.  Why not just deprecate
list_is_from in favor of dmarc_moderation_action?
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

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

[Tomáš Babej]

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 can be intentional or not.

* if you need to discuss the content of the non-member's message privately,
it can be intentional
* if you wanted to reply to the non-member, it is not intentional (and can
be easily missed, since
  every list member sees the email in the thread and thinks the mailing
list has been cc-ed)

Since you cannot really distinguish between these two variants, my thought
is to monitor the mailing list,
and if the situation S occurs, have a warning message replied to the list
("Warning! This email
was addressed to the mailing list only.")

My thoughts how to go with this are:

* gain access to the conferrence Mailbox, and watch it with for changes
with inotify
* on Mailbox change, parse it with python script which will detect
situation S and send a warning to the list
* list of the members can be extracted using list_members

Compared to integrating this with the mailman directly, this has the
advantage of working with any mailing
list solution (as long as list of members can be easily extracted).

Thoughts? Would anybody be interested in such tool?


On Thu, May 1, 2014 at 12:42 AM, Mark Sapiro  wrote:

> On 04/30/2014 07:33 AM, Tomas Babej wrote:
> >
> > I plan to write a script that will handle such cases in a generic way,
> > however, I don't like reinventing the wheel. Does anybody know if this
> > problem has already been solved?
>
>
> What problem are you trying to solve? Remailing the reply from the list
> archive to the original sender, or something else?
>
> From your Subject:, it seems you're looking for something that monitors
> list traffic and in case of a message determined to be a reply to the
> list with no Cc: to someone else, sends that message to the someone
> else, but identifying to whom might be tricky. I'd be interested in what
> you come up with.
>
> --
> Mark Sapiro The highway is for gamblers,
> San Francisco Bay Area, Californiabetter use your sense - B. Dylan
> --
> Mailman-Users mailing list Mailman-Users@python.org
> https://mail.python.org/mailman/listinfo/mailman-users
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Security Policy: http://wiki.list.org/x/QIA9
> Searchable Archives:
> http://www.mail-archive.com/mailman-users%40python.org/
> Unsubscribe:
> https://mail.python.org/mailman/options/mailman-users/tomasbabej%40gmail.com
>
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

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

[Ralf Jung]

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 whether I set reply_goes_to_list to 0 or 1 (and unfortunately,
many of my users request a 1 here :-/ ), the final mail contains no
trace of the original sender except for its pretty-printed name.

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_to_list=0: The reply-to header contains the sender
* reply_goes_to_list=1: The reply-to header contains the sender (due to
  munging) and the list (due to replies going to the list)

Is this a known problem? Am I doing something wrong? Any help would be
appreciated.

Kind regards
Ralf
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

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

[Lindsay Haisley]

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 users, who was the original sender. No
> matter whether I set reply_goes_to_list to 0 or 1 (and unfortunately,
> many of my users request a 1 here :-/ ), the final mail contains no
> trace of the original sender except for its pretty-printed name.
> 
> 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_to_list=0: The reply-to header contains the sender
> * reply_goes_to_list=1: The reply-to header contains the sender (due to
>   munging) and the list (due to replies going to the list)
> 
> Is this a known problem? Am I doing something wrong? Any help would be
> appreciated.

This is being addressed in MM 2.1.18, to be released shortly.

-- 
Lindsay Haisley   | "Everything works if you let it"
FMP Computer Services |
512-259-1190  |  --- The Roadie
http://www.fmp.com|

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

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

[Mark Sapiro]

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 wrong? Any help would be
> appreciated.


The current release is 2.1.18rc3. The final will be released this
weekend. It works there. It should work in 2.1.16 as long as the list is
not fully personalized.

There are bugs fixed in 2.1.18rc3, but they don't seem relevant to your
case. See ,
 and
.

I'll try later today to duplicate this with 2.1.16.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

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

[Ralf Jung]

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_to_list=0: The reply-to header contains the sender
>> * reply_goes_to_list=1: The reply-to header contains the sender (due to
>>   munging) and the list (due to replies going to the list)
>>
>> Is this a known problem? Am I doing something wrong? Any help would be
>> appreciated.
> 
> This is being addressed in MM 2.1.18, to be released shortly.

So what will be the new behaviour? I read through the release notes but
could not find anything applying to this particular issue.

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 disabling
stripping, the original sender remains in the Reply-To.
I would however argue that this is not expected - in particular, the
text says that the Reply-To header of the "original message" is removed,
which I read as: First the header is removed, then all the other
processing is done.

Kind regards
Ralf
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

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

[Mark Sapiro]

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 this explains my issue. After disabling
> stripping, the original sender remains in the Reply-To.


The from_is_list description in 2.1.16 does say Reply-To: munging takes
priority.


> I would however argue that this is not expected - in particular, the
> text says that the Reply-To header of the "original message" is removed,
> which I read as: First the header is removed, then all the other
> processing is done.


I *think* it works as you expect in 2.1.18rc3, but I'll have to double
check.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

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

[Ralf Jung]

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 disabling
>> stripping, the original sender remains in the Reply-To.
> 
> 
> The from_is_list description in 2.1.16 does say Reply-To: munging takes
> priority.

Indeed, I must have missed that.

> I *think* it works as you expect in 2.1.18rc3, but I'll have to double
> check.

Distribution packages as usual lack behind...

Kind regards
Ralf
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

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

[Robert Heller]

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 script encountered another
> exception while trying to log a traceback and the environment info.
> 
> 
> > I just installed my own build of mailman 2.1.16 (built under CentOS 5 
> > x84_64)
> > as an upgrade over the stock 2.1.9 that comes with CentOS 5 and I am getting
> > this error. What should I be looking for? 
> 
> 
> Did you restart Mailman or stop before, start after?

I believe the install scripts in the RPM stop and restart Mailman.  But I will 
do an explicit shutdown of Mailman before the upgrade when I try it again.

> 
> 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 upgrading from 2.1.5-20 or earlier.  I was upgrading from 
2.1.9, so that does not apply (?).  When I did an upgrade to 2.1.16 from an 
'bare' install of 2.1.9 on my home system, there weren't any (major) problems. 
And a fresh install of 2.1.16 (on another machine) had no problems either.

Ok, I did an explict stop of mailman, removed the old rpm (rpm -e) and then a
fresh install of the new version, started mailman, and after some minor config
tweaks, it seems to be working.

> 
> There was an issue a while back, see
> ,
> but this was due to a SuSE patch that referenced a Python xml library
> that wasn't installed. The specifics aren't relevant to your issue, but
> it could indicate there's something missing in your python. Have you
> installed the python-dev package?
> 

-- 
Robert Heller -- 978-544-6933 / hel...@deepsoft.com
Deepwoods Software-- http://www.deepsoft.com/
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments



  
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

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

[Mark Sapiro]

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 upgrading from 2.1.5-20 or earlier.  I was upgrading 
> from 
> 2.1.9, so that does not apply (?).


That FAQ and the mailman-developers post linked from it explain changed
in the RedHat/CentOS package beginning with 2.1.15 that render it
impossible to do a straightforward configure/install of a GNU Mailman
source distribution on top of an existing RedHat/CentOS package.


> Ok, I did an explict stop of mailman, removed the old rpm (rpm -e) and then a
> fresh install of the new version, started mailman, and after some minor config
> tweaks, it seems to be working.


Good.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

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

[Robert Heller]

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 at
> >> .
> > 
> > That page relates to upgrading from 2.1.5-20 or earlier.  I was upgrading 
> > from 
> > 2.1.9, so that does not apply (?).
> 
> 
> That FAQ and the mailman-developers post linked from it explain changed
> in the RedHat/CentOS package beginning with 2.1.15 that render it
> impossible to do a straightforward configure/install of a GNU Mailman
> source distribution on top of an existing RedHat/CentOS package.
> 
> 
> > Ok, I did an explict stop of mailman, removed the old rpm (rpm -e) and then 
> > a
> > fresh install of the new version, started mailman, and after some minor 
> > config
> > tweaks, it seems to be working.
> 
> 
> Good.

I also found a *fatal* error in Tagger.py at line 74:

May 01 10:50:39 2014 (17899) Traceback (most recent call last):
  File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 119, in _oneloop
self._onefile(msg, msgdata)
  File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 190, in _onefile
keepqueued = self._dispose(mlist, msg, msgdata)
  File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 130, in _dispose
more = self._dopipeline(mlist, msg, msgdata, pipeline)
  File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 153, in 
_dopipeline
sys.modules[modname].process(mlist, msg, msgdata)
  File "/usr/lib/mailman/Mailman/Handlers/Tagger.py", line 74, in process
mlist, msg, msgdata, Delete=False)
TypeError: change_header() got an unexpected keyword argument 'Delete'

I deleted the ', Delete=False' from the change_header parameter list and
removed Tagger.pyc and Tagger.pyo (forcing the use of the uncompiled code) as
a short term temp fix (so that mail will go through). I *presume* that this is
fixed in 2.1.18 and when that comes out (I understand it is due out "Real Soon
Now"(tm)).

-- 
Robert Heller -- 978-544-6933 / hel...@deepsoft.com
Deepwoods Software-- http://www.deepsoft.com/
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments



  
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

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

[Anne Wainwright]

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 because I was again having the
same issues. obviously I had not handled it correctly

In the end I changed the code in admindb.py from absolute to relative
(deleted all instances of 'absolute=1', changed 'hosts' file to show the
activedns address   but

I still have dyndns addresses showing on the numeric/alpha address
listing both locally and from outside

I have changed DEFAULT_URL_HOST in mm_cfg.py appropriately, cleared the
browser caches. Where can this be dyndns be hiding, or is it time to run 
the fix_url script?

regards
Anne




On Sun, Apr 14, 2013 at 04:14:32PM -0700, Mark Sapiro wrote:
> On 4/14/2013 10:13 AM, Anne Wainwright wrote:
> > 
> > I have tried that with partial success, but there is another odd 
> > unmentioned behaviour that I have/had to cope with.
> > 
> > When I click on a 0-9A-Z link I am dumped outside back at the
> > login window. When I log in a second time I am presented with the
> > list of members that I wanted in the first place, subsequent
> > queries work first time. Similarly when I need to moderate a
> > message.
> 
> 
> If I understand correctly, this is what's happening in those cases.
> You have a /etc/hosts or whatever to direct the 'outside' host to the
> 'inside' host. You go to the admin or admindb page via an 'inside'
> URL (probably a bookmark) and log in. Once there, relative links work
> fine. You go to a link with an absolute URL. This points to the
> 'outside' host which as far as your browser is concerned is not the
> host that set the authentication cookie so it is not returned to the
> 'outside' host and you have to log in again. Once you have logged in
> once for each host, you are authenticated for the rest of the browser
> session.
> 
> The answer is if you have /etc/hosts or whatever routing the 'outside'
> host to the 'inside' host, never go to the 'inside' host (fix your
> bookmarks to point to the 'outside' host name).
> 
> 
> > At the moment removing the 'absolute=1' entries does the job 100%.
> 
> 
> If you do notice any issues related to this, please let me know.
> 
> -- 
> Mark Sapiro The highway is for gamblers,
> San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

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

[Mark Sapiro]

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 ', Delete=False' from the change_header parameter list


That's the wrong fix. The correct fix is to change the spelling from
Delete=False to delete=False


> and
> removed Tagger.pyc and Tagger.pyo (forcing the use of the uncompiled code) as
> a short term temp fix (so that mail will go through).


That was unnecessary. When Python imports a module, and there is a .py
and a .pyc and maybe a .pyo, it checks the time stamps and if the .py is
more recent, it loads that and compiles it and if it has permission,
(re)writes the .pyc.


> I *presume* that this is
> fixed in 2.1.18 and when that comes out (I understand it is due out "Real Soon
> Now"(tm)).


As I note above, fixed in 2.1.17, and the final 2.1.18 release will be
this weekend barring any unforeseen personal emergencies.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

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

[Greg Earle]

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 RPM build, like its predecessor.  Basing
it on mailman-2.1.12-18.el6.src.rpm.

Has anyone on the list done this before?

It seems like no matter where I try to put the 2 patches in the .spec
file, there is a conflict between the htdig patch and some other patch
(like the "cron" patch or the "FHS" patch).

What's strange is that the patches for 2.1.9 seem not all that very
different, and yet that rpmbuild worked perfectly for me!  But no
such luck with 2.1.12 so far.

If I look in the old 2.1.9 version of the htdig patch file, I see
this segment for "crontab.in.in", for example:

--
diff -ruP --exclude=.DS_Store mailman-2.1.9-index/cron/crontab.in.in mailman-2.1
.9-htdig/cron/crontab.in.in
--- mailman-2.1.9-index/cron/crontab.in.in  2002-01-06 06:28:12.0 +0
000
+++ mailman-2.1.9-htdig/cron/crontab.in.in  2006-09-20 16:06:17.0 +0
100
@@ -18,6 +18,11 @@
 # or want to exclusively use a callback strategy instead of polling.
 0,5,10,15,20,25,30,35,40,45,50,55 * * * * @PYTHON@ -S @prefix@/cron/gate_news
 #
+# At 2:19am every night, regenerate htdig search files.  Only
+# turn this on if the internal archiver is used and htdig
+# use enabled in mm_cfg.py with USE_HTDIG
+19 2 * * * @PYTHON@ -S @prefix@/cron/nightly_htdig
+#
 # At 3:27am every night, regenerate the gzip'd archive file.  Only
 # turn this on if the internal archiver is used and
 # GZIP_ARCHIVE_TXT_FILES is false in mm_cfg.py
--

which assumes that line 19 has "gate_news" and "@PYTHON@" in it.

Yet if I look at the actual diffs after the 2.1.9 htdig patch was
(successfully) applied, it's somehow not the same:

--
[root@rushmore cron]# diff -u crontab.in.in.htdig crontab.in.in
--- crontab.in.in.htdig 2009-04-02 01:45:29.0 -0700
+++ crontab.in.in   2009-04-02 01:45:29.0 -0700
@@ -41,6 +41,11 @@
 # or want to exclusively use a callback strategy instead of polling.
 0,5,10,15,20,25,30,35,40,45,50,55 * * * * @MAILMAN_USER@ 
@prefix@/cron/gate_news
 #
+# At 2:19am every night, regenerate htdig search files.  Only
+# turn this on if the internal archiver is used and htdig
+# use enabled in mm_cfg.py with USE_HTDIG
+19 2 * * * @PYTHON@ -S @prefix@/cron/nightly_htdig
+#
 # At 3:27am every night, regenerate the gzip'd archive file.  Only
 # turn this on if the internal archiver is used and
 # GZIP_ARCHIVE_TXT_FILES is false in mm_cfg.py
--

Note the "@MAILMAN_USER@" on the "gate_news" line (which is now line 42
after the "cron" patch had been applied).  Plus, after the "cron" patch
was applied, the line numbers in the "htdig" patch are no longer correct.

In other words, shouldn't the 2.1.9 patch have choked as well, just
as the 2.1.12 patch seems to be doing to me now?

I tried changing the current 2.1.12 htdig patch and put in "@MAILMAN_USER@".

Now the htdig patch works - but then I get an immediate .rej file from
the FHS patch right afterwards.  :-(

The htdig patch assumes FHS hasn't been applied yet - but if htdig is
applied before FHS, then FHS breaks because it doesn't know about the
added "archives/htdig" entry in VAR_DIRS that the htdig patch put there.

I re-ran the 2.1.9 rpmbuild and sure enough, it worked perfectly fine:

--
[...]
Patch #4 (mailman-cron.patch):
+ patch -p1 -b --suffix .cron -s
+ echo 'Patch #5 (indexing-2.1.9-0.1.patch):'
Patch #5 (indexing-2.1.9-0.1.patch):
+ patch -p1 -b --suffix .indexing -s
+ echo 'Patch #6 (htdig-2.1.9-0.1.patch):'
Patch #6 (htdig-2.1.9-0.1.patch):
+ patch -p1 -b --suffix .htdig -s
+ echo 'Patch #7 (mailman-FHS.patch):'
Patch #7 (mailman-FHS.patch):
+ patch -p1 -b --suffix .FHS -s
[...]
--

At this point I'm more shocked that the 2.1.9 patches worked, given what
I've seen with the 2.1.12 patches.  Color me baffled at this point!

If anyone has successfully done this integration and can offer any pointers
(like what order to do the patching, and what patch number in the spec file
to insert them into, or what obvious thing I'm doing wrong), feel free to
respond or send me e-mail directly and take it off-line.

Thanks,

- Greg

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

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

[Mark Sapiro]

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_cfg.py appropriately, cleared the
> browser caches. Where can this be dyndns be hiding, or is it time to run 
> the fix_url script?


Probably. See the FAQ at .

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

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

[Mark Sapiro]

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
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


> diff -ruP --exclude=.DS_Store mailman-2.1.9-index/cron/crontab.in.in 
> mailman-2.1
> .9-htdig/cron/crontab.in.in
> --- mailman-2.1.9-index/cron/crontab.in.in  2002-01-06 06:28:12.0 
> +0
> 000
> +++ mailman-2.1.9-htdig/cron/crontab.in.in  2006-09-20 16:06:17.0 
> +0
> 100
> @@ -18,6 +18,11 @@
>  # or want to exclusively use a callback strategy instead of polling.
>  0,5,10,15,20,25,30,35,40,45,50,55 * * * * @PYTHON@ -S @prefix@/cron/gate_news
>  #
> +# At 2:19am every night, regenerate htdig search files.  Only
> +# turn this on if the internal archiver is used and htdig
> +# use enabled in mm_cfg.py with USE_HTDIG
> +19 2 * * * @PYTHON@ -S @prefix@/cron/nightly_htdig
> +#
>  # At 3:27am every night, regenerate the gzip'd archive file.  Only
>  # turn this on if the internal archiver is used and
>  # GZIP_ARCHIVE_TXT_FILES is false in mm_cfg.py


and this diff is for a system crontab designed to be configured into
crontab.in and installed as, e.g., /etc/cron.d/mailman


> [root@rushmore cron]# diff -u crontab.in.in.htdig crontab.in.in
> --- crontab.in.in.htdig   2009-04-02 01:45:29.0 -0700
> +++ crontab.in.in 2009-04-02 01:45:29.0 -0700
> @@ -41,6 +41,11 @@
>  # or want to exclusively use a callback strategy instead of polling.
>  0,5,10,15,20,25,30,35,40,45,50,55 * * * * @MAILMAN_USER@ 
> @prefix@/cron/gate_news
>  #
> +# At 2:19am every night, regenerate htdig search files.  Only
> +# turn this on if the internal archiver is used and htdig
> +# use enabled in mm_cfg.py with USE_HTDIG
> +19 2 * * * @PYTHON@ -S @prefix@/cron/nightly_htdig
> +#
>  # At 3:27am every night, regenerate the gzip'd archive file.  Only
>  # turn this on if the internal archiver is used and
>  # GZIP_ARCHIVE_TXT_FILES is false in mm_cfg.py
> --

I.e. the htdig patches are for a GNU Mailman source distribution which
assumes the crontab will be installed as the mailman user's crontab
whereas the RedHat package assumes a system crontab, thus the extra
field for the user to run as. I suspect RedHat's crontab drops the
Python command because it's in a shebang line in the cron files anyway
and it avoids a python version dependency in the crontab.

Sorry I can't offer more help.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

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

[Mark Sapiro]

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/mailman.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

[Mark Sapiro]

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 policies.

Several protocols now in wide use attempt to ensure that use of the
domain in the author's address (ie, in the From: header field) is
authorized by that domain. These protocols may be incompatible with
common list features such as footers, causing participating email
services to bounce list traffic merely because of the address in the
From: field. *This has resulted in members being unsubscribed despite
being perfectly able to receive mail.*

The following actions are applied to all list messages when selected
here. To apply these actions only to messages where the domain in the
From: header is determined to use such a protocol, see the
dmarc_moderation_action settings under Privacy options... -> Sender filters.

Settings:

No
Do nothing special. This is appropriate for anonymous lists. It is
appropriate for dedicated announcement lists, unless the From: address
of authorized posters might be in a domain with a DMARC or similar
policy. It is also appropriate if you choose to use
dmarc_moderation_action other than Accept for this list.
Munge From
This action replaces the poster's address in the From: header with
the list's posting address and adds the poster's address to the
Reply-To: header.
Wrap Message
Just wrap the message in an outer message with the From: header
containing the list's posting address and with the original From:
address added to the Reply-To: header and with Content-Type:
message/rfc822. This is effectively a one message MIME format digest.

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.

The Reply-To: header munging actions below interact with these actions
as follows:

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, the poster's address and the list posting
address or the poster's address and the explicit reply_to_address in the
outgoing Reply-To: header.

[Note: is the above what we want? I think so, but others are adding a
header something like X-Mailman-Originally-From: (see the "The future
options for mailing list managers" section at
)]

These actions do not apply to messages in digests or archives or sent to
usenet via the Mail<->News gateways.

If dmarc_moderation_action applies to this message with an action other
than Accept, that action rather than this is applied

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

[Mark Sapiro]

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. This could be reversed, and in
any case, I plan to make the timeouts an mm_cfg.py setting, but I think
this is an issue. It also requires installation of the 3rd party
dnspython package, and if that's not there, all messages pass. I did
build a test into configure so it will error out if dnspython isn't
installed. None of these is a show stopper for this feature, but some
may just want to apply whatever action to all messages.

The other is social. My largest and highest traffic production list is
the discussion list for my bicycle club.

If I could, I would set dmarc_moderation_action to Reject with a gentle
suggestion to find another ESP to post from, but I can't. One particular
member of the board of directors is a very vocal and not very technical
Yahoo user who I think would have a fit if her mail were "singled out"
for differing treatment, even if only that hers was munged and mine
wasn't. I have tried in the past to programmatically hold or reject "me
too" posts and others that have way more quoted that original material.
(Almost everyone top posts and quotes the entire message being replied
to.) I was forced by a few vociferous complainers who got the boards
attention to back off.

Anyway, my point is list owners don't always have the freedom to do
whatever they want. If their list serves an organization, the policies
of that organization can override good sense.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

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

[Mark Sapiro]

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). Stripping
>> happens after From munging, so this explains my issue. After disabling
>> stripping, the original sender remains in the Reply-To.
> 
> I *think* it works as you expect in 2.1.18rc3, but I'll have to double
> check.


In 2.1.18rc3 with first_strip_reply_to = Yes and reply_goes_to_list =
Poster, the poster's From: address is in Reply-To:, but not for the
other settings of reply_goes_to_list. I'm changing it for the final so
the poster's From: address will always be in Reply-To: when from_is list
is other than No.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

[Lindsay Haisley]

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, the poster's address and the list posting
> address or the poster's address and the explicit reply_to_address in the
> outgoing Reply-To: header.

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 the Reply-To: address. Yes?  If the original
poster included a Reply-To: address then DMARC forces us into a
situation in which we can't avoid information loss.  Either the poster's
Reply-To: is overwritten with the original From:, or the original
Reply-To: is retained and the original From: address is lost.  Which is
it?

-- 
Lindsay Haisley   | "Everything works if you let it"
FMP Computer Services |
512-259-1190  |  --- The Roadie
http://www.fmp.com|

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

[Stephen J. Turnbull]

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 messages when selected
 > here. To apply these actions only to messages where the domain in the
 > From: header is determined to use such a protocol, see the
 > dmarc_moderation_action settings under Privacy options... -> Sender filters.

Good!  Maybe even "encourage" use of d_m_a?

 > No
 > Do nothing special. This is appropriate for anonymous lists.

[snip]

 > 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 confusing?

 > 
 > The Reply-To: header munging actions below interact with these actions
 > as follows:
 > 
 > 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, the poster's address and the list posting
 > address or the poster's address and the explicit reply_to_address in the
 > outgoing Reply-To: header.
 > 
 > [Note: is the above what we want? I think so, but others are adding a
 > header something like X-Mailman-Originally-From:

IIUC, yes, that's what we want.  OnlineGroups has some features
Mailman doesn't (yet?) to handle the "reply munging" issue AIUI.

(1) X- fields are deprecated.  They don't actually help in creating
"private" protocols, and (not relevant to us here, I think) they
make it difficult to upgrade to the standardized version.

(2) I think this is pretty useless (with one exception), because most
MUAs won't display the information.  Even with "Show Source" (how
many AOLers use that?), you have to dig through a thicket of trace
fields and spam scores.  Better to log the information.  But why
do that when we archive the original message as received?  (In
fact, if we do this correctly it would be possible to post-archive
DKIM-verify messages!  GSoC 2015? :-)

 > (see the "The future options for mailing list managers" section at
 > )]

They don't seem to think it's terribly useful though, it's just a sort
of trace field.  BTW, that blog also says

The attackers succeeded in accessing about 20% of AOL users’ email
accounts and obtaining details of their contacts.

I hope that means that AOL is now down to the 100 Stupidest On-Line
Americans, of whom 20 were fooled  But I digress.

 > These actions do not apply to messages in digests or archives or
 > sent to usenet via the Mail<->News gateways.

Is that true of dmarc_moderation_action, too?  (I assume so and would
consider it a bug if not.)



--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

[Stephen J. Turnbull]

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 of DMARC DoS'ers that results in an email to owner).

 > If I could, I would set dmarc_moderation_action to Reject with a gentle
 > suggestion to find another ESP to post from, but I can't.

Heck, even I don't recommend that (I do it, but that's only because I
*can* -- as I've mentioned my users are all looking for excuses to
switch to GMail anyway if they haven't done so already).

 > One particular member of the board of directors is a very vocal and
 > not very technical Yahoo user who I think would have a fit if her
 > mail were "singled out" for differing treatment, even if only that
 > hers was munged and mine wasn't.

Tell her it's mandated by Yahoo! and hard-coded in Mailman (blame
Barry! and don't tell her about the Time Machine), *your* hands are
tied. :-)

 > I have tried in the past to programmatically hold or reject "me
 > too" posts and others that have way more quoted that original material.
 > (Almost everyone top posts and quotes the entire message being replied
 > to.)

But this is different: it really is censorship.  It's censorship I
agree with, it's censorship that doesn't actually infringe on freedom
of expression, but it is prohibiting certain (obnoxious) forms of
expression.

N.B. If top posting bothered me (in channels where it is customary, it
doesn't bother me any more :-), I would implement a Handler that
removes trailing quoted material and substitutes a link to the
archives (if possible to the In-Reply-To message).
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

[Andrew Partan]

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 like to use.

Andrew Partan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

[Mark Sapiro]

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 the Reply-To: address. Yes?


Yes.


> If the original
> poster included a Reply-To: address then DMARC forces us into a
> situation in which we can't avoid information loss.  Either the poster's
> Reply-To: is overwritten with the original From:, or the original
> Reply-To: is retained and the original From: address is lost.  Which is
> it?


Neither. The poster's From: address is merged with the other addresses
in the original Reply-To:. I.e. The Poster's From: address will be there
as will all the other addresses in the original Reply-To:, but there
will be no duplicates.

What do I need to change to make this clear. Note that earlier under the
Munge From action, it says "... and adds the poster's address to the
Reply-To: header" and under the Wrap Message action it says "with the
original From: address added to the Reply-To: header".

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 No we're adding to the original. Do I have
to repeat that last bit further down?

Maybe instead of "the Reply-To: header" in the two action statements, I
should say "the addresses in the original Reply-To: header". I.e. "...
and adds the poster's address to the addresses in the original Reply-To:
header" and "with the original From: address added to the addresses in
the original Reply-To: header". Does that help?

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

[Mark Sapiro]

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 confusing?


How about "... if actions other than No are applied on an anonymous
list, they will be redundant."

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

[Mark Sapiro]

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.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] 2.1.18 internal documentation suggestions

[Lindsay Haisley]

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 No we're adding to the original. Do I have
> to repeat that last bit further down?

I hadn't considered that a Reply-To: address can be plural, which makes
perfect sense.  A single sentence, perhaps just a reference to other
text, covering first_strip_reply_to = No might be in order to pair with
your explicit discussion of first_strip_reply_to = Yes.

The whole issue is complex, and the measures in Mailman to address it
are similarly complex.  Your changes to the internal docs are certainly
an improvement and probably about as good as can be done with a bad
situation.  There may be a problem with being _too_ wordy in explaining
it.

Here's a suggestion:

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, the poster's address
and the list posting address or the poster's address and the
explicit reply_to_address in the outgoing Reply-To: header.  If
first_strip_reply_to = No the poster's address in the From:
header, if not already included in the Reply-To:, will be
appended to any existing Reply-To: address(es).

Last sentence added.  Is this correct, and reasonable?


-- 
Lindsay Haisley   | "Everything works if you let it"
FMP Computer Services |
512-259-1190  |  --- The Roadie
http://www.fmp.com|

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org