> -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Barry Leiba > Sent: Friday, March 02, 2012 6:27 AM > To: ietf@xxxxxxxx > Subject: Re: Last Call: <draft-melnikov-smtp-priority-07.txt> (Simple > Mail Transfer Protocol extension for Message Transfer Priorities) to > Proposed Standard > > 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. That's a good example. > An MTA that implements the Authentication-Results header field > [RFC5451] might remove an existing header and add its own. Unfortunately I don't think this one is, because the header changes it encourages take place strictly within an ADMD (specifically, the receiving one), not as a mechanism for tunneling transport metadata through non-participating environments. > 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. RFC6376 also asks for trace header field treatment for DKIM-Signature. That said, this does show that we've dabbled in this area of mushy boundaries, and the results haven't exactly been disastrous. -MSK _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf