On 17 August 2011 09:29, S Moonesamy wrote: [<http://thread.gmane.org/gmane.ietf.rfc822/11805/focus=5100>] > I missed the "bug" and it was unfortunately not brought up during > the discussion of draft-ietf-yam-rfc4409bis.
Nevermind, the main issue wrt SenderID's "PRA' was in RFC 2822, and it was discussed and intentionally NOT fixed in RFC 5322. I mainly want to have it on public record that 4409bis also was intentionally NOT fixed for the ambitious goals of SenderID, and that's clear now. For 4408bis I can produce the op=pra draft which never got traction for a demonstration of a good faith effort to "fix" email everywhere for SenderID - and failing everywhere due to lack of support. >From my POV folks interested to highlight a "responsible" party - or more important an ominously missing "responsible" party - in MUAs can use DKIM instead of SenderID, where that "responsible" party is not simply the Return-Path covered by RFC 4408 or its successor. And if they are interested to reject mail a.s.a.p. they can use SPF instead of SenderID's PRA, or pick any scheme they like better. But hoping that 2822bis and 4409bis will make SenderID work as designed would be now stupid, as it obviously didn't happen. For a value of "now" determined by 5322, not 4409bis. > My reading of the reply is that it imposes additional requirements. > If the conclusion is incorrect No, you are right. My good faith effort didn't go so far to publish an I-D trying to fix 4409, but I did that for 4408 with op=pra, and folks were not convinced: After all they already have any SenderID info in their DNS cache when they evaluate SPF, and shortcuts in the PRA evaluation (where that is at all desired) would not help wrt DNS traffic. Senders insisting on getting SenderID right "MAY add Sender", so at least that (interpreting MAY as SHOULD) works for anybody trying it. The more complex syntax issues in 2822 and 5322 fortunately affect nobody else, notably not 4409bis or 4408bis. [6 > See http://www.ietf.org/mail-archive/web/ietf/current/msg68465.html ACK, I interpret that as "John doesn't like RFC 6186", otherwise he would find a way to mention it somewhere. I had my share of "let's try discovery for NNTP" elsewhere, and won't mention it again here. But referencing RFC 5068 (BCP 134) would be good, if readers arrive at a "the IETF really wants this" conclusion. > Section 1.2 will be removed before publication. Oops, right, but the "historical context" in John's drafts is often very important for me, because I have no idea what used to be a say FTP design problem before 1995. Presumably others are in a similar position with SUBMIT issues before 2010, and a pointer to BCP 134 in 4409bis appendix A can be helpful for anybody trying to reconstruct "the history of email RFCs" in the future. -Frank _______________________________________________ yam mailing list [email protected] https://www.ietf.org/mailman/listinfo/yam
