Subject: Re: [TOOLS-DEVELOPMENT] DMARC and configuration of IETF mailing lists

From: "Ben Campbell" <[email-masked]>
Date: Fri, 03 Feb 2017 10:02:58 -0600

(- IESG list )

Hi Henrick,

What's the next step(s) here? Are we waiting for the MailMan update to 
do further investigation, or can some of the uncertainties be answered 
in the interim?

Thanks!

Ben.

On 24 Jan 2017, at 13:22, Alexey Melnikov wrote:

> Hi Henrik,
>
>> On 23 Jan 2017, at 16:54, Henrik Levkowetz <[email-masked]> 
>> wrote:
>>
>> Hi Alexey,
>>
>>> On 2017-01-23 12:57, Alexey Melnikov wrote:
>>> Dear tools team,
>>>
>>> The IESG continues to be concerned about the impacts of growing 
>>> usage of
>>> DMARC technology on IETF discussion lists. All choices in front of 
>>> us,
>>> including not taking any action, cause some pain, as we have not 
>>> been
>>> able to identify a perfect approach to mitigate the impacts.
>>>
>>> The situation is evolving, as email software evolves and new 
>>> features
>>> relating to DMARC also continue to be developed. The IESG believes 
>>> that
>>> we need to be aware of the effects and consider different mitigation
>>> approaches. The effects are not necessarily easy to predict based on
>>> theoretical analysis, given the wide variety of software and
>>> configurations that our participants use, and their personal 
>>> preferences
>>> among important IETF mailing list functions and avoidance of various
>>> failure modes.
>>>
>>> Robert told us that Mailman is due for an upgrade in February. This
>>> upgrade would allow IETF to run different IETF mailing lists in
>>> different configurations.
>>
>> I guess this is coupled with upgrading to OpenSUSE 42.x and gives us
>> Mailman 2.1.18 (or higher) with the DMARC handling options described
>> here: , yes?
>
> I believe so.
>
>> https://wiki.list.org/DEV/DMARC
>>
>>> The IESG would
>>> like to perform limited tests on selected lists to determine the 
>>> impacts
>>> of a couple of different possible mitigation configurations. It is
>>> important that such an experiment be carefully monitored and that 
>>> the
>>> impacted users be asked about their experiences. There are strong
>>> opinions on this matter, but the discussion of this matter has so 
>>> far
>>> involved a small subset of vocal IETFers. What matters more though 
>>> is
>>> the experience of the users as a whole.
>>>
>>> The two options that IESG would like to test are: From header field
>>> rewriting ([email-masked] would become an IETF managed forwarding
>>> alias,
>>> the exact structure is TBD(*)) and message wrapping (encapsulation 
>>> of
>>> original message inside multipart/mixed, with the original message 
>>> as
>>> message/rfc822 attachment + some explanatory text).
>>> These workarounds would only apply to email messages from domains 
>>> that
>>> publish DMARC p=reject or p=quarantine policy. Messages from domains
>>> that don't publish DMARC policy or have DMARC policy p=none are not
>>> affected by this change.
>>>
>>> In order to figure out which option has less impact on IETF
>>> participants, IESG would like to try one of them for a couple of 
>>> weeks
>>> (+ collect feedback), roll back the configuration to the current 
>>> one,
>>> then try the other one (+collect feedback) for a couple of weeks.
>>> Each experiment will run on one or more IETF mailing list.
>>>
>>> In order to achieve this, the IESG would like to do the following:
>>>
>>> 0) Publish detailed description of how two workarounds are going to 
>>> work
>>> and comparison of their side effects (both positive and negative).
>>>
>>> 1) Decide with the tools team which mailing lists to use for testing
>>> of each option. This will also need to be agreed with 
>>> managers/working
>>> group chairs
>>> of the affected mailing lists.
>>>
>>> 2) Discuss with the tools team what kind of changes (new scripts,
>>> reconfiguration, Mailman options) are needed to deploy both of 
>>> these.
>>> Agree on when they can be implemented. Publish the timeline to the 
>>> wider
>>> IETF community.
>>
>> If the features of Mailman 2.1.18 are insufficient, the start-up time
>> (writing new scripts) will be longer than otherwise.  This should 
>> maybe
>> be factored into any decision on exactly which options to try out.
>
> Right. From address rewriting will need some scripting work. John 
> Levine said that he could help (he done a version in Python for his 
> mailing list manager, which is not Mailman).
>
>> FWIW, based on what I can read out of the available mailman 2.1
>> documentation (http://www.list.org/mailman-admin.txt) the From: 
>> header
>> field rewriting considered above isn't supported by mailman directly;
>> only replacement of the From: header value with the list address (for
>> p=reject or p=quarantine domains) and placement of the original From:
>> address in Reply-To:.  So it looks as if the rewrite test option 
>> _will_
>> require both new coding and consideration of where in the email 
>> pipeline
>> the rewrite (and rewrite reversal) should be done.
>
> Right.
>
>>> 3) Design with the tools team a detailed plan of what kind of 
>>> feedback
>>> we will be looking for when evaluating results of experimental
>>> deployment
>>> of each of these options. Notify the IETF community.
>>>
>>> 4) It might be worth publishing a Wiki page describing how different
>>> email clients, email systems can be used or configured to minimize
>>> impact of workarounds.
>>>
>>> Does this look like a reasonable starting plan?
>>
>> Assuming that we can use mailman 2.1.18 features to do the rewriting/
>> wrapping, then yes, as far as I can see.  If new code is required, 
>> it's
>> still reasonable if the time and resources issue is considered.
>>
>> One more comment below:
>>
>>>
>>> Best Regards,
>>> Alexey, on behalf of IESG
>>>
>>>
>>> (*) For example, [email-masked] would become [email-masked] 
>>> and
>>> any email sent to [email-masked] would be forwarded to
>>> [email-masked].
>>> We are still discussing with Email experts how forwarding emails 
>>> might
>>> look
>>> like. Some possibilites are u=[email-masked],
>>> [email-masked].
>>
>> I'm sure the experts will provide a good suggestion.  I just note 
>> that of
>> the options above, the 'u=[email-masked]' variant 
>> will
>> not be able to handle addresses like [email-masked]
>> (multiple dots in either localpart or domain -- which dot corresponds 
>> to
>> the at sign when you reverse the address??) well if you expect to do 
>> the
>> reversal without using saved state.
>
> Right, this was just from the top of head. I don't think we want to 
> maintain any state for this. Some kind of encoding scheme would be 
> needed. Possibly replacing @ with %.
>
>
> Best Regards,
> Alexey

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 03 Feb 2017 10:09:53 -0600

