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?
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.
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.
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.
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.
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
It really doesn't matter why. But if you are talking about a
"greylisting" behavior, in my technical opinion, a SMTP Extension
proposal such as SMTPGREY:
http://tools.ietf.org/html/draft-santos-smtpgrey-02.html
is designed to communicate the optimal retry time to clients to help
them minimize the overhead associated with blind server temporary
rejections which puts pressure on the client-side requeuing strategies.
I think the general belief among our peers during the development of
this I-D has been that we should really look for a new and specific
reply code that raises the bar for newer C/S negotiations to take place
with backward compatibility. SMTPGREY attempts to leverage a formal
text response syntax to provide extended response information. For example:
Single line responses:
450 4.7.1. Greylist enabled. retry=00:02:00
451 Temporary rejection. retry=00:00:30
450 4.7.1. Temporary Greylist rejection. retry=01-00:10:00
451 TempFail Retry=00:00:55
421 Your connection is greylisted. Please try again later
(retry=00:01:00)
Multiple lines response:
451-Greylisted. See policy http://example.com/GreyList-Policy
451 Retry=00:02:00
A proof of concept has been shown that this actually works to improve
the communications with MTA and minimizes their delays and retries to
just 2 attempts.
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. 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.
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?
--
HLS