Have bounces set envelope from address to something sensible

Bug #783505 reported by Paul Everitt
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
KARL3
Fix Released
Low
Chris Rossi

Bug Description

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.

Tags: r3.86
Changed in karl3:
milestone: m60 → m59
Changed in karl3:
milestone: m59 → m60
Changed in karl3:
milestone: m60 → m61
Changed in karl3:
milestone: m61 → m62
Revision history for this message
Chris Rossi (chris-archimedeanco) wrote :

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.

summary: - Have bounces set reply-to to something sensible
+ Have bounces set envelope from address to something sensible
Changed in karl3:
assignee: Chris Rossi (chris-archimedeanco) → Christian Zagrodnick (zagy)
Changed in karl3:
status: New → Incomplete
Revision history for this message
Christian Zagrodnick (zagy) wrote :

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

Changed in karl3:
status: Incomplete → Confirmed
Changed in karl3:
milestone: m62 → m63
Revision history for this message
Paul Everitt (paul-agendaless) wrote :

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

Changed in karl3:
milestone: m63 → m74
Revision history for this message
Paul Everitt (paul-agendaless) wrote :

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

Changed in karl3:
milestone: m74 → m75
Revision history for this message
Christian Zagrodnick (zagy) wrote :

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

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

Revision history for this message
Christian Zagrodnick (zagy) wrote :

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?

Changed in karl3:
assignee: Christian Zagrodnick (zagy) → Chris Rossi (chris-archimedeanco)
Revision history for this message
Paul Everitt (paul-agendaless) wrote :

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

Changed in karl3:
status: Confirmed → In Progress
Revision history for this message
Chris Rossi (chris-archimedeanco) wrote :

I executed the following command on production:

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

Changed in karl3:
status: In Progress → Fix Released
Revision history for this message
Christian Zagrodnick (zagy) wrote :

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.

Revision history for this message
Chris Rossi (chris-archimedeanco) wrote :

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'.

Changed in karl3:
status: Fix Released → In Progress
milestone: m75 → m102
Changed in karl3:
status: In Progress → Fix Committed
Revision history for this message
JimPGlenn (jpglenn09) wrote :

fixed not sure how to test.

Changed in karl3:
status: Fix Committed → Fix Released
JimPGlenn (jpglenn09)
tags: added: r3.86
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.