On Jul 22, 2014, at 11:18 AM, Ned Freed
What I would suggest, however, is more focus on results, less on process. To
this end, I will again point out that I've yet to hear a justification for why
we should be talking about issues solely related to message content in RFC
5321. Especially when this separation - rightly, IMO - has been used in the
past to keep issues with RFC 5322 and MIME from creeping in.
Because the SMTP model has evolved to a dual mode operation from one that was
an always accept and process later to one that offered feasible, high scale,
dynamic, online SMTP processing and that included RFC5322 (payload) processing
at the DATA state.
In fact, this evolution has extended to DMARC work expected to be done at the
SMTP DATA state. Same with the new proposed RRVS header work. Even more AVS
processing is done at DATA.
So in the regard, it is all part of the 5321 process. There were a few of us
during 2821bis that highlighted this SMTP evolving point that also included
issues related to session delays and timeouts, i.e. make sure any any shims
processing does not hang or slow down clients, 10 mins is the theoretical
residence time for all scripts run at DATA, 5 mins in all other states. We
even discussed ideas related to "keep-alive" to keep clients connected that may
have shorter timeouts. In fact, as an optimizer, this is why the payload
SenderID protocol has the ESMTP SUBMITTER extension that passes the payload PRA
(purported responsible address) value via a 5321 return path modifier. There
were also an I-D ESMTP extension called HEAD that would allow you to pass the
5322 header block with the idea of doing more future 5322 protocols at the 5321
level before DATA is reached.
SMTP Service Extension for Command HEAD
ietf-smtp mailing list