mail handling stalls when a large message is received and not deliverable

Various issues here:

1- send_process_error_notification should probably truncate the bounced-back mail
2- arguably, incoming.py should be more aggressive about dropping problematic incoming mails. there is some kind of tradeoff about whether, if we fail to send an error, we would rather silently drop the mail, or stall processing. perhaps the best thing is to log the oops, delete the incoming mail, then send the bounce. But that may be overoptimizing for this particular failure.

We've worked around the immediate fail in production, but this will happen again if not fixed.

This should be an OOPS, and has happened again.

A few options here:

1- Set the border mta incoming message size limit down, or the
in-application limit up, so messages are rejected before reaching
incoming.py. In some ways this is cleaner than bouncing them.

2- Truncate when sending errors. Probably good, though I wonder if that will
leave open other cases where we could fail to send the reply.

3- Delete the message from the mailbox before sending the oops. One line
change. It does not seem likely that retrying them will help.
On May 28, 2011 5:55 PM, "William Grant" <email address hidden> wrote:

On Thu, Jun 2, 2011 at 3:35 PM, Martin Pool <email address hidden> wrote:
> A few options here:
>
> 1- Set the border mta incoming message size limit down, or the
> in-application limit up, so messages are rejected before reaching
> incoming.py. In some ways this is cleaner than bouncing them.

We could, but even after that...

> 2- Truncate when sending errors. Probably good, though I wonder if that will
> leave open other cases where we could fail to send the reply.

This really appeals to me

For interest, cinerama tells me the gateway MTA looks to be set at a 50MB limit. It is perhaps odd we accept 50MB mails but limit ourselves to sending out 10MB mails.

> This should be an OOPS, and has happened again.

It's happening while already trying to send and report on an oops. Perhaps we should also oops about the failure to send notification of the oops?

I'm not sure oopsing on the original message fits the oops policy, because this is something users could produce on demand. To handle that we would have to distinguish "message too big" from "something else bad happened", and perhaps there it's better to fix it on the border MTA.

I think perhaps the easiest thing is to just send back the OOPS id and not the whole message?

https://code.launchpad.net/~mbp/launchpad/788874-mail-oops/+merge/63343

Fixed in stable r13170 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/13170>.