Whenever I try to know the content type of multipart message by using javamail API, I'm getting the content type as:
multipart/mixed;
boundary="----=_Part_19_32879825.1271840022140"
I've already disable my antivirus, but I'm still not able to terminate that boundary.
I'm trying to send the message using IMAP protocol.
I'm using Hmail Server.
Could anyone please tell me the reason of it?
If the email that you're sending contains an attachment, this is not an error. It is how the message header is really supposed to be:
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="frontier"
This is a message with multiple parts
in MIME format.
--frontier
Content-Type: text/plain
This is the body of the message.
--frontier
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg
Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg==
--frontier--
From: http://en.wikipedia.org/wiki/MIME
The value of the boundary attribute indicates where each message part finishes and the next one begins.
EDIT:
If you're getting an error related to missing end boundary (is that your question?), then you may want to set the missing end boundary to false:
The
mail.mime.multipart.ignoremissingendboundary
property may be set to false to cause
a MessagingException to be thrown if
the multipart data does not end with
the required end boundary line. If
this property is set to true or not
set, missing end boundaries are not
considered an error and the final body
part ends at the end of the data
That's from the JavaMail API.
Related
We need to send a multipart/form-data request containing two files. Since we had some issues with the requests, we set up a request bin page to try and analyze the requests themselves, since Postman seemed to work fine.
My second file is generated by a different service as a byte stream and represents a JSON object. This byte stream seems to have a NUL (0) byte terminator at the end.
If I add this second file to the multipart/form-data request, something like the following results:
With the body looking as follows:
--9ac41cec-a0ff-4afd-b687-6b8c2f1bddd6.
Content-Disposition: form-data; name="metadata"; filename="metadata-1584981615.json".
Content-Type: application/json.
Content-Length: 581.
.
{"...":"..."}.
--9ac41cec-a0ff-4afd-b687-6b8c2f1bddd6.
Content-Disposition: form-data; name="file"; filename="file-1584981615.json".
Content-Type: application/json.
Content-Length: 12205.
.
{"...":"..."}..
--9ac41cec-a0ff-4afd-b687-6b8c2f1bddd6--.
Obviously, this is supremely invalid. It seems that the multipart request is adding the . characters at the end of every line.
I was able to reproduce this behaviour with Spring Web 5.1.5.RELEASE, okHttp 3.14.7 and Apache HttpComponents 4.5.7. The behaviour does not seem to change if I remove the NUL (0) byte terminator from the byte stream.
Here's the odd part: the receiving webserver accepts this request as a valid multipart/form-data request.
For the record, here's what a valid request (that is also accepted by the webserver) looks like from request bin's point of view (different file):
--83611e7f-ad57-4893-9d1b-5ba2c4543d2a
Content-Disposition: form-data; name="metadata"; filename="metadata-1584982345.json"
Content-Type: application/json
Content-Length: 895
{"...": "..."}
--83611e7f-ad57-4893-9d1b-5ba2c4543d2a
Content-Disposition: form-data; name="file"; filename="file-1584982345.json"
Content-Type: application/json
Content-Length: 9868
{"...": "..."}
--83611e7f-ad57-4893-9d1b-5ba2c4543d2a--
Aside from having the explicit terminator at the end (which does not seem to make a difference at all), the byte stream does not look broken. new String(bytes) gives a valid JSON object. So I'm thinking it has to be something else.
Has anyone encountered this issue before? I'm unsure how to proceed with debugging this issue, and I'm fairly certain that sending improper requests, even though they might be accepted by the remote server at this time, almost certainly guarantees that my code will break somewhere along the line...
i am trying to upload a file to google drive without using api because i don't need it. I've used httpClient from apache for connectivity and encoded file to base64 but it is not working. i am getting this error from server:Missing end boundary in multipart body.
data send to server:
Authorization: Bearer ya29.GluYBCda-OrQMw8Oi-Tf4EIGRU1rzU3Rhak5eozujD3uPMTVOExhcfvDw7k1XSMtMGdBJDNdjZW_wlNvwc-VjmknSTWlRWEZ79MiD6rZkqI6A9vqavGZKDOe11mIContent-Type: multipart/related; boundary="simple_boundary"Transfer-Encoding: chunkedHost: localhostConnection: Keep-AliveUser-Agent: Apache-HttpClient/4.5.3 (Java/1.8.0_71)Accept-Encoding: gzip,deflate--simple_boundaryContent-Type: application/json; charset=UTF-8 {"name":"copy.jpg"}--simple_boundaryContent-Type: image/jpg/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAIBAQIBAQICAgICAgICAwUDAwMDAwYEBAMFBwYHBwcGBwcICQsJCAgKCAcHCg0KCgsMDAwMBwkODw0MDgsMDAz/2wBDAQICAgMDAwYDAwYMCAcIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCABuAIkDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD8f/8Ah7F+1N/0ct8f/wDw4er/APyRR/w9i/am/wCjlvj/AP8Ahw9X/wDkivn+igD6A/4exftTf9HLfH//AMOHq/8A8kUf8PYv2pv+jlvj/wD+HD1f/wCSK+f6KAPoD/h7F+1N/wBHLfH/AP8ADh6v/wDJFH/D2L9qb/o5b4//APhw9X/+SK+f6KAPoD/h7F+1N/0ct8f/APw4er//ACRR/wAPYv2pv+jlvj//AOHD1f8A+SK+f6KAP7jP+CZXizVfHv8AwTb/AGfNd13UtQ1rW9a+Gvhy/wBQ1C/uHubq/uJdLtnlmllcl5JHdmZmYksSSSSa9wr5/wD+CTv/ACiy/Zp/7JV4X/8ATRa19AUAFFFFABRRRQAUUUUAFFFFAH8AdFFFABRRRQAUUUUAFFFFAH9vn/BJ3/lFl+zT/wBkq8L/APpota+gK+f/APgk7/yiy/Zp/wCyVeF//TRa19AUAFFFFABRRRQAUUUUAFFFFAH8AdFFFABRRRQAUUUUAFFFFAH9vn/BJ3/lFl+zT/2Srwv/AOmi1r6Ar5//AOCTv/KLL9mn/slXhf8A9NFrX0BQAUUUUAFFFFABRRRQAUUUUAfyBf8AELj+3X/0Q3/y8/D/AP8AJ1H/ABC4/t1/9EN/8vPw/wD/ACdX9ftFAH8gX/ELj+3X/wBEN/8ALz8P/wDydR/xC4/t1/8ARDf/AC8/D/8A8nV/X7RQB/IF/wAQuP7df/RDf/Lz8P8A/wAnUf8AELj+3X/0Q3/y8/D/AP8AJ1f1+0UAfyBf8QuP7df/AEQ3/wAvPw//APJ1eQftq/8ABGb9pP8A4J2/Cyw8a/GL4cf8If4Z1TVY9Etbz/hINL1DzbySGaZIvLtbmWQZjt5m3FQvyYJyQD/a5X5Af8Hq3/KLLwD/ANlV07/00axQB+MPwn/4OPP2zvgd8LPDXgrwt8ZP7L8M+D9KtdE0iz/4RLQ5/slnbQpDBF5klk0j7Y0VdzszHGSScmug/wCIo39uv/ouX/lmeH//AJBr4AooA+//APiKN/br/wCi5f8AlmeH/wD5Bo/4ijf26/8AouX/AJZnh/8A+Qa+AKKAPv8A/wCIo39uv/ouX/lmeH//AJBo/wCIo39uv/ouX/lmeH//AJBr4AooA+//APiKN/br/wCi5f8AlmeH/wD5Bo/4ijf26/8AouX/AJZnh/8A+Qa+AKKAPv8A/wCIo39uv/ouX/lmeH//AJBr+v2v4A6/v8oAKKKKACiiigAooooAK/ID/g9W/wCUWXgH/squnf8Apo1iv1/r8gP+D1b/AJRZeAf+yq6d/wCmjWKAP5gqKKKACiiigAooooAKKKKACv7/ACv4A6/v8oAKKKKACiiigAooooAK/ID/AIPVv+UWXgH/ALKrp3/po1iv1/r8gP8Ag9W/5RZeAf8Asqunf+mjWKAP5gqKKKACiiigAooooAKKKKACv7/K/gDr+/ygAooooAKKKKACiiigAr8gP+D1b/lFl4B/7Krp3/po1iv1/r4Q/wCDhb/gl/4+/wCCsv7F/hj4dfDrV/B+i63ovjW18STz+JLq5trV7eKxv7dkVoIJnMm+6jIBQDAb5gQAQD+PKiv1/wD+IKn9qb/ofvgB/wCDzV//AJWUf8QVP7U3/Q/fAD/weav/APKygD8gKK/X/wD4gqf2pv8AofvgB/4PNX/+VlH/ABBU/tTf9D98AP8Aweav/wDKygD8gKK/X/8A4gqf2pv+h++AH/g81f8A+VlH/EFT+1N/0P3wA/8AB5q//wArKAPyAor9f/8AiCp/am/6H74Af+DzV/8A5WUf8QVP7U3/AEP3wA/8Hmr/APysoA/ICv7/ACv5gv8AiCp/am/6H74Af+DzV/8A5WV/T7QB/9k=--simple_boundary--
I believe that the problem may be that your start and end boundaries are not on a new line according to this website. I would try putting CRLF's in prior to your boundaries.
The boundary delimiter MUST occur at the beginning of a line, i.e.,
following a CRLF, and the initial CRLF is considered to be attached
to the boundary delimiter line rather than part of the preceding
part. The boundary may be followed by zero or more characters of
linear whitespace. It is then terminated by either another CRLF and
the header fields for the next part, or by two CRLFs, in which case
there are no header fields for the next part. If no Content-Type
field is present it is assumed to be "message/rfc822" in a
"multipart/digest" and "text/plain" otherwise.
(This was edited because I was initially mistaken, I thought that every boundary had to be closed)
If I add FetchProfile.Item.CONTENT_INFO to the FetchProfile a javax.mail.Folder, .getContent() and .getInputStream() only returns empty strings, as if the content is not fetched at all. If I don't set the CONTENT_INFO flag, the content is fetched just fine.
However it only happens if the message is text/plain; charset:us-ascii. If it's multipart or text/html, it works fine.
Can anyone tell me why this happens?
i've a plugin that should process some mails, so i need to get attachments from an imap mail and do some stuff.
All seem to work but i've a single mail that have a strange attachment header and i'm not able to get it correctly, here the attachment header:
--_01d0aeb2-3f01-4153-9121-66b7af6924f1_
Content-Type: application/msword
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=
"=?iso-8859-1?Q?Atto_Aziendale_(xxx=E0_del_xxx_xxx_-_xxx)=2C_Pr?=
=?iso-8859-1?Q?of.xxx_xxx_-_Dr.xxx_xxx.doc?="
"x" are for privacy but that should not be important, the problem is that when i try to get the filename of this attachment with javaMail:
Attachment att = new Attachment(mailPart);
String filename = att.getFilename();
i get only this: "Atto Aziendale (xxx del xxx xxx - xxx), Pr"
seem that it doesn't read the second line.
I've also tried to get the filename in another way:
mailPart.getHeader("Content-Disposition").getAttribute("filename").toString();
and that return: filename="=?iso-8859-1?Q?Atto_Aziendale_(xxx=E0_del_xxx_xxx_-_xxx)=2C_Pr?==?iso-8859-1?Q?of.xxx_xxx_-_Dr.xxx_xxx.doc?="
so it seem that the attribute is correctly readed, but if i try to get:
mailPart.getHeader("Content-Disposition").getAttribute("filename").getValue();
then i get again a truncated filename: "Atto Aziendale (xxx del xxx xxx - xxx), Pr"
anyone know how to get the complete filename or how i should decode the filename attribute?
thanks for any help
If you're using IMAP, the IMAP server is parsing the mail headers and returning the parsed values to the JavaMail client. Your Content-Disposition header has several continuation lines. The IMAP server needs to properly combine those continuation lines and return the parameter values. It looks like the server is omitting the whitespace implied by the continuation line and joining the "?=" with the "=?". Without whitespace between them, they appear to be one encoded word instead of two, which likely explains why you're getting the wrong results when decoding them.
Try setting the System property "mail.mime.decodetext.strict" to "false"; this may allow JavaMail to decode the value. See the javadocs for the javax.mail.internet package for details.
When using javax.mail.*, I'm trying to send a message with the content encoded in both text/plain and text/html. How can I add both encodings to the MimeMessage?
Does setText override the previous text set? ie: if I do setText("", "text/plain") then setText("", "text/html"), will the secord call override the message text previously set or will they both be present in the message?
Q: How do I send mail with both plain text as well as HTML text so that each mail reader can choose the format appropriate for it?
A: You'll want to send a MIME multipart/alternative message. You construct such a message essentially the same way you construct a multipart/mixed message, using a MimeMultipart object constructed using new MimeMultipart("alternative"). You then insert the text/plain body part as the first part in the multpart and insert the text/html body part as the second part in the multipart. You'll need to construct the plain and html parts yourself to have appropriate content. See RFC2046 for details of the structure of such a message.
http://www.oracle.com/technetwork/java/faq-135477.html#sendmpa