Subject: Mail-Transmitter RR

From: David Green <[email-masked]>
Date: Sat, 1 Jun 2002 20:49:48 -0400 (EDT)

I'm sorry if this is off-topic, but I couldn't find a working group that 
is working on dealing with spam, so this is the closest match I could 
find. I know this is in no way related to IPv6 or anything else you guys 
are working on, but it is an idea I had involving the addition of a RR 
type. If this is not the right place to be sending this, any pointers to 
other working groups/forums would be greatly appreciated. And I appreciate 
all of the hard work you guys are doing... My idea is attached 
(domauth.txt)

Thanks,

David Green

---

From: Paul Vixie <[email-masked]>
Date: Sat, 01 Jun 2002 19:49:00 -0700

note that the proposal as written is about smtp source repudiation, not spam.
while it's true that spammers are the most common forgers of smtp source
information, they are by no means alone.

also note that this proposal uses a DNS RR but is not about DNS itself, and
there may be a more appropriate forum for the discussion than namedroppers.
(i wasn't going to release my proposal without further private review, but
the question came up here today and so i sent my working draft in answer.)

> I do like this approcah, though this method only protects against spammers
> (etc) forging those domains that exist and apply this method to protect
> themselves.

exactly.  if i've learnt anything about making spam more difficult, more
expensive, and less effective, it's that it has to be done by someone with
"standing" (such as the recipient or someone whose domain is being forged.)

> While the 'sender domain must exist'  test already acts well
> to protect against use of non-existing domains, spammers will still be free
> to use existing domains that are not thusly protected in their mails.

it is the responsibility of anyone whose domain is forged to add a MAIL-FROM
under this proposal.  there are 30,000,000 of them but at least the ones who
are common targets of forgery will have a way to put an end to it.

> There will also be issues with sites that have off-site MX hosts to hold 
> mail in case of downtime, viz:
> 
> 	$ORIGIN domain.example.
> 	@	IN MX 10 mail
> 		IN MX 20 mail.myisp.example.
> 
> Both hosts in such a configuration will have to be able to perform the
> test, as both may receive mail directly from the sender's MAIL-FROM
> MTAs and the final destination MTA cannot perform this test on mail ...

understood and agreed.  however, i can't think of a less onerous way for a
domain holder to protect themselves against forgery of this kind, and i see
forgery of this kind as a huge huge huge source of domain-holder pain.

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

---

From: Mathias Koerber <[email-masked]>
Date: Sun, 02 Jun 2002 12:00:18 +0800

> domain holder to protect themselves against forgery of this kind, and i
> see forgery of this kind as a huge huge huge source of domain-holder pain.

Neither can I, but my point is that this approach should be combined
with whatever (authenticatable) indication the SMTP folx can come up
with between first incoming MX and further MX hosts into one document,
as this will only be useful if the SMTP server side is properly defined.

mk

---

From: David Green <[email-masked]>
Date: Sun, 2 Jun 2002 11:55:40 -0400 (EDT)

On Sun, 2 Jun 2002, Mathias Koerber wrote:
> I don's see any functionality being destroyed. You will have to make a 
> choice which is more important to you, fast, shortest-hop delivery to
> the nearest recipient MTAs or the protection of your address(es).

Nicely put :) UCE is THE killing factor of using email today. Checking my 
email is a love/hate relationship. At least I have an excellent filter on 
it, but a dozen spams still get through every day. What I don't care about 
is how long it takes me to send one via my isdn (once queued on the 
server, who cares...)

Paul, your proposal is thought out much better than mine. However, I don't 
agree with overloading the MX RR to make this happen. I think that using 
an SRV RR would be a better choice, as this might lead to 
domain-authentication of other services in the future:

    out.smtp.tcp SRV 0 0 smtpsender.asdf.com
    out.http.tcp SRV 0 0 httpproxy.asdf.com

Perhaps even put source port-numbers in there as well...

David Green

---

From: Paul Vixie <[email-masked]>
Date: Sun, 02 Jun 2002 14:47:10 -0700

let's not all start worrying about the wrong things here.

> > As to your plan, I think there is certainly merit to doing it as a
> > private agreement type of thing first. We can see how well it works
> > without burning cycles on the IETF (my own suspicion is that it will
> > be popular with small networks, but unpopular with hotmail et
> > al). If it works, we'll have better understanding for future
> > efforts, and without having to worry about collisions. Not to
> > mention the "running code" value.

> If the IETF system is not completely broken as I suspect it is.  I do
> not see why the draft could not be written, given to the RFC Editor to
> publish as Experimental and then move it to a working group to get it
> onto standards track at a later date.
> 
> If my memory serves me properly (and I am getting on in years now),
> this is what Experimental was all about.

