Subject: [Tools-discuss] Wondering about moving some aliases to be real lists

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 19 Sep 2014 10:44:08 +0100

Hi,

In RTG we have been happily using [email-masked] as a good communication
tool for the chairs to share information and ideas. However, this is an alias
not a list, so there is no archive.

We're wondering about migrating to an archived list with restricted membership
and limited access to the archive. 

Does anyone have any thoughts for or against?
One question is whether the membership of a mailman list can be automated.
Consider, for example, that the IESG list is manually updated as IESG members
come and go.

Thanks,
Adrian

---

From: Dave Crocker <[email-masked]>
Date: Fri, 19 Sep 2014 05:54:41 -0700

On 9/19/2014 2:44 AM, Adrian Farrel wrote:
> However, this is an alias

There are a number of other, standard, role-based addresses, such as the
one for i-d authors.  Once we start archiving one of these, it's worth
considering archiving all of them.

Just for completeness:  A counterpoint is that we aren't very consistent
about actually /using/ role addresses.  So mail that is sent to the
personal address of a chair of course won't get archived.  I don't see
any solution to that, and I suspect there shouldn't be one...

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Robert Sparks <[email-masked]>
Date: Fri, 19 Sep 2014 10:07:05 -0500

> Does anyone have any thoughts for or against?
Just one. If something sent to this list really _needs_ archiving, would 
it be better
sent to the area list instead?

