I'd like bring the discussion more on-charter, and to use
quantitative terms to describe the problem.
Most of the discussion here has been about user-based consent. The
charter (unclear as I find it) doesn't discuss in detail what is meant
by "consent".
So having a background in Physics, I thought I'd come up with some
math-style new vocabulary to describe *whose* consent we're talking
about. I don't have time to write a draft, but I was able to type up
a few short thoughts, in between other work.
----------------------------------------------------------------------
The Consent 4-tuple
-------------------
The general model for email traffic is that there is an email
originator (end-user), a local SMTP gateway, a remote SMTP gateway,
and a final recipient of the email. To use unique terms:
#--------
email originator -> SMTP sender -> SMTP receiver -> final addressee/user
#--------
In order to better discuss the issues involved, I will define a
"consent 4-tuple". This allows us to make quantitatively descriptions
of consent in SMTP conversations.
The consent 4-tuple is composed of 4 values:
(O,S,R,A) Originator, sender, receiver, and final email addressee
We use tokens to describe consent of each party:
- made a statement to NOT consent to the traffic
0 made no statement
+ make a statement to consent to the traffic.
* all of the above.
- The majority of email today is (+,0,0,0)
Originator consents to send it, sender/receiver make no statement,
and the addressee makes no statement.
- Dictionary attacks on email addresses are: (+,*,*,-), or (+,*,-,)
Originator consents, addressee doesn't consent,
or addressee doesn't exist, and therefore can't consent.
Note that unsolicited email from honest people may
also be (+,*,*,-).
- User spam filtering is (*,*,*,-)
Late in the traffic... bad idea.
- ISP spam filtering is generally (*,*,-,*)
Do you really trust your ISP to filter your spam?
- Originating ISP blocking port 25 outbound is (*,-,*,*)
Early in the traffic, good idea.
- RBL's are (*,*,-,*)
Receiver administers consent.
- DUL's are (*,-,-,*)
Sender declares non-consent, receiver agrees to not consent.
- Open relays are (+,0,*,*)
Why should we care about the spammers consent?
- Open relays (or misconfigured proxies) behind a packet filter on
port 25 are (+,-,*,*)
This isn't a problem...
- RMX (reverse MX) is: (*,+,*,*)
Sender consents to source SMTP, recepient may (or may not) agree.
- The naive "roaming user" is (+,,-,0)
The sender doesn't exist, because the roaming user is the sender
The receiver does NOT consent, because he's being lied to about
where the mail is coming from. (Lack of informed consent==no consent)
- The smart roaming user is (+,+,0,0)
His sender consents to forward the email.
This is also SMTP authentication of the originator.
- SSL certificates (client-server) are (*,+,+,*)
Both S/R consent, because they've been authenticated.
- Spam from well-known domains is (+,+,0,-), or (+,+,+,-)
(e.g. throw-away accounts at otherwise-respectable ISP's)
Everyone consents to handle the data, but the addressee
decides that it's spam.
- Spam with forged "from" lines is: (+,0,-,*), or (+,*,0,-)
The receiver did NOT consent to being lied to.
- Spam with forged "from" lines coming from spam hosts is (+,+,-,*)
- Spam filters like spamcop.net are (*,*,-,*), or (*,*,+,*)
They consent to throw away bad traffic, or to pass only known good
traffic.
- A happy world is (+,+,+,+)
The problem is that (+,+,+,+) is a MUCH smaller space than
!(+,+,+,+). This means any implementation based on declared
non-consent will be hugely more expensive than one based on declared
consent.
Alan DeKok.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg