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