| Hello Hector,
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:
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
|