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

[Hector Santos <[e-mail]>]

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