Page MenuHomePhabricator

add aliases to catch two main corp mailing lists with specified without 'lists'
Closed, DeclinedPublic


Exim alias config change: (2 lines)


These are similar to the existing aliases:

Group aliases


Event Timeline

JKrauska raised the priority of this task from to Needs Triage.
JKrauska updated the task description. (Show Details)
JKrauska added a project: acl*sre-team.
JKrauska added a subscriber: JKrauska.
Restricted Application added subscribers: Matanya, Aklapper. · View Herald TranscriptJul 27 2015, 8:01 PM
Krenair added subscribers: chasemp, greg, valhallasw.
Krenair added a subscriber: Krenair.

I tried to find the relevant lines from #wikimedia-operations earlier:

Jul 27 18:24:54 <cajoel>	does our exim config try sending to a mailman list if the end address doesn't work?
Jul 27 18:25:24 <cajoel>	meaning, if I try to email, will it attempt delivery to as a last resort default?
Jul 27 18:25:49 <cajoel>	and if it doesn't, what would you think of me adding those as aliases to direct?
Jul 27 18:26:03 <JohnFLewis>	I don't believe so. I'd imagine it'll get bounced or sent to roots
Jul 27 18:26:34 <JohnFLewis>	they can be added but they'll be auto-moderated if they're not added to the list config /me finds the exact name
Jul 27 18:26:40 <chasemp>	cajoel: no it doesn't
Jul 27 18:27:01 <cajoel>	would an exim alias resolve this?
Jul 27 18:27:24 <chasemp>	I don't know what the problem is? people emailing the wrong address?
Jul 27 18:28:30 <JohnFLewis>	cajoel: an exim alias would though what chasemp said. anyhow, it'll need to be added to<listname>/?VARHELP=privacy/recipient/acceptable_aliases for it to be accepted by mailman otherwise it'll bounce or be held in mod
Jul 27 18:28:48 <cajoel>	I could do that.
Jul 27 18:29:24 <cajoel>	chasemp: it's a little complicated, but yes, I'd like to catch accidental deliveries to the address without the lists.
Jul 27 18:41:26 <chasemp>	cajoel: IDK man, obfuscating mailing list interaction doesn't seem good? I don't understand the use case, seems social and good luck :)
Jul 27 18:43:23 <greg-g>	cajoel: chasemp it'd also confuse the distinction between google hosted "lists" and our mailman lists
Jul 27 18:43:29 <greg-g>	I'd vote no
Jul 27 18:45:02 <valhallasw`cloud>	cajoel: aliasing sounds a bit dangerous, but a 'hey, this user is unknown, but maybe you meant this mailing list:' kind of reply could work?
Jul 27 18:54:42 <cajoel>	valhallasw`cloud: I would be interested in making this change only for 2 lists which are WMF specific.
Jul 27 18:54:46 <cajoel>	wmfall and wmfsf
Jul 27 18:58:43 <JohnFLewis>	cajoel: I see no technical issue with it though there seems to be a social issue. mailman handles aliasing already and it's capable of it. assuming that change is done, everything will work fine :)


The ask seems to directly mimic the exiting groups alias for ops@.
I feel like it's a low bar to ask for the same treatment.

There's a secondary reasoning here, which get's a little complex.
But for the record:

I am creating 'mirror' groups in Google groups that are exactly copies of the mailman memberships.

Before you get outraged, these lists WILL NOT be setup for posting (email) capabilities. Mailman will continue to do that job.

The use case for these google groups is for Calendar invites.

Please see the calendar invite Lisa just sent (7.27) out to WMFAll, it's effectively useless to anyone on WMFAll because you cannot respond to it as your own user.

Google Calendar app, auto expands any Google group you invite to a calendar invite, sending single invites to all members.

My original intent was to create wmfall-invitations@ as a google group, and that works, but then people have to remember '-invitations'.

A much more slight of hand technique would be to simply create the Google Group using the same name 'wmfall'.

Using the same name would allow for automatic expansion in calendar events, and having the exim alias would catch if someone accidentally tried to email (as opposed to a not quite obvious bounce from Google Groups saying that 'you cannot post to this group'.)
I intend to not list wmfall in the google directory (auto complete), but I wanted to protect cases where someone /thought/ they might be emailing wmfall@lists, but instead sent to wmfall@

That's the whole story.



The 'prior art' got turned in to markup in the description.


Close task -- agreed name overload is too confusing, and not that important.

Naming google groups like this


JKrauska closed this task as Declined.Jul 28 2015, 8:24 PM
JKrauska set Security to None.

To me it sounded like you had a reasonable request, but your choice...