Hello Hector,
On Mar 28, 2013, at 3:53 PM, Hector Santos <hsantos(_at_)isdg(_dot_)net> wrote:
Hi Doug,
On 3/28/2013 2:13 PM, Douglas Otis wrote:
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.
Whats the difference with IPv6 connections? Should it matter? Does it matter?
IPv6 makes publishing IP address reputations impractical. Since IP address
reputation has been a primary method for identifying abusive sources with IPv4,
imposing ineffective and flaky replacement strategies has an effect of
deterring IPv6 use.
Here is a paper illustrating problems with DKIM.
https://www.dropbox.com/sh/jh4z407q45qc8dd/MlcUTUFUf4/Domains%20as%20a%20basis%20for%20managing%20traffic.pdf
This requires a sign up to obtain/view. Sorry.
Javascript disabled? Here is a simpler alternative:
http://www.bungi.com/Dom-v6.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.
Don't follow. A 55x is a permanent rejection. Not a SMTP protocol instruction
to retry.
The 554 return code is to indicate no SMTP service is at the host. It is
illogical to assume other MX records will offer different results, but that is
the expectation for their pseudo authentication scheme to work.
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.
It may be, but it may force a client to continue a AUTH sequence and thats
not possible if ESMTP is not in place or AUTH is not part of the ESMTP
options.
Improved authentications using a negotiation sequence offers efficient and
robust means for ensuring email delivery integrity. DKIM can not control
abusive sources. SPF does not offer source authentication for mitigation
control either.
Sounds like there are apples and oranges being mixed up here.
421 is far more likely to be understood as fallback for problematic
clients, but remembering anything about prior IPv6 clients is unworkable.
Don't follow. SMTP clients are following a SMTP state machine:
4xx means retry
5xx means don't retry
Some providers are trying to make an exception for 554 to mean the host does
not support SMTP (when DKIM or SPF was not previously seen from a specific
client). This is to imply a need to keep trying other hosts in other MX records
after retrying a 421 code. WIth IPv6, the same providers will also impose a
flaky reverse DNS PTR record requirement as well. For IPv4, these PTR records
helped in the exclusion of residential access. For IPv6, such mapping is also
impractical and represent a waste of resources.
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.
I can interpret SPF as an authentication protocol for IP::DOMAIN association
authentication assertion which allow for the policy-based domain defined
authorization for the sender domain to send mail.
Many domains are obligated to authorize outbound servers being shared by other
domains. Assumptions that authorization means authentication may prove
damaging by holding the wrong domains accountable. Nothing ensures the return
path has been asserted by the return path domain.
This is can be done at the SMTP level prior to the DATA state. DKIM is a
Payload (RFC 822/2822/5322) protocol which would require the DATA state to be
reached first in order to apply any sort of dynamic SMTP online response
other than 250 accept.
Aren't SMTP Auth negotiations the right methodology?
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.
Having a hard time understanding how IPv6 has anything to do with DKIM or SPF
that would be different than IPv4. Even then, why make the distinction?
Does it matter what port is used? The public vs private port? Only with
private port can you raise the bar for client correction (SMTP compliancy)
over what is currently allowed for public port operations where there is
legacy relaxations to allow for anonymous local or hosted domain reception of
mail. Not open relay.
I am getting the idea that you focusing on IPv6 as the trigger to raise the
bar for anything that is currently optional - DKIM, SPF and any other current
augmented email technology.
How do you separate this with IPv4 design requirements that still needs to
the in place, and most likely forever?
IPv6 makes publishing IP address reputations impractical and why some are
attempting a kludge that falls short of authenticating the source or at being
reliable.
Regards,
Douglas Otis