| Re: Encoding Problems [message #186355 is a reply to message #186354] |
Sun, 06 July 2014 03:19   |
Richard Damon
Messages: 58
Registered: August 2011
Karma:
|
Member |
|
|
On 7/5/14, 10:16 PM, Denis McMahon wrote:
> On Sun, 06 Jul 2014 01:36:20 +0200, Arno Welzel wrote:
>
>> Christoph Michael Becker, 2014-07-05 03:28:
>
>>> What about a default clause, at least triggering a notice/warning that
>>> the encoding is not understood?
>
>> Good Point. But which other encoding except no encoding at all, base64
>> and or quoted printable may be used?
>
> multipart/form-data
>
> It might not be expected in an email, but then the email might be
> generated by someone looking to target some notional email application
> which had an exploitable vulnerability in that it would try and decode
> multipart/form-data in a manner that further allowed a carefully crafted
> invalid data sequence to trigger arbitrary code execution.
>
> Now that exploit might not even be targeting the code being discussed
> here, but when script kiddie spam house sends out billions of emails in
> an attempt to exploit that vulnerability, the chances are that one of
> them will make its way into this processing chain.
>
> Detecting and cleanly handling both unrecognised declared encoding types
> and malformed encoded data is therefore probably good practice.
>
multipart/form-date would be a value for Content-Type, not a value for
Content-Transfer-Encoding.
The defined vauls (By RFC 2045) of Content-Transfer-Encoding are:
quoted-printable
base64
binary
8bit
7bit
(Binary and 8bit are only allowed if the receiving server indicates it
is capable of handling it).
Binary, 8bit, and 7bit imply not transform should be performed on the
data to decode it.
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]