Glen: Are you comfortable with the plan being discussed?

Thanks!

Ben.

On 3 Feb 2017, at 10:02, Ben Campbell wrote:

>>> (multiple dots in either localpart or domain -- which dot 
>>> corresponds to

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 3 Feb 2017 19:10:29 +0100

Hi Ben,

Strawman for next steps:

1. Code snippets from John Levine (via Alexey)
2. Figuring out where in the mail pipeline the rewriting should happen
   (Glen+Alexey+Robert+Henrik, I think)
3. Figuring out needed glue to use John's snippets (Glen, Henrik)
4. Installation of OpenSUSE 42.x (Glen, Matt)
5. Installation of glue code + snippets in conjunction with community
   notification about the experiment (Glen, Henrik)

Best regards,

	Henrik

---

From: Glen <[email-masked]>
Date: Fri, 3 Feb 2017 10:48:48 -0800

> Glen: Are you comfortable with the plan being discussed?

Hi Ben -

Thank you very much for thinking of me.  I shall try to be brief.

It seems to me that Mailman, right now (as of 2.1.16 - and we are running
2.1.17), has two very valid and useful options for handling DMARC....
(1)  From address rewriting and (2) Message encapsulation.    By providing
these options, it seems to me that Mailman has solved enough of the
problems surrounding DMARC to ensure that our list messages can be
effectively delivered to everyone on our lists, without tripping over DMARC
anymore.  Mailman has also, self-referentially, made this the "standard
behavior" for Mailman - because of the way they did it, they've set their
own standard for DMARC handling, and so this is the way "most people will
expect" Mailman to work.

So, I would suggest that testing those existing options right now could be
done without any effort on my part, or the Tools Team's part, or any
disruption.  Just pick a list and try it out.

In contrast, I am gathering that the plan being considered is much more
complex, involving scripting, program changes to Mailman, the creation and
management of an additional alias database driven by Mailman, and so
forth.  I cannot speak to the benefits of this path, but with respect to my
comfort, this worries me a bit, for several reasons.

My first concern is security.  Earlier statements were correct:  Mailman
upgrades on the IETF servers do happen as a part of OS upgrades, and also
smaller updates.  OpenSuse, as most distros do, pushes major upgrades and
minor updates to their users, which are installed automatically as they are
released.  This brings with it advantages - new features (such as the
already-available DMARC header rewriting options) are pushed to us
regularly, and security holes are closed pretty quickly by midstream
updates.  Although the frequency of these updates is low, it is non-zero,
and not something I can discount.

By going down this path, the IETF is essentially choosing to fork Mailman,
and make something new.  In order to even preserve the changes that were
made, I'll have to remove Mailman from the server repository catalogs, and
relocate the system to a different directory structure to avoid accidental
overwrites in the future.  By severing Mailman in this way, we will no
longer receive updates, and upgrades will have to be done, in essence,
manually.  This means that someone will have to start "watching" Mailman
for upgrades, and, at each upgrade step, the Tools Team will have to figure
out how their modifications mesh with the Mailman modifications, reapply
their patches and changes (possibly with modifications to the patches),
test, and then figure some way to deploy.

Since my responsibility is operations, the only way this could effectively
work for me would be to turn Mailman into something similar to the
Datatracker:  The modified Mailman should probably be stored in the Tools
SVN server, patches written by the Tools Team, tested and approved by the
TMC, and deployed to us as SNV checkouts by Henrik.  Then, whenever,
changes come out, the Tools Team (re)writes the patches, the TMC tests, and
I (re)deploy - just as we do with the Datatracker.  (And, if there are
issues, as there sometimes might be, I can "roll back" to the previous SVN
release quickly and cleanly.)

If (and, likely, only if) this is what is being considered, then, yes, I am
comfortable.  The prep and engineering work would be done by the Tools
Team, validation by TMC, and deployment by the Secretariat, just as we do
with the Datatracker now.  I would be fine with that.

But if something different is being considered, then I could not assert
comfort without knowing more about the intention.  For example, if the
intent is to just "have someone do the scripting" and then "send me some
zips to install and test", without any validation or vetting.... or if the
intent would be to have someone modify  Mailman in place because "the
changes are small" (or whatever), then, no, my response would have to be
that I am horribly uncomfortable with that, because, at the end of the day,
if we bring in some volunteer (or contractor) do "just hand us something",
then anything that goes wrong whilst the system is live, and/or any
debugging that may need to happen down the road would fall on me... and
potentially bury me.

Under those circumstances, I would not be comfortable at all.  So, knowing
more about the "operations" and deployment intent here would be most
helpful.

Too long?  Didn't read?

1. Why not try what Mailman already offers, first?  It's not
IETF-perfection, but it might be close enough to satisfy.

2. If not, then please plan carefully, and do this right:  Set up a forked
Mailman source tree (and you might as well go all the way to 2.1.23, the
latest), apply your patches and changes to that, test it thoroughly
offline, make it perfect, check it in, and then give me a Datatracker-style
SVN checkout that I can structure on the server without risk to any of us.

Under either of those two conditions, yes, I would be comfortable.
Otherwise, I'd think not.

Apologies if I'm confused or off-point (it happens often!), and thank you
again for asking me.

Glen

---

From: Glen <[email-masked]>
Date: Fri, 3 Feb 2017 10:52:18 -0800

>    notification about the experiment (Glen, Henrik)

Disclaimer:

My email was sent before I saw this - I was not ignoring it, I just hadn't
seen it.  I think my email might change this strawman significantly, but I
will defer to Henrik and the rest of you on sorting that out.

Glen

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 03 Feb 2017 15:51:04 -0600

I'm sensitive to the concern about forking MailMan from the distro 
version. Am I correct to assume the existing From: rewriting capability 
is the limited version that Henrik mentioned? That is, are we agreed 
that code changes are required for the plan that Alexey described? (Not 
to question Henrik--I just want to make sure we are all on the same 
page.)

Thanks!

Ben (As IESG tools liaison).

---

From: Robert Sparks <[email-masked]>
Date: Fri, 3 Feb 2017 16:02:14 -0600

Alexey should weigh in with more detail, but the essence is that 
(extensive) community discussion has already shown that the rewriting 
functionality that is in mailman is not sufficient on its own. It 
results in (at least) a corruption of recipient's address books that the 
community will not accept. The additional rewriting code and the 
maintenance of the aliases proposed is what is being proposed to solve 
that problem.

Alexey - could you point Glen to a summary of the discussions that show 
_why_ we can't simply use mailman as distributed, and point out the 
other consequences I'm sure I've elided?

RjS

On 2/3/17 3:51 PM, Ben Campbell wrote:
> version. Am I correct to assume the existing From: rewriting 
> capability is the limited version that Henrik mentioned? That is, are 
> we agreed that code changes are required for the plan that Alexey 
> described? (Not to question Henrik--I just want to make sure we are 
> all on the same page.)
>
> Thanks!
>
>     On Fri, Feb 3, 2017 at 8:09 AM, Ben Campbell <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     It seems to me that Mailman, right now (as of 2.1.16 - and we are
>     running 2.1.17), has two very valid and useful options for
>     handling DMARC....   (1) From address rewriting and (2) Message
>     encapsulation.    By providing these options, it seems to me that
>     Mailman has solved enough of the problems surrounding DMARC to
>     ensure that our list messages can be effectively delivered to
>     everyone on our lists, without tripping over DMARC anymore. 
>     Mailman has also, self-referentially, made this the "standard
>     behavior" for Mailman - because of the way they did it, they've
>     set their own standard for DMARC handling, and so this is the way
>     "most people will expect" Mailman to work.
>
>     So, I would suggest that testing those existing options right now
>     could be done without any effort on my part, or the Tools Team's
>     part, or any disruption. Just pick a list and try it out.
>
>     In contrast, I am gathering that the plan being considered is much
>     more complex, involving scripting, program changes to Mailman, the
>     creation and management of an additional alias database driven by
>     Mailman, and so forth.  I cannot speak to the benefits of this
>     path, but with respect to my comfort, this worries me a bit, for
>     several reasons.
>
>     My first concern is security.  Earlier statements were correct: 
>     Mailman upgrades on the IETF servers do happen as a part of OS
>     upgrades, and also smaller updates.  OpenSuse, as most distros do,
>     pushes major upgrades and minor updates to their users, which are
>     installed automatically as they are released.  This brings with it
>     advantages - new features (such as the already-available DMARC
>     header rewriting options) are pushed to us regularly, and security
>     holes are closed pretty quickly by midstream updates.  Although
>     the frequency of these updates is low, it is non-zero, and not
>     something I can discount.
>
>     By going down this path, the IETF is essentially choosing to fork
>     Mailman, and make something new.  In order to even preserve the
>     changes that were made, I'll have to remove Mailman from the
>     server repository catalogs, and relocate the system to a different
>     directory structure to avoid accidental overwrites in the future. 
>     By severing Mailman in this way, we will no longer receive
>     updates, and upgrades will have to be done, in essence, manually. 
>     This means that someone will have to start "watching" Mailman for
>     upgrades, and, at each upgrade step, the Tools Team will have to
>     figure out how their modifications mesh with the Mailman
>     modifications, reapply their patches and changes (possibly with
>     modifications to the patches), test, and then figure some way to
>     deploy.
>
>     Since my responsibility is operations, the only way this could
>     effectively work for me would be to turn Mailman into something
>     similar to the Datatracker: The modified Mailman should probably
>     be stored in the Tools SVN server, patches written by the Tools
>     Team, tested and approved by the TMC, and deployed to us as SNV
>     checkouts by Henrik.  Then, whenever, changes come out, the Tools
>     Team (re)writes the patches, the TMC tests, and I (re)deploy -
>     just as we do with the Datatracker.  (And, if there are issues, as
>     there sometimes might be, I can "roll back" to the previous SVN
>     If (and, likely, only if) this is what is being considered, then,
>     yes, I am comfortable.  The prep and engineering work would be
>     done by the Tools Team, validation by TMC, and deployment by the
>     Secretariat, just as we do with the Datatracker now.  I would be
>     fine with that.
>
>     But if something different is being considered, then I could not
>     assert comfort without knowing more about the intention.  For
>     example, if the intent is to just "have someone do the scripting"
>     and then "send me some zips to install and test", without any
>     validation or vetting.... or if the intent would be to have
>     someone modify  Mailman in place because "the changes are small"
>     (or whatever), then, no, my response would have to be that I am
>     horribly uncomfortable with that, because, at the end of the day,
>     if we bring in some volunteer (or contractor) do "just hand us
>     something", then anything that goes wrong whilst the system is
>     live, and/or any debugging that may need to happen down the road
>     would fall on me... and potentially bury me.
>
>     Under those circumstances, I would not be comfortable at all.  So,
>     knowing more about the "operations" and deployment intent here
>     would be most helpful.
>
>     Too long?  Didn't read?
>
>     2. If not, then please plan carefully, and do this right:  Set up
>     a forked Mailman source tree (and you might as well go all the way
>     to 2.1.23, the latest), apply your patches and changes to that,
>     test it thoroughly offline, make it perfect, check it in, and then
>     give me a Datatracker-style SVN checkout that I can structure on
>     the server without risk to any of us.
>
>     Under either of those two conditions, yes, I would be
>     comfortable.  Otherwise, I'd think not.
>
>     Apologies if I'm confused or off-point (it happens often!), and
>     thank you again for asking me.
>
>     Glen
>
>
>
>
>
>
> _______________________________________________
> TOOLS-DEVELOPMENT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-development

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 3 Feb 2017 23:09:57 +0100

Hi Glen,

(I saw your later post, but thought I'd respond to what you write below):

My current understanding is as follows (it could be wrong): The IESG
wishes to perform 2 experiments on a small number of mailing lists.
One of the experiments requires Mailman 2.1.18, because only with that
release can the desired settings be applied to individual mailing lists,
rather than as a global setting.  The other experiment requires a script
or script external to Mailman to rewrite some header fields.  The rewrites
will be statelessly reversible, so will not require any database or other
backing store.

With these limitations, the experiments makes sense to me, and I think they
also fit within the limits you mention below.

On my part, I'm happy to modify the ideas I have of how to implement the
proposed experiments in any way needed to fit your security and stability
requirements.

Best regards,

	Henrik

---

From: Glen <[email-masked]>
Date: Fri, 3 Feb 2017 14:30:34 -0800

Robert, Alexey -

There's no need for that, thanks though.  Robert's statement is more than
sufficient for me.  I don't necessarily need to know the "why" in any event
- only the "how".  :-)

That said, if the community will not accept Mailman's default activity,
then perhaps it's more appropriate to consider this as a set of patches we
should submit back to Mailman.  Is the IETF community "special"?  Or do
their views seem relevant to the larger Mailman user base?  If the latter,
I would guess that a contribution of the final outcome back to Mailman
would be desirable.

(And of course doing it that way might eliminate concerns about forking, as
our changes would presumably be "Worked in" to the next Mailman release and
become mainstream.)

Anyway - nobody needs to sell me on anything - I will do my best to support
anything regardless of the "Why".  :-)

Glen

On Fri, Feb 3, 2017 at 2:02 PM, Robert Sparks <[email-masked]> wrote:

> functionality that is in mailman is not sufficient on its own. It results
> in (at least) a corruption of recipient's address books that the community
> will not accept. The additional rewriting code and the maintenance of the
> aliases proposed is what is being proposed to solve that problem.
>
> _why_ we can't simply use mailman as distributed, and point out the other
> consequences I'm sure I've elided?
>
> RjS
>
> version. Am I correct to assume the existing From: rewriting capability is
> the limited version that Henrik mentioned? That is, are we agreed that code
> changes are required for the plan that Alexey described? (Not to question
> Henrik--I just want to make sure we are all on the same page.)
>
> Thanks!
>
> If (and, likely, only if) this is what is being considered, then, yes, I
> am comfortable.  The prep and engineering work would be done by the Tools
> TOOLS-DEVELOPMENT mailing [email-masked]://www.ietf.org/mailman/listinfo/tools-development
>
>
>

---

From: Glen <[email-masked]>
Date: Fri, 3 Feb 2017 14:40:40 -0800

All -

Apologies.  My mail volume is high, and I process at intervals, and in
linear fashion only, usually.  Sorry.

Hi Henrik -

> will be statelessly reversible, so will not require any database or other

This all sounds excellent. So if I understand you, we're not actually
patching the Mailman source tree for either of the IETF's desired
experiments here.  That would mean that we don't have to fork, and my
earlier thoughts on SVN, et al, are irrelevant.  That would be a much
happier outcome for me.

> proposed experiments in any way needed to fit your security and stability

Thank you.  If you're comfortable, I'm comfortable, so let's proceed.

Here is the situation on my end:

We've upgraded Ryan's development server, and the Sandbox server, to
OpenSuse 42.2 (the latest, as mentioned previously) which includes
Mailman 2.1.22.

I'm going to do "ietfc" (the "unofficial second" hot backup machine) this
weekend.  Ryan and Matt will have that machine starting Monday to test and
check.  I hope to hear a good report from them soon (within the week) and
do "ietfb" (the Orlando/main hot backup) the following weekend, with the
same subsequent test and check by them.

If all goes well, I will report back to the TMC with a summary of our
experiences, and an assumption of readiness, so that we can schedule the
production machine.  I am guessing, if all goes well, we can do that update
live and in place on Monday the 20th, or Monday the 27th, depending on how
everything else goes.

I hope this answers everything.  Thanks to you and Ben and everyone for
your support!

Best regards,
Glen

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 06 Feb 2017 19:25:07 +0000

Hi,

On Fri, Feb 3, 2017, at 10:02 PM, Robert Sparks wrote:

> results in (at least) a corruption of recipient's address books that
> the community will not accept. The additional rewriting code and the
For the "From rewriting" workaround, we will need alias maintenance
scripts. For "message wrapping" we would (ideally) need to modify 1
Python file in Mailman to change the list of header fields preserved in
the outer message. (The changes to Mailman are small and we can try
submitting them back to Mailman.)

> Alexey - could you point Glen to a summary of the discussions that
> show _why_ we can't simply use mailman as distributed, and point out
> the other consequences I'm sure I've elided?
I can dig out more details.

>>> running 2.1.17), has two very valid and useful options for handling
>>> DMARC....   (1)  From address rewriting and (2) Message
>>> everyone on our lists, without tripping over DMARC anymore.  Mailman
>>> has also, self-referentially, made this the "standard behavior" for
>>> Mailman - because of the way they did it, they've set their own
>>> standard for DMARC handling, and so this is the way "most people
>>> will expect" Mailman to work.
>>> 

