Page MenuHomePhabricator

Tool Labs: Provide working mail addresses for users and service groups
Closed, ResolvedPublic

Description

From https://www.mediawiki.org/wiki/Wikimedia_Labs/Tool_Labs/Needed_Toolserver_features

"Uncertain how this is going to happen, but planned to find a way. For WMF, this is a legal question rather than a technical one. Main question: Which domain?" -- Silke WMDE (talk) 10:27, 7 April 2013 (UTC)

What is needed?

The default destination for projects could be a project-local mail box or all project users.

As a workaround, project mailing lists can be created as normal mailing lists. However, this takes a while...


Version: unspecified
Severity: major

Details

Reference
bz58796

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 2:15 AM
bzimport added a project: Toolforge.
bzimport set Reference to bz58796.

MZMcBride, please be careful with mass changes. This bug is about mail addresses for users and tools in the Tools/Tool Labs/whatever project, not a general solution for all projects in Wikimedia Labs.

Hi WMF, any status update on this?

dr.trigon wrote:

I need mail for DrTrigonBot and I would be happy if we could test this at some point BEFORE shutting down the toolserver. Thanks

(In reply to comment #3)

I need mail for DrTrigonBot and I would be happy if we could test this at
some
point BEFORE shutting down the toolserver. Thanks

Just to clarify the scope of this bug: Outgoing mail is already working perfectly, this bug is about providing incoming mail addresses/forwarders that are reachable from the InterNet.

To update matters:

This has been cleared by legal, and we now have a definite architecture. Incoming mail should arrive shortly after the migration of Labs to eqiad with the following functionality:

mail to <shelluser>@<project>.wmflabs.org will be forwarded to the email address of the user specified on Wikitech (as in 'email this user').

mail to <servicegroup>-maintainers@<project>.wmflabs.org will be forwarded to the email addresses of all the service group members as above.

Future functionality (soon after) will be to provide a per-service-group forwarding address through Wikitech (for redirecting to mailing lists, etc).

Supporting DrTrigon - this has high priority after the migration of Labs.

dr.trigon wrote:

Thanks for all comments!

I have following scenario: on TS (according to [1]) configuration involves the file '$HOME/.forward subster' that contains:
> ~/data/subster/mail_inbox
in order to enable mail (mbox style) storage in given file for address:
drtrigon [email protected]
Can I do the same here (already)? What would be the mail address? drtrigon [email protected], right? Is there a manual?

[1] https://wiki.toolserver.org/view/Mail

Another question is what happens to TS mail addresses after official shutdown? I think they should stay valid (forever), resp. be delivered or forwarded to users here. We need a transition period of appropriate duration - I think at least a year - in order to inform all involved external users and update all configurations.

dr.trigon wrote:

What is the current status?

I REALLY NEED THIS BEFORE TS goes down! Since today I not able to login to TS anymore and the cgi interface is down, see e.g. [1]. What happens here???

[1] http://toolserver.org/~drtrigon/cgi-bin/panel.py

This should be coming, I expect, in a week or so.

(In reply to DrTrigon from comment #7)

I have following scenario: on TS (according to [1]) configuration involves
the file '$HOME/.forward subster' that contains:
> ~/data/subster/mail_inbox
in order to enable mail (mbox style) storage in given file for address:
drtrigon [email protected]
Can I do the same here (already)? What would be the mail address?
drtrigon [email protected], right? Is there a manual?
[...]

The basic mail system seems to have been set up (cf. labs-l), but AFAIUI local storage is neither allowed nor possible. I have seen some talk about a grid-enabled procmail, but no code yet.

What is your use case for drtrigon [email protected]?

There is now support for sending incoming mail to a process. I'm debugging an issue with it, and will document it shortly.

ETA first week of April, according to office hour.

dr.trigon wrote:

(In reply to Marc A. Pelletier from comment #13)

This is now working, as documented at:

https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/Help#Email

It tried it yesterday by setting up ~/.forward.subster containing:

jmail cat > ~/data/subster/mail_inbox_test

This does not seam to work - if I try to send a mail to [email protected] I do not receive the mail but it bounces with following error:
Diagnostic-Code: smtp;400 4.4.7 Message delayed

Is the mail server running? What am I doing wrong?

Opened bug #63702 for the issue in comment #14.

dr.trigon wrote:

(In reply to Tim Landscheidt from comment #15)

Opened bug #63702 for the issue in comment #14.

Thanks!

dr.trigon wrote:

I re-opened this bug since for me it was NEVER solved: "Provide WORKING mail addresses ..." this system was never working for me - just because it is supposed to be working does not mean it works.

(In reply to DrTrigon from comment #17)

I re-opened this bug since for me it was NEVER solved: "Provide WORKING mail
addresses ..." this system was never working for me - just because it is
supposed to be working does not mean it works.

I'm not going to engage in an edit war here, but mail addresses *are* working. I wrote in comment #10:

[...]
The basic mail system seems to have been set up (cf. labs-l), but AFAIUI
local storage is neither allowed nor possible. I have seen some talk about

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

a grid-enabled procmail, but no code yet.

And I did not receive any answer for my question:

What is your use case for drtrigon [email protected]?

But despite (!) this, using "|jmail cat > /data/project/wikilint/mailbox" as /data/project/wikilint/.forward.subster perfectly stores incoming mail to [email protected] at the specified location (though I didn't assume that it would even work as it uses a shell redirection and [[wikitech:Nova Resource:Tools/Help#Processing email programatically]] spoke only of "program" without any shell syntax or arguments).

So by all accounts, this bug is fixed for me.

Reclosing, let's just use the other bug for the remaining issue.

dr.trigon wrote:

(In reply to Tim Landscheidt from comment #18)

(In reply to DrTrigon from comment #17)

I re-opened this bug since for me it was NEVER solved: "Provide WORKING mail
addresses ..." this system was never working for me - just because it is
supposed to be working does not mean it works.

I'm not going to engage in an edit war here, but mail addresses *are*
working. I wrote in comment #10:

[...]
The basic mail system seems to have been set up (cf. labs-l), but AFAIUI
local storage is neither allowed nor possible. I have seen some talk about

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

a grid-enabled procmail, but no code yet.

And I did not receive any answer for my question:

What is your use case for drtrigon [email protected]?

It's a pitty but the mail adresses are not working for me, as written in bug 63702 neither the tool nor the user addresses work for me.

The question you asked got overseen by my - sorry for that. On the toolserver I have drtrigon [email protected] as a mail address where every mail gets piped to ~/data/subster/mail_inbox in order to serve as an additional data source to be processed by some distinct bot later on. (As this works on the toolserver this has to work here too! ;)
The "use case" is that people, organistations, institutions, etc. that do not want to share some data (like world rankings etc.) in the puplic are still able to share the data with us.

But despite (!) this, using "|jmail cat > /data/project/wikilint/mailbox" as
/data/project/wikilint/.forward.subster perfectly stores incoming mail to
[email protected] at the specified location (though I
didn't assume that it would even work as it uses a shell redirection and
[[wikitech:Nova Resource:Tools/Help#Processing email programatically]] spoke
only of "program" without any shell syntax or arguments).

'cat' is a programm that is supposed to take the standard input and pipe it then to a file (I would love to do this more directly if possible). That fits exactly in to the explanation on [[wikitech:Nova Resource:Tools/Help#Processing email programatically]].

But let's continue in bug 63702 I am very thankful for any help on this - even more as this feature DOES NOT WORK as on toolserver yet and is therefore NO APPROPRIATE REPLACMENT NOR SOLUTION TO TOOLSERVER YET.

(In reply to DrTrigon from comment #20)

[...]

'cat' is a programm that is supposed to take the standard input and pipe it
then to a file (I would love to do this more directly if possible). That
fits exactly in to the explanation on [[wikitech:Nova
Resource:Tools/Help#Processing email programatically]].

[...]

cat always outputs to standard output; cf. cat(1):

DESCRIPTION
Concatenate FILE(s), or standard input, to standard
output.

dr.trigon wrote:

(In reply to Tim Landscheidt from comment #21)

(In reply to DrTrigon from comment #20)

[...]

'cat' is a programm that is supposed to take the standard input and pipe it
then to a file (I would love to do this more directly if possible). That
fits exactly in to the explanation on [[wikitech:Nova
Resource:Tools/Help#Processing email programatically]].

[...]

cat always outputs to standard output; cf. cat(1):

DESCRIPTION
Concatenate FILE(s), or standard input, to standard
output.

...and from there through pipe into file, right?

(In reply to DrTrigon from comment #22)

[...]

'cat' is a programm that is supposed to take the standard input and pipe it
then to a file (I would love to do this more directly if possible). That
fits exactly in to the explanation on [[wikitech:Nova
Resource:Tools/Help#Processing email programatically]].

[...]

cat always outputs to standard output; cf. cat(1):

DESCRIPTION
Concatenate FILE(s), or standard input, to standard
output.

...and from there through pipe into file, right?

No, that is set up by the shell. cat does not know which file (or pipe) its output is redirected to.