two things.  first, experimental means that the people who have ietf
secret decoder rings weren't properly involved and so they now wish your
protocol had never existed.  SRV is an example, even though win2k and
kerberos use it in production and have wide deployment bases.

second, getting an RFC number can in some cases help with deployment
even if the status is experimental, but this is not one of those cases.
it was nec'y with SRV because the behaviour wasn't going to be optional,
and interoperability of wire formatting was a requirement.

once i'm satisfied that every technical contribution has been made (short
of "this needs its own RR type and wire format") and considered and that
the proposal isn't just plain bad, i'll submit it to the rfc editor as
experimental, and then in parallel i will market it on my own.  years
will go by during which the ietf will do nothing, except perhaps launch
its own deeper effort while rejecting the experimental rfc on the grounds
that it's an end run around the standards process.  later, we'll all have
forgotten about this.  but if it succeeds anyway, then i will resubmit it
to the ietf as a BCP, since by "success" that's what i'll mean.

i hope this doesn't come across as bitter.  several people have tried to
give me my very own ietf secret decoder ring over the years, but though i
have tried, i mostly can't figure out how it's supposed to work.  (all
real progress is either decoder-ring-friendly like IXFR/NOTIFY/UPDATE,
or it's decoder-ring-unfriendly like IMAP and SRV and ICP and HTCP.)

in case my own preferences are unclear, i killed BIND's UID and GID RRtypes
as well as mike schwartz's pre-standard dynamic update support, even though
a whole lot of people were using them, and i did it because things on the
wire have to be, in my way of looking at things, standardized.  MAIL-FROM
adds nothing to any wire format, so i'm willing to take a BCP path to it.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 02 Jun 2002 19:28:38 -0700

> In the example you used above, and I am sure this is the same with
> many large ISPs, UUNET's mail server, mail.uu.net, is actually 5
> different machines:
> 
> mail.uu.net.            300     IN      A       199.171.54.106
> mail.uu.net.            300     IN      A       199.171.54.122
> mail.uu.net.            300     IN      A       199.171.54.245
> mail.uu.net.            300     IN      A       199.171.54.246
> mail.uu.net.            300     IN      A       199.171.54.98
> 
> If I add mail.uu.net as one my MAIL-FROM records, but the server
> delivering the message is actually ashd1-2.relay.mail.uu.net, is that
> message going to be rejected?  I don't imagine most DNS
> "administrators" will know that mail.uu.net is really multiple
> servers.

i note that the server you mentioned...

	;; ANSWER SECTION:
	ashd1-2.relay.mail.uu.net.  59m34s IN A  199.171.54.246

...has the same address as one of the mail.uu.net A RR's.  so, the
published psuedocode...

      repudiated(mailfrom, ipsource) = {
           (lhs, rhs) = parse_addr(mailfrom);
           mxset = get_mx("MAIL-FROM" "." rhs);
           if (mxset == NULL)
                return FALSE;
           mxset += configured(perimeter_relays);
           foreach mx (mxset) {
                aset = get_a(mx.server);
                if (ipsource IN aset)
                     return FALSE;
           }
           return TRUE;
      }

...would indeed permit your mail to come from that host if all you
added to your own domain's MAIL-FROM MX RR was "mail.uu.net".  this
kind of address antialiasing can be a problem, as witnessed by the
PTR RR for this address...

	;; ANSWER SECTION:
	246.54.171.199.in-addr.arpa.  1H IN PTR  ashd1-2.relay.mail.uu.net.

...which can only point to one name even though two names are usable.
however, it's not a problem for the MAIL-FROM proposal as written.

> Secondly, doesn't this have the potential to be abused by mail
> administrators that only kinda-sorta know what they are doing?

no moreso than DNS itself.  i just "tail"'d my daemon.log file and saw...

Jun  3 02:22:36 isrv3 named[184]: wrong ans. name \
	(. != 10.7.118.135.in-addr.arpa)
Jun  3 02:22:36 isrv3 named[184]: invalid RR type 'PTR' in authority section \
	(name = '10.7.118.135.in-addr.arpa') from [192.11.222.170].53
Jun  3 02:22:36 isrv3 named[184]: invalid RR type 'NS' in additional section \
	(name = '7.118.135.in-addr.arpa') from [192.11.222.170].53

...that even without this new-fangled MAIL-FROM business, either a sysadmin
or a protocol implementor (or most likely, both) are able to get the power
cord wrapped around both legs while trying to drill this hole.

> If a mail administrator decides s/he doesn't want to accept mail from
> anyone without a MAIL-FROM record, then it is no longer a voluntary
> action.  ...

internet communication is bilaterally consensual, or doesn't occur at all.
if a mail server operator doesn't want to accept mail from me because i
don't have a MAIL-FROM, then no power on earth can compel them otherwise.

---

From: David Green <[email-masked]>
Date: Sun, 2 Jun 2002 22:49:57 -0400 (EDT)

> "administrators" will know that mail.uu.net is really multiple

I really don't see any choice but to authorize by IP address rather than 
by hostname, not only for security reasons, but also to avoid a double 
query for each incoming mail; one is quite enough. I'm still trying to 
figure out how to handle an ISP that would like to designate a range of 
IPs as valid senders, or one that has a very large number of valid 
senders.

> mail administrator decides s/he doesn't want to accept mail from
> action.  Or is that not going to be part of the functionality?

That would not be part of the functionality in my proposal, although I 
think it would be in Paul's. Any filtering would be the choice of the end 
user (assisted by their MUA). This choice was made to avoid the situation
that you have mentioned here.

David Green

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 3 Jun 2002 09:34:00 -0700

> 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 [email-masked] 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

---

From: Paul Vixie <[email-masked]>
Date: Mon, 03 Jun 2002 13:22:12 -0700

> So do you have a patch to sendmail that implements this draft?   :')

i don't even have a sendmail source pool any more.  sorry.  i'll do postfix
and somebody else can do sendmail.

---

From: Randy Bush <[email-masked]>
Date: Mon, 03 Jun 2002 14:14:13 -0700

> out a migration plan that delivers value to adopters each step of

bingo!

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 4 Jun 2002 08:50:12 -0700

I should have added that Paul's tweak may well have a place to play in such
a scheme however we need to look at the big picture.

Also I think that we need to look at more than incremental measures. The
problem with incremental measures is that they simply perpetuate the arms
race. The SPAMers have time to react to each ad hoc measure and devise a
counter measure - witness the current practice of mining email lists to
harvest sender/receiver pairs in response to registered sender filtering.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 04 Jun 2002 09:55:25 -0700

> harvest sender/receiver pairs in response to registered sender filtering.

i'm still waiting to see a spammer who can reliably beat DCC.

see http://www.rhyolite.com/anti-spam/dcc/ for details.  my take on DCC
is that the thing that keeps it from killing all spam for all time is
the difficulty in widely deploying it, not the technology itself.
spammers who manage to beat the checksum engine will just force a
rolling upgrade.

that's not to say internet messaging technology hasn't been completely
outstripped by cultural "advances".  i look favorably upon XNS in
general and http://www.onename.com/ in particular.  if we can widely
deploy some kind of digital identity standard such that the only way
i'll accept a message (e-mail, popup, etc) from someone is if they've
been trustedly introduced and i have recourse if they violate my inbox's
terms of service, then spam as we know it today can't exist.

this seems far adrift for namedroppers, though.

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 04 Jun 2002 12:51:03 -0500

> the difficulty in widely deploying it, not the technology itself.

There are two reasons why DCC is not a silver bullet. First of all, if you
are EG [email-masked] then you get the message before DCC triggers.
Unless you are willing to delay the mail -- sending in the checksum as
part of the transfer function, wait a while, then check the pool as part
of the delivery function -- it cannot have guaranteed success.

Secondarily, it only works AFTER you have burned bandwidth, processes,
storage and compute time. For hotmail and aol, the only advantage to DCC
is that their customers don't have to see the crap. They're operational
costs are as high as before, if not higher.

Don't get me wrong, things like DCC and Vipul's Razor are both compelling
technologies, and are certainly good tools to use. But they are most
effective when used in conjunction with filters that work at the protocol
level (a la RBLs and the MAIL-FROM.domain hack).

The real objective is to keep the crap out of my spool, and on the
spammer's disk, sucking up his costs rather than mine. Give me more
network filters, I'll use them all.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Paul Vixie <[email-masked]>
Date: Tue, 04 Jun 2002 11:02:11 -0700

warning - this is not dns related.  just hit delete.

> of the delivery function -- it cannot have guaranteed success.

there will be universal willingness to embargo inbound mail for 20 minutes
among DCC users who know that doing so will increase the effectiveness.
(the spammers, to combat this, would have to slow down their spam runs,
which is not technically possible in some cases, and increases the exposure
window for catch-in-the-act even where it is possible.)

> costs are as high as before, if not higher.

and yet the strongest incentive for today's spam is the success of
yesterday's.  i've said for years that the only way to stop spam was to
stop its lifecycle.  (sort of the same as how we cut down mosquito
populations by removing puddles rather than poisoning the adults.)

> network filters, I'll use them all.

yea, verily.  though MAIL-FROM is not designed to stop spam but rather allow
a domain owner to protect his/her intellectual property.