>>> Mailman, and so forth.  I cannot speak to the benefits of this path,
>>> but with respect to my comfort, this worries me a bit, for several
>>> reasons.
>>> 

>>> holes are closed pretty quickly by midstream updates.  Although the
>>> frequency of these updates is low, it is non-zero, and not something
>>> I can discount.
>>> 

>>> changes that were made, I'll have to remove Mailman from the server
>>> repository catalogs, and relocate the system to a different
>>> By severing Mailman in this way, we will no longer receive updates,
>>> and upgrades will have to be done, in essence, manually.  This means
>>> that someone will have to start "watching" Mailman for upgrades,
>>> and, at each upgrade step, the Tools Team will have to figure out
>>> how their modifications mesh with the Mailman modifications, reapply
>>> their patches and changes (possibly with modifications to the
>>> patches), test, and then figure some way to deploy.
>>> 

>>> similar to the Datatracker:  The modified Mailman should probably be
>>> stored in the Tools SVN server, patches written by the Tools Team,
>>> tested and approved by the TMC, and deployed to us as SNV checkouts
>>> by Henrik.  Then, whenever, changes come out, the Tools Team
>>> (re)writes the patches, the TMC tests, and I (re)deploy - just as we
>>> do with the Datatracker.  (And, if there are issues, as there
>>> sometimes might be, I can "roll back" to the previous SVN release
>>> quickly and cleanly.)
>>> 

