Re: A new transition plan, was: Re: the evilness of NAT-PT, was: chicago

On Jul 7, 2007, at 11:19 AM, Iljitsch van Beijnum wrote:

> On 6-jul-2007, at 20:53, Douglas Otis wrote:
>
> > How will SMTP servers vet sources of inbound messages within an  
> > IPv6 environment?  Virtually every grain of sand can obtain a  
> > "new" IPv6 address.
> Simple: look at prefixes rather than individual addresses. If  
> 2002::2002 is a spammer, then you may want to assume that  
> 2002::2003, 2002::2004 etc are also spammers. With IPv6, the "CIDR  
> distance" between nodes under different administration should be  
> considerably larger than with IPv4, where you'll often see systems  
> belonging to different people on consecutive addresses.
Recommending CIDR blocking will not win accolades.  This is one of  
the evils most want to avoid.  The dynamics of IPv6 addressing is  
part of the problem.  IPv6 might utilize a translation of some IPv4  
address, perhaps of a session crossing through the IPv4 address space  
into IPv6 address space via gateways.  These translations will likely  
be dynamically assigned.  Just the ease of being able to obtain a new  
IPv6 address represents a problem although this is also touted as a  
feature.  IPv6 address vetting is unlikely to effectively track bad  
actors, nor will reverse DNS be all that useful.
> > An IPv6 address may traverse any number of translation points as  
> > well.
> Huh? What are you talking about?
There will be many ways to bridge between the IPv4 and IPv6 address  
space.
> > This complex topology spells the end of SMTP in its current form.
> And that's a bad thing?
Probably not.  However, the IETF might want to consider what is  
needed to transition into something more robust once IPv6 space is  
allowed to send email.  Difficult to obtain non-volatile references  
are essential for tracking abuse history.  The difficulty is with the  
difficult-to-obtain reference.
PNRP depends upon groups.  Groups work in a fashion similar to that  
of a mailing list.  This suggests there could be intermediaries  
offering references.  Evidence of abuse should be limited to the  
transmitting domain and not the individual.  Dealing with abuse  
should be internal to the domain.
Limiting accountability to the domain is a major sticking point  
within the current email infrastructure.  Those transmitting messages  
into public servers wish to avoid accountability.  However,  
accountability simply does not scale down at an individual to  
individual level.  There must be some form of collective  
accountability established.
One way this could be accomplished would be to create a message that  
is nothing more than a URI.  This could be done in a manner similar  
to BURL.  The URI could be constructed of a double hash of a time- 
stamp, source identifier, and content.  Message storage and retrieval  
could even utilize object storage.
The "group" would be the web URL where the sender stored the  
individuals' messages.  Recipient access could depend upon either the  
obscurity of the double hash or handled by a scheme similar to  
OpenID.  This approach should scale, and yet ensure references are  
obtained from those offering an HTTP message access service.  This  
would allow combining both SMTP and HTTP into a unified URL  
reputation vetting system independent of any underlying IP address.
> It's the fundamental lack of, well, everything, in SMTP that allows  
> all this spam that we're suffering from these days and makes it  
> impossible to get rid of things like the base64 encoding overhead.
The transition will likely need to be evolutionary and not  
revolutionary.  MUAs could be modified to handle either form of  
messaging.  At some point, those still using the old methods will be  
too few to matter.
> Build a better mousetrap rather than complain that the mice don't  
> like the cheese.
Agreed.  But is this something the IETF will even consider?  Are  
there too many vested in the old mousetrap?
-Doug




_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf