| Commit message (Collapse) | Author | Age | Lines |
|---|
| |
|
|
| |
Otherwise UTF-8 encoded strings will be returned as ASCII-8BIT.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Taken from https://github.com/mikel/mail/pull/602
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a fix for issue #1232. Richard Taylor pointed
out that some PDF attachments had the non-standard content-type
document/pdf, and that these weren't being treated as PDFs.
(Ganesh Sittampalam discovered that all of these PDFs were
generated by a Lexmark X945e, according to the PDF metadata.)
This commit adds an extra case to normalise_content_type to map
document/pdf to application/pdf.
In fact, since the upgrade of the Mail gem in ccebe3c3d6d4dc5f81
the behaviour when handling the non-standard content-type
document/pdf was much better, but this commit also means that
you get the right icon for the attachment, and can be
cherry-picked onto older versions to fix #1232.
|
| |
|
|
|
| |
The new name value doesn't escape a double quote within single quotes,
which seems more correct.
|
| |\
| |
| |
| |
| |
| | |
Conflicts:
locale/he_IL/app.po
locale/nb_NO/app.po
|
| | |
| |
| |
| | |
errors when parsing large mails with envelopes on memory limited systems.
|
| |/ |
|
| |
|
|
|
|
|
|
|
| |
This use of eval allows arbitrary remote code execution on
parsing of a maliciously formed email.
Two tests are updated to match the behaviour of the new
code to return the display name - these introduce extra
escaping, so should be innocous.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This seems to be the bug mentioned here:
http://po-ru.com/diary/fixing-invalid-utf-8-in-ruby-revisited/
That explains that some versions of Iconv don't ignore
invalid characters when converting to UTF-8 even with
//IGNORE if that invalid character happens to be at the end
of the string. In fact, as Matthew Somerville pointed out,
with some versions of iconv (e.g. 1.14 on Mac OS, apparently)
it's necessary to add and remove more than one space at the end,
in case the first character of the byte sequence indicates a
long sequence. We add and remove 4 to be on the safe side.
|
| |
|
|
|
|
|
|
|
|
| |
The behaviour of the TMail backend's 'to' and 'cc' methods
where there was a malformed To: or Cc: line was to return
nil, whereas Mail returns a version of the string anyway.
We'd have to change quite a lot of code to deal with an
extra possible class of returned objects, so it's simplest
for the moment to monkey-patch Mail::Message's 'to' and 'cc'
methods to restore the old behaviour.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Mail gem deals with multipart messages that look as if
they should have 1 part but are missing the final MIME boundary,
by make the parts list empty and setting part.body to the
text of the email. Rather than throwing an exception in this
case, we just pretend that part is text/plain and return it, so
that the page doesn't error and we still have a chance of some
useful text being displayed.
Note that we haven't investigated yet the case of emails that
have more than one start boundary, but no final boundary.
Fixes #921
|
| |
|
|
| |
no charset field.
|
| |
|
|
|
|
|
| |
These cases are rare, and probably need to be resolved by
reporting issues against the Mail gem (although it's debatable
what the more correct or pragmatic behaviour should be in both
cases).
|
| |
|
|
|
| |
At one point in development this email was misparsed, so I've
added this as test to check for regressions.
|
| | |
|
| |
|
|
|
|
|
| |
This example email indicates the wrong charset and includes
a top bit set character despite Content-Transfer-Encoding: 7bit
- nonetheless, we should be able to convert it to UTF-8 and
interpret the character correctly.
|
| |
|
|
|
|
|
|
|
| |
If there is a missing final MIME boundary, the behaviour
of Alaveteli with the TMail backend was to still parse
the attachment, but with the new code it currently throws
an exception. This commit adds a test that asserts that
the attachment should be parsed despite the email being
malformed in this way.
|
| |
|
|
|
|
|
|
|
|
|
| |
There is currently a difference in behaviour in the parsing
of nested MIME multipart attachments between the Mail and
TMail based backends. This commit adds a test that will
pass if the behaviour is the same as the the old (TMail-based)
version, which I believe is correct according to RFC 1521.
The example email has a PNG attachment after the final MIME
boundary, and the RFC says that anything after the final
boundary ("the epilogue") should be ignored.
|
| |
|
|
|
|
|
|
|
|
|
| |
These two cases were ignored previously, and we need to make sure
that they still are under the switch from TMail to Mail.
One TNEF attachment is a heavily truncated one from a real example
from Alaveteli that has no personal data in it. The other is
an example from the tests in the distribution of the tnef
package for Ubuntu 1.4.9-1 - it's an HTML version of the US
constitution.
|
| | |
|
| |
|
|
| |
timezone. TMail renders headers using localtime, which is not ideal, but we're migrating away from it anyway, so I'm not sure it's worth delving into the internals of TMail to fix it.
|
| | |
|
| |
|
|
| |
filenames, and within rfc822 subjects.
|
| | |
|
| |
|
|
| |
function.
|
| |
|
|
| |
get_attachment_text_one_file as it is now an externally-accessed method of the mail handler module.
|
| | |
|
| |
|
|
| |
header strings from a mail.
|
| | |
|
| |
|
|
| |
with the mail backend.
|
| | |
|
| |
|
|
| |
getting the auto-submitted field.
|
| |
|
|
| |
the mail handler.
|
| |
|
|
| |
an email.
|
| | |
|
| | |
|
| | |
|
| |
|