>>> yes, I am comfortable.  The prep and engineering work would be done
>>> by the Tools Team, validation by TMC, and deployment by the

>>> validation or vetting.... or if the intent would be to have someone
>>> modify  Mailman in place because "the changes are small" (or
>>> whatever), then, no, my response would have to be that I am horribly
>>> uncomfortable with that, because, at the end of the day, if we bring
>>> in some volunteer (or contractor) do "just hand us something", then
>>> anything that goes wrong whilst the system is live, and/or any
>>> debugging that may need to happen down the road would fall on me...
>>> and potentially bury me.
>>> 

>>> knowing more about the "operations" and deployment intent here would
>>> be most helpful.
>>> 

>>> 1. Why not try what Mailman already offers, first?  It's not IETF-
>>>    perfection, but it might be close enough to satisfy.
>>> 

>>> 2. If not, then please plan carefully, and do this right:  Set up a
>>>    forked Mailman source tree (and you might as well go all the way
>>>    test it thoroughly offline, make it perfect, check it in, and
>>>    then give me a Datatracker-style SVN checkout that I can
>>>    structure on the server without risk to any of us.
>>> 

>>
>> _______________________________________________ TOOLS-DEVELOPMENT
>> mailing list [email-masked]

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 06 Feb 2017 19:27:43 +0000

Hi Henrik,

>    notification about the experiment (Glen, Henrik)

Would you like to decide on some dates for the above and maybe we need
to have some conference calls to discuss finer details?

Thank you,
Alexey

> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 7 Feb 2017 13:52:06 +0100

Hi Alexey,

> to have some conference calls to discuss finer details?

I just sent out a poll for a conference call to discuss item 2 above.  I
assume you'll nudge John re. 1, and forward the code when available.  Item
3 should follow.  4 is up to Glen and Matt; I think they already sent a
tentative timeline.  5 will depend on the rest, of course.

Best regards,

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 7 Feb 2017 17:07:38 +0100

Hi Alexey,

> tentative timeline.  5 will depend on the rest, of course.

I just closed the poll with this choice (Friday 10th, 20:00 CET, which should
be 11 am PST and 13 am CST:  http://doodle.com/poll/vaxnhrvfcvut8myh

Alexey, can you arrange for a WebEx meeting at that time, and send invites?

Best regards,

	Henrik

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 10 Feb 2017 14:54:03 +0000

> Alexey, can you arrange for a WebEx meeting at that time, and send

Sorry, setting the WebEx now.

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 10 Feb 2017 16:30:26 +0100

> Sorry, setting the WebEx now.

Thank you!

	Henrik

---

From: Glen <[email-masked]>
Date: Fri, 10 Feb 2017 10:09:27 -0800

Alexey,

I would like to ask that we include Matt Larson (also from AMS) in
this call, as he is familiar with the mail handling we already
perform.

I've forwarded the Webex invite to him but if any additional
permissions are needed, could those please be set?

Thank you so much!

Glen

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 10 Feb 2017 18:12:50 +0000

Hi Glen,

> this call, as he is familiar with the mail handling we already

No problems!

> permissions are needed, could those please be set?

I think he just uses the link as everybody else.