Have bounces set envelope from address to something sensible

[Paul Everitt]

From gocept:

Am 09.05.2011 20:21, schrieb Chris Rossi:

2) The alert message to at least one community member cannot be delivered for
some reason. The gocept's MTA generates a delivery status notification and
sends it to the return address, in this case, the Karl community.

This point leaves some room for improvement. The way the things work, mails is sent to vanished mail addresses for a possibly indefinite amount of time. I think it would be better to send out mails with a sensible envelope sender address where bounces are collected. Thus, human-generated replies go to one mail address and non-delivery messages go to another.

We could collect non-delivery replies for regular reviews (dysfunktional mail accounts should be disabled) or even for automated bounce processing. The mailman code contains some nice pieces which extract mail addresses from such reports.

[Chris Rossi (chris-archimedeanco)]

In response to another bug, I added the ability to onfigure the envelope from address site-wide. So this is basically done. The question, though, is what is a 'sensible' value for this? Right now, for osf, it is set to <email address hidden>. This will cause any bounces to come back to mailin where they will be bounced since there is no 'karl' community.

Zagy, if you would like to set up something different let me know what email address you would like to use here.

[Christian Zagrodnick (zagy)]

As a first step we'll add a new mailbox for bounces. This way we at least don't produce double bounces any more.

[Paul Everitt (paul-agendaless)]

Hmm, this one fell through the cracks. Christian, is there a next action on this?

[Paul Everitt (paul-agendaless)]

Hmm, no comment from Zagy. I'll move to next week, try again.

[Christian Zagrodnick (zagy)]

Yep, sorry for being slow. The mailbox is being created now.

I suggest using <email address hidden> for the bounce address.

[Christian Zagrodnick (zagy)]

I've set up <email address hidden> for testing/staging. Before putting anything into production the change should be verified.

Chris, will you do this? Or anybody else?

[Paul Everitt (paul-agendaless)]

Yes, we'll have Chris do the next step on this.

[Chris Rossi (chris-archimedeanco)]

I executed the following command on production:

$ bin/karlserve settings set osf postoffice.bounce_from_email <email address hidden>

[Christian Zagrodnick (zagy)]

Now the question of course is also what to do with those messages. But I suppose this would be a longer term process to do anything about them.

[Chris Rossi (chris-archimedeanco)]

I spent a few more minutes looking at and thinking about this this morning:

We have a similar problem ongoing with backscatter going back and
forth with <email address hidden>, although the number of emails
involved is much smaller than what we were seeing with
<email address hidden>.

The problem is we're winding up with an infinite loop where something
(lost in the sands of time) causes something to be sent in to some
Karl community that winds up bouncing back to postmaster@X. If, for
some reason, postmaster@X can't handle the bounce email, it, in turn,
bounces an email right back to <email address hidden>. Ad infinitum. In
the case of sorosny.org this was because that mailbox got full. In
the case of osiwa.org, it's because that mailbox doesn't exist.
Regardless, we want to avoid infinite mail loops, whatever the reason.
 We spent a certain amount of time and effort a couple of years back
keeping mail loops from generating bogus content in Karl, but
apparently we didn't go the next step of making sure we're not
generating a massive amount of behind the scenes noise.

It looks like this was an attempt to address this problem, that we
failed to follow through on:

https://bugs.launchpad.net/karl3/+bug/783505

The idea here is that if we set the envelope from of bounce messages
to something that winds up either in the bitbucket or cordoned off
somewhere, then we break the cycle and no longer generate massive
infinite loops of MTAs emailing each other about the fact that they
can't email each other. Something from yesterday felt funny to me so
I investigated further this morning and discovered that my
implementation of this is actually wrong. I am setting the 'From'
header of the email to whatever is set as the 'bounce_from_email'. I
am not actually setting the envelope 'From' which is why bounces of
bounces keep coming back to '<email address hidden>', because that's
still the envelope from. So that's one problem.

I did go ahead and send a test mail to
'<email address hidden>', the email provided by Zagy in
that ticket, just to see what would happen. That email bounced. ;)
So fixing my snafu with the envelope from won't get us out of the
woods yet. We need to also have an email address to set that to that
will quietly absorb, without bouncing, anything that is thrown at it.
The ticket above suggests hanging on to that email in case there's
something we want in it. I suspect there won't be and we may as well
send it to /dev/null, but as long as nothing bounces back from it,
we've fixed the infinite loop.

I don't really understand what you're suggesting with the local 'null'
alias. What we need is an address that will silently absorb email
sent to it from the great wide internet. And then I need to fix my
implementation of 'bounce_from_email'.

[JimPGlenn (jpglenn09)]

fixed not sure how to test.