On 3/30/2013 7:57 AM, Livingood, Jason wrote:
Mail acceptance for IPv4 worked inclusively - receivers accept unless IP
reputation or other factors failed. IMHO with IPv6 that model may need to
be turned around to an exclusive one - so receivers will not accept mail
unless certain factors are met (like domain-based authentication or the
IPv6 address is on a whitelist). I'd expect MAAWG will continue to be a
good place for mail ops folks to work through this stuff.
Jason (et al),
You are echoing views that have been acquiring quite a few supporters
over the last year or so. While entirely understandable, they face a
number of challenges, not the least being serious dependency on the
unstated particulars. That is, a broad statement of principle, such as
you proffer, isn't enough for evaluating either efficacy of the approach
or its drawbacks; there need to be very concrete details specified, with
careful consideration of the way they will affect /legitimate/ Internet
mail.[1]
One issue does not require that detail:
Specifically, the way v6 mail is discussed assumes that it is
different from -- independent of -- v4 mail. It isn't and it won't be.
It's an extension of the existing Internet Mail service, which is
largely ignorant of the underlying IP layer.
I realize that's not true of the complex protection engines that
have been developed in the face of abuse; but my point is that the
functionality seen by users neither knows nor cares about transport and
below.
Folks might not realize just how multi-protocol Internet Mail transport
used to be.[2] Having mail running in parallel over two 'transport'
systems will merely be a visit back to that. Or, at least, it should be.
To the extent that the basic user experience is different, depending
upon the lower layer being used, Internet Mail is going to be even
messier for those users than it is now.
It's my understanding that messier user experience translates into
higher customer support costs...
d/
[1] Given that the default-deny approach has been voiced for some time
now, the lack of specifications, including how to integrate it with
existing mail, should start to trouble us all.
[2] To Be "On" the Internet, RFC 1775
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net