We're updating the issue view to help you get more done. 

Occasional 500 error when deleting works due to Net::SMTPFatalError: 550

Description

Support and Policy & Abuse have encountered several works that give 500 errors during the deletion process, regardless of whether the person deleting the work is an admin or a work creator. Database admins are similarly unable to delete the affected works using the destroy method on the command line – they receive errors such as

1 2 3 4 5 Net::SMTPFatalError: 550 maximum allowed line length is 998 octets, got 1002 from app/models/work.rb:211:in `block in before_destroy' from app/models/work.rb:203:in `each' from app/models/work.rb:203:in `before_destroy'

Replacing the content of the work or the beginning or end notes (it depends on the work) with new text enables deletion, but means the user does not receive a full copy of their work.

The error does not appear to be related to the length of the content or notes – this error has even happened when attempting to delete a work that consisted solely of an image. It also does not appear to be related to the specific content; that is, if you recreate a problematic work on staging, it will still delete.

Since this error is not reproducible on demand, any fix for this can't be tested beyond making sure it is possible to delete a work. We will have to deploy the fix and see if we stumble upon the error again.

Notes

james_ discovered that this is due to the plain text part of the email having 7bit encoding. red found that Mail's documentation on multipart emails says:

Mail assumes that if your text in the body is only us-ascii, that your transfer encoding is 7bit and it is text/plain. You can override this by explicitly declaring it.

How to test

  • Post a work and delete it

  • Post a work and have an admin delete it

In both cases, as the work's author, you should receive emails, with the HTML and plain text versions of the work attached. If you look at the raw email, you should see that the plain text attachment has base64 encoding, like this:

1 2 3 4 ----==_mimepart_5b2b25fe3d906_773ffab1942599d Content-Type: text/plain; charset=UTF-8; filename="2k line.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="2k line.txt"

More notes
Sarken has the URL of a work affected by this bug on production. Once this is deployed, we can delete that work to confirm the issue is fixed.

Environment

Status

Assignee

redsummernight

Reporter

Sarken

Roadmap

Works

Priority

Medium

Affects versions

0.9.215

Fix versions

Components

BackEnd

Difficulty

Medium

Milestone

Internal 0.9