Re: Last Call: <draft-melnikov-smtp-priority-07.txt> (Simple Mail Transfer Protocol extension for Message Transfer Priorities) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Barry Leiba wrote:
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.

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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]