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

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

 




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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

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