Re: Sufficient email authentication requirements for IPv6

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]