parse_attachment() error when a trailing ';' exists

[sblondon]

Hello,

there is an exception when an e-mail with attachment is parsed in a specific case:
when the Content-Disposition line has a ';' at the end of the line.

Working case:
Content-Disposition: attachment; filename="abc.xyz"

Error case:

Content-Disposition: attachment; filename="abc.xyz";
                                                   ^ ooops

It's fixable by modifying the parse_attachment() implementation. I hesitate for 2 way to fix it:

• using second element to dispositions only:
  for param in dispositions[1]:
• checking if param is not falsy inside the for loop.

According to https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition
Content-Disposition: form-data; name="fieldName"; filename="filename.jpg" is valid so I think the second solution is better.

What do you think about it ?
Ok for such a pull-request?

The trace in ipython:

<ipython-input-21-dcfccc808ef9> in <module>()
----> 1 spam = imbox.parser.parse_email(tspam)

~/src/vieux-emails/local.virtualenv/lib/python3.4/site-packages/imbox/parser.py in parse_email(raw_email, policy)
    163                 body['html'].append(content)
    164             elif content_disposition:
--> 165                 attachment = parse_attachment(part)
    166                 if attachment:
    167                     attachments.append(attachment)

~/src/vieux-emails/local.virtualenv/lib/python3.4/site-packages/imbox/parser.py in parse_attachment(message_part)
     99             for param in dispositions[1:]:
    100                 print("PARAM", param)
--> 101                 name, value = decode_param(param)
    102 
    103                 if 'file' in name:

~/src/vieux-emails/local.virtualenv/lib/python3.4/site-packages/imbox/parser.py in decode_param(param)
     60 
     61 def decode_param(param):
---> 62     name, v = param.split('=', 1)
     63     values = v.split('\n')
     64     value_results = []

ValueError: need more than 1 value to unpack

[martinrusev]

@sblondon The second solution looks more reasonable. A pull request with the change is welcome

[sblondon]

So, this issue can be closed now?