incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <>
Subject Re: [Proposal] Shutting down legacy OOo mailing lists
Date Tue, 25 Oct 2011 18:22:14 GMT
Hi Rob,

On Oct 25, 2011, at 7:27 AM, Rob Weir wrote:

> On Mon, Oct 17, 2011 at 11:35 AM, Dave Fisher <> wrote:
> <snip>
>> In the three to four weeks that it will take to get to step (7) AOOo and Apache Infra
should have control over the MX records. An easier alternative would be to
decide what MX services we want to continue on and do the MX migration at this
point. Even if it will bounce and/or forward email.
> Can we talk through that option a little more?  Take a legacy list
> like  If we try to handle this via the MX
> record, then that applies to the entire domain, all mailing lists as
> well as forwarding email account at  Is that correct?
> In other words, the MX record is at the level of, not
> at the level of

Correct. It is the whole domain.

> So in the MX approach, is there any way to do a more gradual
> migration, or do we need to do it all at once, including the
> forwarding accounts?  I know for web traffic, there is some
> flexibility at the subdomain level.  But these are all the same
> domain, just differing by account.

When we leave Kenai/Oracle and move to ASF we are doing it all at once. In advance we will
need to tell Infrastructure what forwarders and mailboxes we require. They'll tell us if there
are any mailboxes (like postmaster) that we might be required to monitor (could be none.)

If securityteam@oo.o becomes a forwarder then that is one mailbox we don't need.

> Suppose there is some way to get over that.  Then we could create
> identically named (or predictably mappable) equivalent lists using
> ezmlm.  But since we're not able to automatically sign users up, the
> traffic forwarding would all end up in the moderator queues.  Of
> course, these could be passed through.  We could even white list the
> addresses.  (or black list in the case of spammers)  But it doesn't
> get people signed up on the ezmlm list.
> Where this might be useful is for cases where a legacy email list
> address is on a third party page, or maybe even in our own legacy list
> archives.  Someone does a Google search and sees something that says,
> "If you run into this problem, please send an email to
>".  Some degree of forwarding for these emails would
> ensure such users don't get lost.
> But we can't simple forward * to a
> ooo-legacy-bucket.i.a.o email list, since many of the *
> are personal forwarding addresses and contain personal content.  And
> some lists are private lists.  So any forwarding scheme would need to
> be very sensitive to these details and would likely need an actual
> enumeration of the 300 or so lists and the unknown number of official
> contact emails (webmaster, etc.) that we want to forward.

Your excursion into hypotheticals has led you back to reality. We have a table of forwarders
and we ask Apache Infrastructure to implement it as part of hosting's MX.

The only question is if we need any mailboxes.

I think we have to either keep a set of personal OOo forwarders ala forwarders,
or none at all. Forwarders not kept will bounce. It is possible that we can control of the
550 (?) unknown user bounce message. We'll need to ask Infrastructure about it.

We decided earlier not to keep personal forwarders.

We could make it so all the committers on AOOo could have forwarders to their addresses which then forward where selected.

> Do you see that path in a similar way?  Or do you see a simpler way of
> doing that?

Without the digression, yes, similar, but with the added question about real mailboxes.


> -Rob

View raw message