Ok two : we're in the 'proliferation of lists' swing of a pendulum 
that's made many cycles.
When the backswing comes, is this something you would defend as a 
separate archived list,
or would you give in and let it be consolidated with something else?
> One question is whether the membership of a mailman list can be automated.
Probably, but there would be some non-trivial initial effort, and, I 
expect, discovery of surprising edge cases along the way.
(The mechanic is the sync-members command at 
http://www.gnu.org/software/mailman/site.html)

A group like a rtg-chairs would be a better group than the IESG to start 
experimenting with.

---

From: Thomas Narten <[email-masked]>
Date: Mon, 22 Sep 2014 09:11:21 -0400

Please migrate to a proper mailing list.

One minor annoyance I have with the current setup is that it adds a
"Resent-To" header line that lists the individual addresses that
rtg-chairs expands to. That means having to special-case procmail
rules in some cases for such pseudo-lists. :-(

Thomas

And, the individual addresses
At Fri, 19 Sep 2014 10:44:08 +0100, Adrian Farrel wrote:
> Tools-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-discuss
> 
> Please reports datatracker.ietf.org bugs at http://tools.ietf.org/tools/ietfdb
> Please reports tools.ietf.org bugs at http://tools.ietf.org/tools/issues or
> send email to [email-masked]
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 22 Sep 2014 09:15:32 -0400

I would really rather not have it be the case that [email-masked] be
archived.  My personal mail store works well enough, and there's no
confusion as to whether it's public or not.

Adrian: Why is it that the IETF needs to archive these messages for
you, as opposed to you keeping a local copy?

Also, +1 to Robert's point that if it's important enough to be
archived, it's important enough to be on a list.

On Fri, Sep 19, 2014 at 11:07 AM, Robert Sparks <[email-masked]> wrote:
> Just one. If something sent to this list really _needs_ archiving, would it
> be better
> Ok two : we're in the 'proliferation of lists' swing of a pendulum that's
> made many cycles.
> When the backswing comes, is this something you would defend as a separate
> archived list,
> Probably, but there would be some non-trivial initial effort, and, I expect,
> discovery of surprising edge cases along the way.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 22 Sep 2014 09:34:57 -0400

> confusion as to whether it's public or not.

It's not just about the archive, I think.
It's also that DMARC fallout is impossible to mitigate when it is an alias.

---

From: Richard Barnes <[email-masked]>
Date: Mon, 22 Sep 2014 10:05:41 -0400

Can you expand on this, for someone unfamiliar with DMARC?

---

From: Michael Richardson <[email-masked]>
Date: Mon, 22 Sep 2014 13:35:44 -0400

> Can you expand on this, for someone unfamiliar with DMARC?

Nor am I.
Just a victim.
https://mailarchive.ietf.org/arch/search/?q=DMARC+ietf&f_list=ietf&gbt=1

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Richard Barnes <[email-masked]>
Date: Mon, 22 Sep 2014 15:43:18 -0400

Maybe I'm being dense here, but I don't see anything in that thread
about DMARC having problems with aliases.

--Richard

---

From: Dave Crocker <[email-masked]>
Date: Mon, 22 Sep 2014 13:25:56 -0700

> It's also that DMARC fallout is impossible to mitigate when it is an alias.

Typical email aliasing mechanisms do not change the message (header +
body).  Rather they merely replace the rfc5321.RcptTo command address.
As such, DKIM signatures should survive.

Mailing lists mess with the message text and, therefore, /do/ break DKIM
signatures.

So while aliasing isn't the same as pure relaying, it's very close,
since it only message with a part of the SMTP envelope.

SPF authentication won't survive aliasing, but DKIM signing should.

d/

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Sep 2014 09:48:29 -0400

> SPF authentication won't survive aliasing, but DKIM signing should.

And DMARC is about both.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 23 Sep 2014 07:17:34 -0700

> yeah, but they change which IP address is sending the message with the given From:

DKIM has nothing to do with the IP address.

And, by the way, it also really has nothing to do with any other message
field, such as From.

>     > SPF authentication won't survive aliasing, but DKIM signing should.

DMARC is about /either/.  It does not require both. A valid DKIM
signature for a domain that aligns with the rfc5322.From field's domain
is sufficient.

d/

---

From: Benoit Claise <[email-masked]>
Date: Sun, 28 Sep 2014 14:06:14 +0200

Adrian,

In OPS, we had both [email-masked] and a list. We discovered some 
inconsistencies between the two.
ops-chairs is auto-generated, and always right. In the end, we removed 
the list.
Bottom line: make sure they're consistent ... or maybe the trick is to 
have a new list, with a single member [email-masked]?

Regards, Benoit

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 28 Sep 2014 20:01:51 +0100

I just spent 10 seconds going "Oh Benoit is so smart. Damn! Why didn't I think
of that"
Then I remembered the archive problem - we want the archives to be closed to all
but list members, but we *do* want the list members to be able to see them.

<sigh>

I guess normal service has been restored - Benoit is as dumb as I am ;-)

A

> -----Original Message-----
> From: Benoit Claise [mailto:[email-masked]]
> Sent: 28 September 2014 13:06
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Wondering about moving some aliases to be real lists
> 
> Adrian,
>

---

From: Benoit Claise <[email-masked]>
Date: Sun, 28 Sep 2014 21:54:35 +0200

Happy to help brother :-)

B.
> .

---

From: Dave Crocker <[email-masked]>
Date: Mon, 29 Sep 2014 08:30:57 -0700

> but list members, but we *do* want the list members to be able to see them.

Do you want the archive open to only /current/ list members, or to
anyone who has ever been a member?

The former might sound more naturally reasonable, but note that means
new folk will have access to earlier archive entries from previous
members, but those earlier folk won't have access to more recent postings.

So, what is the management/privacy justification for that particular
restriction model?  Or any other particular model?

In addition, over time, the number of people who will have been members
gets quite large, which starts approximating 'everyone'.  This, too,
raises the question of what the actual privacy model is and why?

If privacy of the group's communications is of meaningful concern, this
probably requires an archive model that has a fresh archive for every
cycle of membership.

And that, of course, leaves the question of who gets to see earlier
versions of the archive...

d/

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 29 Sep 2014 16:35:25 +0100

This is a good point, and means that Benoit's proposal might do the trick.

> From: Dave Crocker [mailto:[email-masked]]
> Sent: 29 September 2014 16:31
> To: [email-masked]; 'Benoit Claise'; [email-masked];
[email-masked]
> Subject: Archive access models - Re: [Tools-discuss] Wondering about moving
> some aliases to be real lists
>