dr.trigon wrote:

The same for drtrigonbot.maintainers@tools.wmflabs.org which should work out of the box, right?

reverted your priority/severity fields.

AFAICT, no other user has said it also doesn't work for them.

Given the recent comment bug 58796 comment #18, it does work for someone.

(In reply to Tim Landscheidt from bug 58796 comment #18)

But despite (!) this, using "|jmail cat > /data/project/wikilint/mailbox" as

Should be >>? (append)

dr.trigon wrote:

(In reply to jeremyb from comment #2)

reverted your priority/severity fields.

AFAICT, no other user has said it also doesn't work for them.

Just because nobody else is using this feature like me does not mean it's ok. Especially as it is supposed to be a replacement for toolserver - and there it works perfectly (and even simpler).

Given the recent comment bug 58796 comment #18, it does work for someone.

(In reply to Tim Landscheidt from bug 58796 comment #18)

But despite (!) this, using "|jmail cat > /data/project/wikilint/mailbox" as

Should be >>? (append)

Might be, but is not the crucial point here at the moment - I would be very happy if at least something would arrive. But I assume (I don't know) it fails already before...

Tim: What does work for you? Could you describe your setting and use case to me, please?

(In reply to DrTrigon from comment #3)

[...]

Tim: What does work for you? Could you describe your setting and use case to
me, please?

What I wrote in bug #58796, comment #18:

I don't see any jobs for the mailq queue for tools.drtrigonbot in /var/lib/gridengine/default/common/accounting, but for tools.wikilint, so apparently the job doesn't get launched in the first place.

/var/log/exim4/rejectlog on tools-mail contained:

So I "chmod o+r ~tools.drtrigonbot/.forward.subster", and my next test mail was correctly written to ~tools.drtrigonbot/data/subster/mail_inbox_test.

I documented that at https://wikitech.wikimedia.org/w/index.php?title=Nova_Resource:Tools/Help&diff=109536&oldid=108815.

dr.trigon wrote:

(In reply to Tim Landscheidt from comment #6)

/var/log/exim4/rejectlog on tools-mail contained:

2014-04-13 18:22:00 H=mo4-p00-ob.smtp.rzone.de [81.169.146.162]

F=<tim@tim-landscheidt.de> temporarily rejected RCPT
<drtrigonbot.subster@tools.wmflabs.org>: failed to open
/data/project/drtrigonbot/.forward.subster: Permission denied (euid=107
egid=110)

So I "chmod o+r ~tools.drtrigonbot/.forward.subster", and my next test mail
was correctly written to ~tools.drtrigonbot/data/subster/mail_inbox_test.

Aaaahh I see, now that makes sense to me - was what I somewhat initially assumed to be the problem... its always about the permissions...! :)) Thanks a lot!!! :)

The strange thing now is why it was NOT deliverd to the mail address specified in '~/.forward'? And also not bunced with an error message? But instead was not able to be delivered and ended up being delayed? The same for drtrigonbot.maintainers@tools.wmflabs.org mentioned in comment 1.

(In reply to DrTrigon from comment #7)

[...]

The strange thing now is why it was NOT deliverd to the mail address
specified in '~/.forward'? And also not bunced with an error message? But
instead was not able to be delivered and ended up being delayed? The same
for drtrigonbot.maintainers@tools.wmflabs.org mentioned in comment 1.

The same thing (mail being stuck in the queue) happened previously when ~/.forward had wrong permissions and is thus apparently a design choice by the Exim developers. It makes some sense because otherwise mail to a user with an improper ~/.forward would be misrouted to for example local storage with no indication to the user about that, while the "we'll keep trying" approach shows up at least in the mail queue and thus potentially in the admins' eyes.