I would like to state my own bias because of the historistical tradition and
design of all mail hosting and transport systems, not just the internet.
This is important, because no new considerations or design is going to alter
this implementation model.
Foremost, the traditional design for SMTP has been for all systems to follow
two fundamental rules, with the first being:
Rule #1: Authentication is required for routing. No authentication required
for final destination.
Of course. the principle problem with the "anonymous-like" transaction
behavior with final destination mail has been the growth in the abuse, a
problem I don't mind saying has been known and documented since the early
1980s. However, the problem was not significant enough until the internet
was introduced into the public. Which brings me to fundamental rule #2
that has its origins in the then new email provisions introduced in 1986
ECPA (Electronic Communications Privacy Act) related to email tampering and
altering the "intent of the user:"
Rule #2: Mail Acceptance must be delivered or bounced. It can't simply
disappear.
What does this rule mean from a implementation and product liability
standpoint, not just for mail transport systems but for all Interactive
Online Mail hosting systems dominate during the 1980s early mail days?
It meant that a rejection policy was legally acceptable at the user input
(online hosting) or for automated systems, at the transport level. If the
mail was accepted for posting, then the system had a responsibility to
maintain a) the integrity of the mail (privacy for example), b) that it was
delivered and c) if it was not delivered, it be returned or a reason
provided to the author as to why it was not.
This gave strength the new "system policies" that were now required by
online hosting systems during a LOGIN process telling users what are the
system policies for acceptable mail. But even with a sysop system policy,
the "intent of the user" was an important factor in any tort, defamation,
malpractice suit.
The exception to the 1986 ECPA rule are employer based mail systems.
Employees do not have the same right covered by the 1986 ECPA provisions.
In any case, to make a long story short, this is why I strongly object to
any design concept attempting to address the "anonymous sender" user problem
that imposes or requires the acceptance of the payload for POST SMTP
analysis.
In my view, it will alter the landscape and will open a major "Pandora Box"
in new legal issues. It already has begun (See Scott Ricther current lawsuit
directly related to "intent" and malpractice), I strongly believe the
promotion of POST SMTP validation is the wrong direction.
Finally, in direct regards to MARID, if MARID imposes a 2822 validation
requirement, this will seriously limit or incur a higher development cost
for its consideration into our package. If it is implemented with a 2822
requirement, that will force our design to provide a DATA hook where this
can be done and still follow the traditional and legally responsible design.
In other words, our MARID implementation will not be for POST SMTP
validation operation.
Hope this remark was not off base. I am strictly stating how we will be
viewing MARID come implementation.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Dave Crocker" <dhc(_at_)dcrocker(_dot_)net>
To: "Jim Lyon" <jimlyon(_at_)exchange(_dot_)microsoft(_dot_)com>
Cc: "IETF-MXCOMP" <ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Monday, June 21, 2004 4:49 AM
Subject: Re: Against Extensibility in MARID Records
Jim,
I think your note is particularly useful for prompting us to consider
what the history of Internet does and does not contribute to the
current consideration.
To state my own biases at the start:
1. For all intents and purposes, the Internet has literally no
large-scale experience with interesting policy mechanism operated
among participants lacking prior arrangement.
2. BGP probably counts as an exception, but we should note just how
constrained it is, if we evaluate it as communicating "policy".
3. The DNS is a simple lookup mechanism and our experience with it is
in producing simple records. both in terms of searching
and in terms of complex records, efforts to make it act more like a
general purpose data based have all failed, or at least been highly
problematic.
4. Reliance on the DNS for core Internet infrastructure operation
dictates that its reliability and performance of those tasks be
guarded vigorously, even at the expense of interesting new
applications.
So with that in mind:
JL> In arguing against extensibility, John Levine argues that it's a bad
JL> thing (he used the word "chaotic") to have information in a MARID
record
JL> that is not understood by everyone.
I took John's foundation statement as being:
One of the main points of MARID, as I understand it, is to develop
something that can be implemented relatively quickly and will
interoperate among senders and recipients all over the net.
These match my own understanding and are extremely important as input
to a design process. History with Internet standards that succeed in
matching these requirements dictate considerable simplicity and very,
very limited choice in the core functionality. Extensibility is
restricted to be outside that core.
JL> To rebut this, I note that substantially every successful data format
JL> and protocol contains buckets for information that isn't globally
JL> understood.
Such information is never part of the core that is needed to get basic
functionality out of the service. Things work quite well without any
of the extensibility.
JL> For example, consider headers in RFC 2822 mail messages.
...
JL> A similar story applies to the headers in HTTP.
Internet protocols used between participants without prior arrangement
must specify a small, tight core that everyone supports, and that
small tight core must do something very useful. Any extensibility must
be optional value-add.
This is certainly true for email headers, for smtp, and for http headers.
There is a very big and very basic difference between extensibility
support between consenting participants, versus extensibility that
impacts non-consenting participants.
It is also worth noting that extensibility is typically a good thing
only AFTER the core is operational. For all of the freedom with
RFC733/RFC822 headers, folks didn't take all that much advantage of
the freedom for many years. And SMTP options did not appear for 10
years. If you want masses of sites to implement something new
quickly, make sure that development and adoption take a minimum of
effort.
JL> Given that we *know* that we'll need more information in the future
The problem is that we have no serious idea what that information will
be. We all think we do, but there is no experiential basis for
knowing what is true. All of the deployed, successful, large-scale
systems use remarkably simplistic schemes. Any expectations that
there will be deployment of clever, large-scale "policy" analysis
engines is not supported by experience, no matter how appealing such
engines might seem.
I think John Levine's follow-up point, about separation of reputation
versus authentication are also fundamental.
JL> (most of us are here to reduce spam, not just authenticate MTAs), it
JL> behooves us to plan the extensibility now.
Please take a look at the history of the SNMP security field. It was
an example of a place-holder provided with similar thinking. Security
obviously would be needed and we would figure out what that meant
later, so let's leave a field that will be define later.
It turned out that the security that was need required a rewrite of
SNMP.
Extensibility is best provided when there is a pretty good idea of the
details that will determine how it will be used. The problem for the
current discussion is that the "pretty good idea" does not have all
that much empirical basis, nor even community consensus.
JL> SPF's current modifiers are
JL> a step in the right direction (they have the ignore what you don't
JL> understand ethos), but as I've argued elsewhere, they aren't
sufficient.
The problem is that there is actually very little operational
experience USING those values to do Internet-scale mail filtering.
JL> PS: John also continues the misconception that anything that uses XML
JL> will be big enough to require DNS TCP. This just isn't true. It looks
JL> like most XML-encoded stuff runs about 20% bigger than SPF-encoded
JL> stuff.
I think the real issue is the generic and potentially unbounded nature
of the extensibility, rather than the syntax used for encoding it. Of
course, verbosity is not without its issues, for DNS records.
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>