On Fri, Mar 2, 2012 at 6:47 AM, Hector <sant9442@xxxxxxxxx> wrote:
> If I understand where you going with this, IMV, I don't think it is a good
> thing SMTP systems should be expected will be processing the payload or its
> headers before the EOD is issued.
This document doesn't specify anything that needs header processing
*during* the SMTP transaction.[1] The specified manipulation would
happen after the MTA had accepted the message, and before it relayed
it to the next hop, so I don't think there's any timeout-sensitive
issue here.
[1] It's possible that if an MTA should receive a high-priority
message that came through a non-supporting MTA immediately prior, AND
it wanted to reject the message based on the priority ("message too
big for the specified priority," or some such), then it would have to
find and parse the MT-Priority header field before giving the OK after
DATA. That seems minimal, but perhaps it could be a problem.
Unrelated to Hector's note:
Does anyone's answer change if I point out that we already have at
least two protocols that have an MTA alter message header fields in
between message receipt and message relay?
An MTA that supports DKIM [RFC6376] might, under some conditions,
remove an existing signature and add its own.
An MTA that implements the Authentication-Results header field
[RFC5451] might remove an existing header and add its own.
Arguments can be made that the former is more of a gateway function
than a relay function (and Ned has already pointed out that we're
pretty sanguine about this sort of manipulation in gateways), and that
the latter is behaving more or less as a trace field, which we also
allow some flexibility with. Also, those specifications aren't
directly part of an SMTP extension, so they're things that are
performed by a server that supports SMTP *and also* something else.
Whereas this manipulation is built directly into the SMTP extension,
as part of the protocol.
No opinions given here as a participant -- I'm trying to tease out the
issues for this document.
Barry, still shepherding
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf