Purported Responsible Address in E-Mail Messages
draft-lyon-senderid-pra-01
Yes
(Ted Hardie)
No Objection
(Bert Wijnen)
(Margaret Cullen)
(Mark Townsley)
Abstain
(David Kessens)
Note: This ballot was opened for revision 01 and is now closed.
Ted Hardie Former IESG member
Yes
Yes
()
Unknown
Allison Mankin Former IESG member
No Objection
No Objection
(2005-02-03)
Unknown
It seems like a good idea to for this work to have documents for experimental deployment. Is it worth adding references to some documents about remedies in the Security Considerations of senderid-core (specifically to how TCPs decrease risks of blind insert attacks and to the ingress filtering RFC, and to the DNSSEC spec)?
Bert Wijnen Former IESG member
No Objection
No Objection
()
Unknown
Brian Carpenter Former IESG member
No Objection
No Objection
(2005-05-20)
Unknown
I have followed Harald's lead = no objection
Harald Alvestrand Former IESG member
No Objection
No Objection
(2005-02-03)
Unknown
Reviewed by Scott Brim, Gen-ART. I fully agree with his comment that "no objection would be useful now", whether one parses "no objection" as a reference to a type of ballot or not..... His review: No objection would be useful now, but one question in case you feel like bringing it up. RFC2821 exchanges are limited to us-ascii. That limits responsible submitter etc. in a way that is kind of last-millennium. There are schemes for supporting UTF-8, but they are not mentioned in these drafts (nor are they on standards track afaik). That might be okay but the *issue* isn't even mentioned. If I had my way I would at least include a statement that 2821 as it stands needs to be extended to support internationalized names and addresses for schemes that use it (2821) to be adequately useful. There are a couple id-nits which will disappear when it goes to RFC.
Margaret Cullen Former IESG member
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
(2005-06-20)
Unknown
draft-lyon-senderid-core-00 sepcifies SPF version 2. The title should reflect this fact. Does draft-lyon-senderid-core-00 obsolete the SPF version 1 document?
David Kessens Former IESG member
(was Discuss)
Abstain
Abstain
()
Unknown
Sam Hartman Former IESG member
(was Discuss)
Abstain
Abstain
(2005-05-25)
Unknown
I cannot support publication of this ballot because I believe that the conflicting use of the spf1 records between this proposal and the SPF proposal is harmful to the Internet. Particularly given that there was marid wg consensus on this point I'm unwilling to block publication over this issue although I understand others may.
Scott Hollenbeck Former IESG member
(was Discuss, No Objection)
Abstain
Abstain
(2005-06-15)
Unknown
(Moving my discuss to a comment to maintain a record of it.) The Sender ID specifications currently reference draft-lentczner-spf-00. That draft has been superceded by draft-schlitt-spf-classic-00. There are some significant differences between the two SPF drafts that might require mods to the Sender ID drafts to preserve older functionality: 1. When the domain name is malformed or when the DNS query returns "non-existent domain", the Schlitt draft now requires receivers to perform a second DNS query at the "zone cut" in order to find an SPF record. When doing the PRA check, the Sender ID drafts specify an immediate "fail." The second DNS query is not needed and can be addressed via an amendment to draft-lyon-senderid-core-00 in order to preserve the currently specified behavior. 2. The Schlitt draft makes a second DNS query at the zone cut mandatory whenever an SPF record for the domain is not found on the first DNS query. The reliability and/or utility of such a check is debatable. In the case of the PRA check, it would appear to require additional DNS queries in very many cases for questionable benefit. draft-lyon-senderid-core-00 could be amended to state that a second query at the zone cut is OPTIONAL when performing a PRA check. References etc. will need to be cleaned up as well.