RE: Scope, and a preliminary list of issues

This is a pretty DMP-centric view on Alan's issues.  You've been warned.

I've approached this from the KISS standpoint from the start, adding
protocol only when absolutely necessary (such as when encountering a null
reverse path).  I want to add as little as possible and change as little as
possible to achieve sender verification.  My responses reflect this.

I also believe in a domain owner's right to dictate what may be done with
their domain name.  This is especially true in the real world where Internet
domains are used as trade marks and service marks.

>   For now, I would like to have the author of each proposal to post a
> 1-2 sentence response to each of these issues.  We can then construct
> a "meta-proposal", which contains the overlap of the proposals.  We
> can address any overlap or duplication by comparing the benefits and
> drawbacks of each proposal.

> 	I.1. Proposed design for addressing issues related to EHLO
> 	I.2. Proposed design for addressing issues related to MAIL FROM

Are you treating HELO and EHLO equally?  HELO is still a recognized
identification command.

I focused on the MAIL FROM step in DMP to keep DMP's design simple.  I only
started looking at HELO/EHLO data to deal with null-reverse-path messages,
which still must be supported.  Otherwise, I'd just as soon ignore HELO/EHLO
information to keep the design simple.  MAIL FROM contains just as much
identifying information.

> 	II.1. Do (or should) the designs require DNS protocol changes

No, as we can use existing record types and DNS protocol to achieve
verification.  When TXT was suggested, it was pointed out that a TXT record
could be several kilobytes.  All of RMX could probably be implemented
without creating a new DNS record type.

> 	II.2. What entities in the network have to implement
> these proposals

A sending site's administrators or owners have to add records to their
domains.  A receiving site needs to have their MTA software look them up.

> 	II.3. Do we have existing implementations of proposals
> 	      (MTA, MUA, etc)

Meng Weng Wong coded SPF examples that look up "downlevel" DMP records too.
I've been told of others but haven't seen any hard source code.

> 	III.1. What is the cost of deploying the proposals
> 	       (time, effort, $$)

For a sender-only, nothing should be spent except time spent adding DNS
records.  A receiver would need to upgrade their MTA or add new rules for
it.  Clients of the receiver shouldn't have to do anything at all (ie: end
users) or they're going to whine.

> 	III.2. What is the impact of the proposals on mailing lists
> 	       i.e. Does the behaviour of sender or receiver change?

A lot of list software already uses its own domain in the MAIL FROM command,
often with special IDs to identify whose mailboxes bounce mail.  Even this
list uses it: "[email protected]" appears in my mail server's inlog.

If the list software does this already, it's not adversely affected.  The
receiver doesn't notice anything different.

> 	III.3. What is the impact of the proposals on roaming users
> 	       i.e. Does the behaviour of sender or receiver change?

I've seen two approaches to how a roaming user sends mail:

* Use a relay the user has access to
* Look up MX records and send mail directly

I use srv1.fecyk.ca as a relay to send Pan-Am mail, and I work from several
client sites.  My srv1 uses POPAUTH.  If I identify srv1 as allowed to send
mail for pan-am.ca, and I am allowed to relay mail through it using a
[email protected] MAIL FROM, receiving sites should accept it.  If it's spam,
the receiver can complain to [email protected] knowing it at least came
from someone allowed to use my srv1.  Or I have a security problem needing
fixing.

If I tried to send mail using some kind of direct-to-mx client from say,
some dial-up somewhere or some client site, the receiver doesn't know I'm
not some spammer spoofing pan-am.ca.  I'd expect a receiver to refuse it.

A sender using a server they're allowed to use already wouldn't be affected.
If they run their own server and their own domain, they can identify said
server as allowed to send mail for it.  Even if it's a server running on a
laptop and they roam - Dynamic DNS providers existed before there was a DDNS
spec and they can dynamically change other records besides A and AAAA
records.

> 	IV.1. What part of the spam problem do these proposals address

DMP (and TTBOMK, SPF) address spoofing only.  This is probably all of the
spam I see personally.

> 	IV.2. How can spammers work around these proposals

They could use their own domains and their own servers.  DMP for instance
could allow a spammer to have the entire Internet allowed to send mail for
their domain.

They could spoof a domain that doesn't already have identifying records,
even a subdomain of a domain that has them, provided that receivers don't
refuse mail from sites without those records.

They could spoof a nonexistent domain, provided receivers don't already
check to see if a domain really exists or if it has MX records to handle
mail at all.

> 	IV.3. What is the cost to spammers of working around these
> 	      proposals

Well, setting up a domain might not be expensive but it still requires some
tech knowledge, and access to DNS servers.  We'd probably start seeing
spammers having to learn how to be sysadmins before they could send spam.
Any 'all in one' spammer kit doing all of this would either have to have
access to a central resource (that could be pulled for spam support) or
somehow automate the registering of a domain name and paying the registrar.

Finding domains not using sender identifier records would be easy at first,
until whatever system was adopted widely.

> 	IV.4. How much of an impact do these proposals have on spam

If spammers had to send mail in their own domain names, they'd have to risk
being exposed.  Setting up bogus domains would become more popular for a
little while, but registries like CIRA already require documentation for the
names (ie: pan-am.ca was derived from a registered company name in
Manitoba).

As for the others, I guess the domain registries would get fat from
spammers' money for a while.  :-)  At least until said registries became
targeted for spam support.  Most spammers don't have the cash for investing
in fifty domain names.

> 	IV.5. Does the cost the implementing the proposals justify
> 	      the effort?

I tried to make DMP cheap.  A sender putting up DMP records wouldn't have to
change their mail server software if they didn't want to block mail at all,
but still wanted to avoid being spoofed.  I'd say the price was right.  SPF
fits there too, I think.

--
PGP key (0x0AFA039E): <http://www.pan-am.ca/[email protected]>
What's a PGP Key?  See <http://www.pan-am.ca/free.html>
GOD BLESS AMER, er, THE INTERNET. <http://vmyths.com/rant.cfm?id=401&page=4>