[Tickets #13835] Re: Horde breaks attachments

noreply at bugs.horde.org noreply at bugs.horde.org
Tue Feb 3 09:11:09 UTC 2015


Ticket URL: https://bugs.horde.org/ticket/13835
  Ticket             | 13835
  Updated By         | bra at fsn.hu
  Summary            | Horde breaks attachments
  Queue              | Horde Framework Packages
  Type               | Bug
  State              | Unconfirmed
  Priority           | 2. Medium
  Milestone          |
  Patch              |
  Owners             |

bra at fsn.hu (2015-02-03 09:11) wrote:

>> This means the attachment will be converted to CRLF line endings and
>> a CRLF will be inserted after 998 characters by the SMTP server if a
>> line is longer than that, therefore breaking the XML parser on the
>> receiver end and breaking any checksum validations.
> You are incorrect.  http://www.w3.org/TR/REC-xml/#sec-line-ends
> When normalized as is required, the data is EXACTLY the same as when sent.
Maybe I'm misunderstanding something here, but for me exactly means  
it's exactly the same, but it's not:
$ md5sum orig.es3 gmail.es3
1e5ff3a4beff2589882afa87abd56c81  orig.es3
01c974b662f8f187edf4207f7ce24852  gmail.es3

And they aren't the same even when I do "by translating both the  
two-character sequence #xD #xA and any #xD that is not followed by #xA  
to a single #xA character".
because the SMTP server (postfix) breaks lines, which (both this and  
the CRLF issue) is not the case when you encode it in base64.
BTW, our users ask that if they attach a file, it should be the same  
on the receiving side. This is the case with gmail, outlook.com,  
fastmail, outlook etc, but not with horde. I can't tell them you  
should normalize your XMLs, because they are not generating or parsing  
To them the issue is if they send the files with horde, it'll break.  
If they send it with whatever else, it won't.

I will attach two files, orig.es3, which is I sent as an attachment,  
and gmail.es3 which I got in gmail. If I feed the gmail.es3 into an  
XML parser (http://validator.w3.org/check), the original validates  
while the received one breaks on multiple points (the line breaks).

>> AFAIK, Horde should base64 encode any non text/* mime types.
> False.  Directly from the MIME RFC:
> "It may seem that the Content-Transfer-Encoding could be
> inferred from the characteristics of the media that is to be encoded,
> or, at the very least, that certain Content-Transfer-Encodings could
> be mandated for use with specific media types.  There are several
> reasons why this is not the case."
I've just found this:
"Your browser is incorrectly reporting the file as 'text/something'
when uploading.  That's the only way we would be non-base64 encoding
an attachment."
When this statement became false?

More information about the bugs mailing list