SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message
draft-katz-submitter-01

[Ballot comment]
(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.

[Ballot comment]
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.

[Ballot discuss]
I have serious reservations about the SPF solution.
However, I did not stand in the way of publication due to the consideration
that I rather have a deployed technology documented.

The same considerations and issues as described in the tracker regarding
the SPF draft apply here, except that it is not clear to me what the deployment
status is.

In addition, I think it needs to be made much more clear in both drafts what
the differences are. I don't think it is clear at all whether
senderid is really a version 2 of spf or that it is something different
alltogether.

[Ballot discuss]
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.

[Ballot discuss]
draft-lyon-senderid-core:
This is an experimental RFC.  As such it is not appropriate for
this specification to establish requirements for the Internet.
Requirements language may be used to describe what people complying
with this specification do, but not to describe what the general
internet community must do.  I found two instances where this spec
appears to establish general requirements.

Section 1:

  An e-mail sender SHOULD publish information for both tests, and
  SHOULD arrange that any mail that is sent will pass both tests. 
An
  e-mail receiver SHOULD perform at least one of these tests.

I'd recommend s/SHOULD/MAY/ throughout the above.


Section 3.4 says:
  As described in [SPF], domain administrators are required to
publish
  information in DNS regarding their authorized outbound e-mail
  servers.


proposed: s/administrators/administrators participating in this
experiment/

[Ballot comment]
A custom IESG note is appropriate for draft-lyon-senderid-core-00.
  Some of the points raised by David Kessens on the SPF version 1
  document (draft-schlitt-spf-classic-00) should be captured there,
  as they apply equally well to both documents.

[Ballot comment]
-- draft-katz-submitter-00.txt
This does not comply with our FQDN names for exmaples:

  bob@almamater.edu.example
  bob@company.com.example
  alice@mobile.net.example
and more of those

[Ballot comment]
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.

[Ballot comment]
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)?