Re: Re: Additional appeal against publication of draft-lyon-senderid-* in regards to its recommended use of Resent- header fields in the way that is inconsistant with RFC2822
"william(at)elan.net" <[email protected]> Mon, 29 Aug 2005 13:55:51 -0700 (PDT)
| Newsgroups | gmane.mail.spam.spf.discuss,gmane.ietf.general,gmane.ietf.mxcomp |
|---|---|
| Message-ID | <[email protected]> |
On Mon, 29 Aug 2005, Frank Ellermann wrote: >> incompatible with RFC2822 > > I'm still a bit lost how this could actually _break_ something. > For obvious reasons the author can't say "updates 2822", how > should he fix it ? As you said the 822 issue is mentioned in > the senderid-pra draft. > > Do you want more "security considerations", something along > the line of "PRA-participants agree to break an explicit MUST > in 2822" ? Its not that easy because participants are not the only ones who see messages from such forwarders (if they ever come into existence) and so as I mentioned the draft actions are not limited to those who agree to participate in the experiment (but at least and unlike re-purposing of v=spf1 records this action would not cause failures as you correctly note). And since this actually breaks standard, this would seem to require explicit action and consent from IESG with understanding about it and update to RFC2822 with consensus and last call if properly done (and there has not been even an attempt by draft authors to ask for review at ietf-smtp or ietf-822 and do last-call like SPF draft author has done voluntarily). I guess its also fundamental question on how seriously does IETF really protect its own standards and follows its own procedures on how they are to be changed. As far as fixing it there are two ways to go about it (and you're correct that I should have mentioned considering its an appeal and there I have to say, not only what I believe is wrong but how it can be fixed): 1. As I already mentioned, IETF can do separate draft that updates RFC2822 and illuminates ambiguities allowing for reuse of Resent- header fields by forwarders. This new draft (and only that draft) would have to go to standard track as proposed standard with appropriate review and last call same as RFC2822. 2. Without changing standard, SID for its experiment (and since none of the systems adding Resent are adding it the way they want right now anyway, so no changes to running systems) can just create new header field and use that - this possibility has been mentioned at MARID btw. -- William Leibzon Elan Networks [email protected]