ietf-smtp
[Top] [All Lists]

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

2019-04-01 09:22:33
On 3/31/2019 8:42 PM, Dave Crocker wrote:
On 3/31/2019 10:57 AM, Viruthagiri Thirumavalavan wrote:
I need some clarification about the term "email payload".

The term 'payload' is not a formal term of art in email.  The word
appears only once in RFC 5598, and not in a context that concerns your
topic of interest.  It does not appear at all in RFC 5321 or RFC 5322
or RFC 3501.

Considering the message body as the payload is reasonable in some
cases, but not in others, because there is quite a bit of user-to-user
information in some of the message header fields.

In SMTP context, it's probably safe to say that everything after the
DATA command is payload.  Certainly in terms of typical use of the
word payload in protocol discussions, I think that's a straightforward
assessment.


+1

As with many others here, I've worked and developed client/server/gateway software on multiple mail protocols predating 821/822, and as in engineering and sciences, I always felt the term "payload" was used and understood pretty consistently, at least from my pov.

Overall, Transport mechanisms carry and deliver Payloads, and I believe that is the general concept regardless of technology and protocol level.

Specifically for SMTP (RFC821/2821/5321) protocol, the DATA state, imo, is the payload. That would be RFC822/2822/5322. I rather stick with this (my) understanding as it was in other protocols, not just SMTP. I would not think just the "body" is the payload. The body is part of the payload.

Yet, I can understand how one may suggest the entire SMTP set of input commands is also a "payload" including the QUIT command, for a batch transfers:

  EHLO
  MAIL FROM
  RCPT TO
  DATA
  RFC822/2822/5322
  QUIT

or argue that the body can be delivered by other means other than SMTP, and therefore, it brings it down to what may be considered the fundamentals parts of electronic mail systems: I would suggest is and was:

   DATE:     required, but can be delivery time, not create time
   FROM:     required
   TO:       required by 822, not by 2821/5322
   SUBJECT:  not require, maybe good of UI
   BODY

Thats the common denominator for all the mail systems I have worked on since the 80s. I can use the above as a gateway for as minimum. So is that the "Electronic Mail" or "Messaging" payload?

But the big part of the process is the response/reply process and that is where the "Meta Headers" or want I called Network Control Lines/Headers (and by some old fidonet guys Kludge lines since there is no official field for them)

Anyway, for SMTP, I will stick with DATA as being the payload. Maybe the UI or Application developer can call the body the "payload" but I would also throw in the other above minimum headers for an UI Display "Payload."

--
HLS



_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp

<Prev in Thread] Current Thread [Next in Thread>