RE: Mail-Transmitter RR

["Hallam-Baker, Phillip" <pbaker@verisign.com>]

> Leathering through RBLs, reverse-path verification, keyword filters,
> distributed checksums, are all things that people use now. An 
> authorized
> sender RR/owner/whatever is just another tool in the 
> toolbelt.

I think that this is the key to adoption, think of incentives that
are created that drive adoption. Any protocol change that requires
mass adoption before it provides value is going to be a hard sell.

I think that the problem of SPAM needs more than just a DNS tweak
or two. I think that we need to take a more systemic approach, work
out what it would take to build a mail network that severely 
discourages SPAM, claculate the delta to what we have today, work
out a migration plan that delivers value to adopters each step of
the way.

Email messaging has in any case been in need of an overhaul for a
long time. SMTP has suffered the fate of many 'simple' protocols,
inadequate analysis of the requirements and under-engineering of
the initial specification has lead to numerous ad-hoc extensions
and work arrounds with the result that we don't have a standard,
we have a set of heuristics. Handling of mailing lists is 
particularly broken.


What we need is some sort of summit that brings together the people
working on the various parts of SPAN control strategy. Real Time
Blacklists are not a long term solution that many are invested in,
especially as the scum attempt to litigate their way off lists with
strategic lawsuits.


First consider the possible incentives for adoption of spam control
infrastructure for the sender:

1) Reduced probability of appearing on Real Time Blacklist

2) Allow recovery from the stolen email address problem in which 
	a spammer uses a genuine email address (often taken from a 
	mailing list) to send SPAM, thus causing the email address to
	become unusable due to complaint backlash.

3) Comply with regulatory controls
	Yes I know these are unpopular in the states, however,
	coertion is a legitimate tool and coertion by democratic
	elected governments is preferable to coertion by unelected
	self appointed vigilantes which is what we often have with
	black lists.

3a) Discourage imposition of regulatory controls
	The US version of argument 3...

4) Reduce the cost of email management.

5) Reduce the number of messages that are erroneously rejected


BTW I don't believe that configuration alone will lead to blacklists
becomming unnecessary. I have personal experience of an Israeli ISP
which bombarded me with SIRCAM virus and refused to cut off their
'subscriber' (I suspect that it was the ISP network administrators)
until threatened with blacklisting.


I think that architecturally we need to take a systemic approach that
includes such components as:

1) Means of authenticating origination points.
	These are likely to involve both public key techniques and IP
filtering techniques

	Public key mechanisms are likely to involve both authentication of
the services (via SSL) and authentication of actual messages. Here we need
to fullfil a longstanding hole in the email security world, establishing an
authentifiable binding between the email security mechanism and the DNS
system:

	IE if I want to send email to warlord@mit.edu I should be able to
query mit.edu, pull up an SRV record for a key location service (no not a
directory, LDAP is not a good place to put PGP keys and a pretty bad place
for X.509 certificates). The key location service gives me a chain of PGP
keys which I then forward to my validation engine to get out a raw key and a
policy (Derek signs all his mails so reject unsigned mail as SPAM). Equally
if you look me up via the SRV record of Verisign you will get an X.509
certificate and a policy (I sign all my mail too).


2) Means of advertising origination policy.

	The Mail From: hack described by Paul is essentially a means of
advertising policy, it is similar to work that has been going on in the
context of Web Services security, how do I advertise the fact that my
service always authenticates its responses or accepts a certain level of
security enhancement to prevent downgrade attacks?


The technical mechanisms employed to support these mechanisms are likely to
include:

1) DNSSEC (solve the SPAM problem and you have a killer app for DNSSEC)

2) DNS Records 
	Possibly the SRV record to a client oriented service
	Possibly new records that are client oriented

3) PKI in the form of PGP, X.509 and possibly SPKI

4) XKMS responders to navigate the disparate PKI infrastructures on behalf
of clients
	Possibly the XKMS protocol is extended to support publication of
security policies.

5) Clients with enhanced SPAM rejection capabilities leveraging the above.

6) Mail server with enhanced SPAM rejection leveraging the above.


		Phill

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>