Dear IETF,
In response to various strategies to reject IPv6 email lacking either DKIM or SPF, the non-negotiated approach suggests far greater review is needed.
Here is a paper illustrating problems with DKIM.
https://www.dropbox.com/sh/jh4z407q45qc8dd/MlcUTUFUf4/Domains%20as%20a%20basis%20for%20managing%20traffic.pdf
Rather than offering a means to negotiate, returning a 554 response is seen as a way to coerce senders to try other MX records. In https://tools.ietf.org/html/rfc5321 this code does not clarify why a connection has been rejected, but implies in the case of a connection-opening response, "No SMTP service here".
An alternative might be to use existing negotiation techniques for scalable source authentication:
http://tools.ietf.org/html/rfc4954 offers 530 5.7.0 Authentication required
This response SHOULD be returned by any command other than AUTH,
EHLO, HELO, NOOP, RSET, or QUIT when server policy requires
authentication in order to perform the requested action and
authentication is not currently in force.
530 seems like a better response.
421 is far more likely to be understood as fallback for problematic clients, but remembering anything about prior IPv6 clients is unworkable.
http://tools.ietf.org/html/rfc4954 offers a means to properly negotiate enhanced requirements. Since DKIM in its current form can not enhance authentication to a level able to mitigate abuse, it does not justify negotiation. SPF is not about authentication. SPF is an authorization scheme.
Smarthost services for naive senders new to IPv6 could permit an easy introduction to scalable authentication schemes like StartTLS. Formalized negotiations can solve an abuse problem by placing added burdens on senders for a scalable scheme that should prove far more robust. I can expand on this if anyone is interested.
Regards,
Douglas Otis