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