Does message rfc822 allow a new line in between two headers?
After Content-Disposition I got a newline.
Attaching Image
The Received header (and all of the headers that follow it) are not part of the MIME part headers - they are the content of the MIME part.
This attachment has a MIME-type of message/rfc822 which is an email message. When you parse the content of the MIME part (which starts with the Received header), what you end up with is another message object.
Related
Please, let me know whether my understanding of these things is correct:
Email-message consits of two parts: email-message envelope and contents of an email-message.
Email-message envelope is an information that is formed step by step during
SMTP-handhaking phases on a path of a message from sender's mailbox
to reciever's mailbox (during exchanging command-reply pairs between each
SMTP-client and SMTP-server on a path).
Header section is one of the two parts of a content of an email-message
(along with message body), and initially consists of the lines written by sender along with the body of the message in his email client.
Body of the email message - this thing is self-explanatory.
RFC 5322 specifies the format of the email-message content (header section and message body), and RFC 5321 specifies the work of the SMTP protocol.
Although header section of the email-message is initially formed by sender of email-message along with the body of the message (in his email-client), this header section may be further extended with some header fields containing envelope information during the path of the email-message through different SMTP-servers. For example, SMTP-server can append a new "Received:" header line to the header section. These modifications of header section must be performed according to the rules from RFC 5321 and after each of these modifications the resulting header section must me consistent with the format specified in RFC 5322.
When we open a received email-message with an email-client GUI, we see only the message body and a part of the header section of the message that was initially written by sender of email-message in his email client. But if we want to look at the full header section of the message (with those header lines containing envelope information, that were appended by SMTP servers) we can use options like "show original" in Gmail.
Since nobody answered, I will do it - I have spent some days looking for information about it, have read in RFC 5321 and RFC 5322 the most important moments and hasn't found any contradictions to the assumptions in the question.
As far as I understand Content-Disposition header can by userd for any body part of email message
It specifies the "Content-Disposition" header field, which is
optional and valid for any MIME entity ("message" or "body part")
RFC 2183
I saw that many mail clients set Content-Disposition header only for attachmetns body parts.
The question is: is it normal to set Content-Disposition to inline for message body (text/html/email body) ?
What do you mean by "normal"?
It's acceptable to set Content-Disposition to "inline" for the message body, but as you noted most mailers only use Content-Disposition to set it to "attachment". And setting it to "inline" generally doesn't make any difference to how a mailer is going to display the message. That is, you can't force it to display some content inline if it doesn't know how to, or if only considers additional body parts as attachments.
It is possible to send an email with different content types: text/html, text/plain, mime, etc. It also is possible to use different encodings, including (according to the RFCs) for header fields: us-ascii, utf8, etc.
How do you solve the chicken and egg problem? The content-type header is just one of several headers. If the headers can be any encoding, how does a mail server or client know how to read the content-type header if it does not know what encoding the headers themselves are in?
I can see it if the first line, e.g. had to be the content-type and it had to be in a pre-agreed encoding, (e.g. ascii), but that is not the case.
How do you parse a stream of bytes whose encoding is embedded as a string inside that very same stream?
Headers are defined to be in ascii. They can be in utf-8 if agreed to out of band, such as via the smtp or imap utf-8 capability extensions.
Internationalization in headers is performed via "encoded words", where the encoding is part of the header data. (This looks like a string such as =?iso8859-1?q?sample_header_data?=). See rfc2047.
Content Type headers do not apply to headers themselves, only the body content.
Requirement: To send VB file of records length 100 as attachment using TCPSMTP utility with proper message in body without using IEBGENER utility.
I am trying to send email attachment file VB dataset as attachment. Its working either message in attachment or attachment file in body. But both simultaneously not working.
My JCL is:
//IRTCPN15 EXEC PROC=TCPSMTP
//SMTPIN DD DSN=EMAIL.CODE,
// DISP=SHR
// DD DSN=FILE.TOBE.SENTAS.ATTACH.MENT,DISP=SHR
Here, I have used both datasets EMAIL.CODE and FILE.TOBE.SENTAS.ATTACH.MENT of same specification VB 100 record length. I have also tried using boundary demiliter, but still its not working both together.
Dataset EMAIL.CODE contains:
HELO *******
MAIL FROM:<*******>
RCPT TO: <********>;
DATA
FROM: <******>
TO: <*******>;
SUBJECT: subject data
MIME-VERSION: 1.0
CONTENT-TYPE: TEXT/PLAIN
---Mail Body---
CONTENT DISPOSITION: ATTACHMENT; FILENAME=FILE.TXT
Please suggest me how to send this attachment with body. I have used asterisk due to security reasons. Please feel free to ask if any more information is needed.
In the EMAIL.CODE dataset, you're specifying that content-type of your message is text/plain. However, text/plain on its own (which is the default content type anyway) is always going to appear inline.
In order for the text in the message to be seen as an attachment, you need a Content-Disposition header that specifies attachment.
I can see in your question that you have a CONTENT DISPOSITION line, but it's labeled as being part of the message body. In addition to the fact that it needs to be a header, not a part of the body, it also needs to be hyphenated. So you should have CONTENT-DISPOSITION, not CONTENT DISPOSITION.
However, what all of this gets you is a message containing nothing but the attachment, and your question specifies that you want both a message body and an attachment. In order to do that, your Content-type at the top level needs to be multipart/mixed, and the body of the message needs to contain two MIME parts, one specified simply as being text/plain, and the other also text/plain, but with Content-Disposition: attachment.
This example shows the data for a MIME message containing both a text/plain body and a text/plain attachment.
FROM: <sender#example.com>
TO: <receiver#example.com>
Subject: TESTING message with body and attachment.
Mime-Version: 1.0
Content-type: multipart/mixed; boundary=MIME_BOUNDARY
This is the non-MIME body of a multipart message in MIME format.
Unless you are using a genuinely ancient email client or viewing
the raw source of a message, you should never see this paragraph.
--MIME_BOUNDARY
Content-type: text/plain
This is the inline text section of a multipart message
in MIME format. This is what will appear as the body
of your email when using any normal email client.
--MIME_BOUNDARY
Content-type: text/plain
Content-Disposition: attachment; filename=example.txt
This is the plain-text attachment.
--MIME_BOUNDARY--
.
I am working on a script that will handle email attachments. I see that, most of the time, both content-type and content-disposition headers have the filename, but I have seen cases where only one had proper encoding or valid mime header.
Is there a preferred header to use to extract the file name? If so, which one?
Quoting wikipedia http://en.wikipedia.org/wiki/MIME:
"Many mail user agents also send messages with the file name in the name parameter of the content-type header instead of the filename parameter of the content-disposition header. This practice is discouraged."
So it seems content-disposition is preferred. However as I am using JavaMail, current JavaMail API seems to have only a String getDisposition() method: http://javamail.kenai.com/nonav/javadocs/javax/mail/Part.html#getDisposition(). So you might need to work with the header directly if you are using JavaMail.