Barry Leiba wrote:
On Fri, Mar 2, 2012 at 6:47 AM, Hector <sant9442(_at_)gmail(_dot_)com> 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.
Thanks Barry for your follow up.
I was provided input relative to the generality of your question
regarding an "SMTP system" which you now provided a better specific
example(s) to what I was referring to, case in point.
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.
My question is "when" or does it matter?
Is its done during the SMTP session (DATA before the EOD response) or
is it done after the mail is accepted?
I believe if done at DATA, then we are still talking the SMTP
protocol. If it is done after the SMTP session, then its not really
something we can say is still part of the SMTP protocol.
It also depends on the augmented protocol itself.
Example, as an DKIM implementator, the verification is only done at
the SMTP DATA, no resigning or anything related to "CHANGE" is done
here. Anything close to that is completely outside of SMTP. But.....
An MTA that implements the Authentication-Results header field
[RFC5451] might remove an existing header and add its own.
This is closer to a higher potential for SMTP systems to consider
because of the nature and intent of new receiver message validations
now using a AUTH-RES header to provide receiver processing "state"
information to be either appended (a change) and/or additional
AUTH-RES header added.
But there also the idea that you won't do (change) because AUTH-RES
also provides the machine identity that did the checking and added the
information. So if there are now new state information to add, I
would think you will see want to have some persistency and trace
history of the different hops, machines that did the AUTH-RES state
checks.
I was purely thinking in general terms of how/where an email augmented
protocol would be expected to be implemented for quick plug and play
operations.
To me, AUTH-RES "change" would fits better for your question when all
done in the same ADMD. It is what might be expected and happen in
adding new processing state information DKIM verification and
changes related to stripping/replacement (a already controversial
subjective tampering idea) I would not expect to be "normally" done in
a SMTP receiver.
Of course, its just one person opinion and one input only.
Thanks
--
HLS
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf