1. If consent can be "expressed" in some sort of a document or
data structure, that "expression of consent" can be communicated or
moved from the local periphery of the system into the more global core.
Thus, I, my ISP, or my organization, might prepare an "expression of
consent" that states that mail will not be accepted if it exceeds
certain sizes, contains certain elements (such as attachments) or is of
a "commercial" nature.
I think an important aspect of such a consent-based system is precisely that
the
sender (or spammer or whoever) MUST NOT BE ABLE TO INQUIRE IN ADVANCE regarding
what (hypothetically) would and would not be accepted.
A classical problem in computing is when one system misleads another into
making
an irrevocable, wrong decision.
One example of such a problem is where the sender inquires about what I'm
allowing today, and finds out that I've turned off HTML from unlisted senders.
They proceed to send me plain ASCII text. The problem comes from the fact that
I could change my policy regarding that sender AT ANY TIME. So they might ask,
for example, if they can send HTML... my server says "sure! You're approved"
and meanwhile I turn off their permission. Now they send me HTML-burdened mail
and it says "sorry! Not allowed" and they look bewildered and say, "WHAT
GIVES?!"
Here's another example. A common request to system designers is "tell me how
much free space is on such-and-such-a-volume". The OS returns a message saying
"I have this much" and the application then presumes it can write a file that
big. But by the time it gets there, the space has already been used by someone
else... a far better solution is to go ahead and create the file you want,
position out to the end of it and write the last sector to allocate the space
(presuming that it DOES that in your system!) and THEN proceed to transfer your
data into your (now assured!) disk space. That way, you don't get caught
short,
and you don't make a (perhaps irrevocable) decision based on data which later
turns out to have been inaccurate.
I think that the RECIPIENT should adjust the permissions to gate in what they
EXPECT the sender to send, based on their knowledge of what that sender DOES
send. (And hopefully can set the options so their sender will send plain ASCII
text!) The point is that you allow what you want and expect, and simply gate
out everything else as unexpected and atypical and therefore probably wrong.
As an example, Aunt Gertrude is on AOL and sends their stupid default
HTML-burdened E-mails, but those never have anything in them much beyond
boldface, italics, maybe a couple of font changes... never scripting or
convoluted hyperlinks, tables, ActiveX, or such. If she ever sent me an
attachment, it would be nothing more scary than a JPG file. So ideally I could
set her permissions to allow her to do [only just!] what she's likely to do.
It's not unlike a credit card company which develops a feel for the pattern of
your use of your credit card, and then when they suddenly see a highly atypical
purchase for $500 worth of tequila at a liquor store in the far other end of
your city... they might call you at home to try to verify that the charge is
yours, and that you still have your card. That's really the goal of the
permissions system... to allow the people you know and trust to (just) do what
you expect them to do, and send you what they send you. People who you don't
know (yet) can still reach you by using least-common-denominator, safe and
universal stuff like plain ASCII... and once you've developed a relationship,
you can upgrade their permissions (if appropriate and necessary) to allow them
somewhat wider range of expression if the recipient deems that appropriate.
But I do NOT believe that "just anybody" on the Net should be able to inquire
about what you do and don't permit. They ought to (like creating the big file)
simply try it and it will either work or it won't. (Or, better yet, simply
send
the COMPATIBLE UNIVERSAL format to begin with, and never PRESUME that they can
send anything else unless they clear it with the intended recipient first...)
Besides, for privacy reasons, I don't want anybody else but me and my ISP or
domain provider looking at my personal permissions list.
If this expression can be accessed by arbitrary
nodes, then either sending nodes or intermediate nodes would be able to
determine what had been consented to and decide whether to originate or
relay any particular message.
I think that approach, while it might sound appealing, is a VERY bad
architectural model.
A very simple version of such a system would be created if we
were to adopt something like the "donotcall.gov" system which is used to
block telemarketing calls in the US.
There is a BIG difference, though. There, everyone is pretty much in the same
boat ("a telemarketer is a telemarketer") and there is a Federal law waiting to
prosecute those who misuse the phone numbers on the list they get.
2. If systems that rely on "licenses to send" or
recipient-issued tokens are deployed, then depending on the way these
things are implemented, upstream nodes would be able to inspect the
licenses and determine whether or not a particular message was, in fact,
authorized.
Except for the fact that they probably CANNOT.
Again, consider the case of a Yahoogroups mailing list. Messages are either
delivered individually (bearing the name of the sender) or as a digest (and
thus
bearing the name of the list). Another point is that a digest might have a
largeish number of messages from different people, and IF those people are in
fact known (or some of them known) to the recipient, they MIGHT have different
permission rules.
And like the challenge-response issues I mentioned in an earlier post, there is
really no way in general for a recipient (or even his ISP) to reach back and
figure out how to contact (directly) the "original" SMTP server which
originated
the message (at least certainly not by the return address).
Depending on implementation choices, non-authorized messages
could be either discarded, subjected to more or greater "spam-detection"
inspections, or routed at lower quality of service.
Actually, the solution I like best of the ones I've heard so far for this is
(again) the solution I proposed... where periodically a "digest" of suspected
spam messages (say, one or two lines each) is sent in an E-mail to the intended
recipient, so that they can vet them in a sort of triage and ask their ISP to
move false positives back into their 'to be delivered' queue. This allows the
recipient to (in a single E-mail) quickly scan down a list of maybe as many as
a
hundred or more E-mails and decide which ones they want to look at.
In a way, this is like the newspaper. If you get a daily newspaper, few if any
people read it cover to cover. Instead, you can leaf through it and
pick-and-choose the articles and items that look like they might be interesting.
(And HOPEFULLY, legitimate senders will quickly learn that sending
unanticipated
mail in anything other than plain ASCII will reduce dramatically the likelihood
that it will ever be read...)
Gordon Peterson http://personal.terabites.com/
1977-2002 Twenty-fifth anniversary year of Local Area Networking!
Support the Anti-SPAM Amendment! Join at http://www.cauce.org/
12/19/98: Partisan Republicans scornfully ignore the voters they "represent".
12/09/00: the date the Republican Party took down democracy in America.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg