Tickets :: Comment on [#13835] Horde breaks attachments

* Your Email Address
* Spam protection	Enter the letters below: .__.. ..___.__..__. [__]\| \|[__ [__]\| \| \| \|\|/\\|\| \| \|\|__\|
Comment	>>> 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 them. > 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?
Attachment
Watch this ticket

Saved Queries