[ietf-smtp] Proper definition of the term "email payload".

Viruthagiri Thirumavalavan <giri@dombox.org> Sun, 31 March 2019 17:58 UTC

MIME-Version: 1.0
From: Viruthagiri Thirumavalavan <giri@dombox.org>
Date: Sun, 31 Mar 2019 23:27:30 +0530
Message-ID: <CAOEezJRM8ZVaWK6rtvP4ZH9CbN-itVof9_Zi8hf+wVym0cAxzA@mail.gmail.com>
To: ietf-smtp@ietf.org, barry@python.org
Content-Type: multipart/alternative; boundary="0000000000005c2ddc058567a5cf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/8i_gnHqMYjZcnr1jLVFYJgw7Z60>
Subject: [ietf-smtp] Proper definition of the term "email payload".
Precedence: list

Hello IETF,

I need some clarification about the term "email payload".

Wikipedia <https://en.wikipedia.org/wiki/Payload_(computing)> says

*In computing and telecommunications, the payload is the part of
transmitted data that is the actual intended message. Headers and metadata
are sent only to enable payload delivery*

Python email library documentation
<https://docs.python.org/3/library/email.message.html> says this.

*An email message consists of headers and a payload (which is also referred
to as the content). Headers are RFC 5322 or RFC 6532 style field names and
values, where the field name and value are separated by a colon. The colon
is not part of either the field name or the field value. The payload may be
a simple text message, or a binary object, or a structured sequence of
sub-messages each with their own set of headers and their own payload. The
latter type of payload is indicated by the message having a MIME type such
as multipart/* or message/rfc822.*

It looks like Python email library
<https://github.com/python/cpython/blob/3.7/Lib/email/message.py>author "Barry
Warsaw <https://barry.warsaw.us/>" followed similar definition found in
wikipedia when defining his library functions. But I feel like calling ONLY
the email "Body Part" as "payload" is wrong. The term "payload" should
refer to the entire "Message Part" in Email. i.e. Both Headers and Body.

When you place an order for a "box of beer", you are not paying only for
the "beer cans", but also paying for the "container box". So the payload
here is the entire box.

HTTP Example:

HTTP/1.1 200 OK
Date: Sun, 10 Oct 2010 23:26:07 GMT
Content-Type: text/html
Content-Length: 1234

<html>

<head>
<title>Hello World!</title>
</head>

<body>
(more contents)
  .
  .
  .
</body>
</html>



If you take a closer look at this HTTP example, the headers are only just
instructions for the client. The end user doesn't need to worry about any
piece of information found in those headers. So wikipedia definition
perfectly suited for applications like HTTP.

But in Email, When a mail get transferred from Hop A to Hop C via Hop B,
the user in Hop A actually wants to deliver the whole "message part" to Hop
C. If Hop B, strips the headers and transfer only the "Body" part, then it
becomes an "Anonymous" message. So the end user requires the information
found in the "Headers" too. e.g. From, Subject, Date etc. [In HTTP, title
tag is equivalent to Subject and it's found in the "head" Markup, not in
the HTTP Headers]

As you can see, the user is interested in the "entire message". So the term
"actual intended message" should refer to the "whole message" extracted
from the DATA command. The "actual intended message" should be pictured like
this <https://www.dropbox.com/s/2i6mec5fzgu1v6n/messagepart1.png?dl=0> in
email.

Also note that, when you migrate your mails to another mail service, you
need the whole message with Headers, not just the body.

Based on my points, I believe calling only the "Body" part as "Payload" is
wrong. I would love to hear your thoughts on this. If Barry Warsaw is here,
would love to know your opinion too.

PS: I did actually ask this question 2 years back in a stackexchange website
<https://softwareengineering.stackexchange.com/questions/342184/what-is-an-email-payload>.
I wasn't satisfied with the answer I got there. I don't want to use the
term incorrectly in my application. That's why I'm posting it here.

Thanks
-- 
Best Regards,

Viruthagiri Thirumavalavan
Dombox, Inc.

[ietf-smtp] Proper definition of the term "email … Viruthagiri Thirumavalavan
Re: [ietf-smtp] Proper definition of the term "em… Keith Moore
Re: [ietf-smtp] Proper definition of the term "em… Viruthagiri Thirumavalavan
Re: [ietf-smtp] Proper definition of the term "em… Keith Moore
Re: [ietf-smtp] Proper definition of the term "em… Viruthagiri Thirumavalavan
Re: [ietf-smtp] Proper definition of the term "em… Viruthagiri Thirumavalavan
Re: [ietf-smtp] Proper definition of the term "em… Dave Crocker
Re: [ietf-smtp] Proper definition of the term "em… Viruthagiri Thirumavalavan
Re: [ietf-smtp] Proper definition of the term "em… Viruthagiri Thirumavalavan
Re: [ietf-smtp] Proper definition of the term "em… Viruthagiri Thirumavalavan
Re: [ietf-smtp] Proper definition of the term "em… Barry Warsaw
Re: [ietf-smtp] Proper definition of the term "em… Mark Sapiro
Re: [ietf-smtp] Proper definition of the term "em… John C Klensin
Re: [ietf-smtp] Proper definition of the term "em… Viruthagiri Thirumavalavan
Re: [ietf-smtp] Proper definition of the term "em… Valdis Kl=?utf-8?Q?=c4=93?=tnieks
Re: [ietf-smtp] Proper definition of the term "em… Hector Santos
Re: [ietf-smtp] Proper definition of the term "em… Dave Crocker
Re: [ietf-smtp] Proper definition of the term "em… Michael Peddemors