Hi Keith -
multiple layers of response here:
Indeed. A very useful note. Thanks for the careful read of
my draft. As always, I think I agree with 95% of your
comments, though I suspect you might feel strongly about the
other 5% as well. :)
Layer 1: generally about standardizing spam countermeasures
I agree with your comments about overall strategy (e.g., not setting
too quickly on one solution, not doing harm, making sure pieces
don't conflict). I think those issues are important, and that is
clearly an IESG call. I'm fine with experimental, proposed, or
even a no-action action if that's what people want.
A lot of the spam countermeasures in use seem to me to be actually
harmful in that they decrease the ability of the mail system to deliver
legitimate messages reliably. Even if you consider that not filtering
spam also affects mail reliability (either because it overloads mail
systems or because it overloads recipients who might accidentally
delete a legitimate message embedded in a large batch of spam), some
spam countermeasures still seem to do more harm than good. User
experience varies - what works well for one group of users may not work
well for another.
I agree 100% ... there were 2 motivations for this draft:
1. The fact that esmtp had no way for the receiver to indicate
that they don't want to be solicited.
2. The fact that our mail headers are being littered with
insertions by filtering software and, increasingly with obscure
markings like "ADV" required by policy makers.
My hope was to provide a very simple, friendly-to-the-architecture,
and neutral means of transporting this information. I specifically
stayed away from authentication, consent, and many other issues
because I don't know how to solve those.
And, it may be very true that what I'm trying to accomplish fits
in a more comprehensive solution that addresses those issues,
or maybe in a less comprehensive solution. What I do know is
that I don't see any less/more comprehensive solutions to this
particular problem on the table and, hopefully, my draft
will fit in the "can't hurt, might help" category.
For your specific comments, some are very easy suggestions that
I'll work into the draft quickly:
1. I agree the grammar is confusing being spread out. I'll
keep it as is because it leads the reader through the pieces,
but then collect those pieces in an appendix.
2. I picked 3 sample classes because I needed something for
examples. Let me move those to the appendix, mark them
clearly as "not part of the standard," modify the grammar,
then use them in the text as examples. Does that work for you?
3. You had some good comments on enhanced status codes. I've
now received 3 suggestions on the answer (from you originally,
then Eric Allman, then Ned). I think that section (2.3),
should be looser: point out 3 possible error codes, say
that this is a topic of other standards.
4. You pointed out some ambiguities in the relay language.
I agree that should be tightened up.
5. Section 3 can easily be deleted. I put it in for a
different audience. :)
Some of your other comments I don't necessarily disagree with,
but they are issues that I've wrestled over many times as
various reviewers have commented. I'm not saying I necessarily
got it right, but let me try and explain how we got there.
1. You worried a bit about the comma-separated list of
keywords. As you guessed, the reason was to keep a
uniform syntax in all four places: EHLO, MAIL FROM and
answers, Solicitation: header, and received: header.
Comma-separated with no spaces and a limited character
set seemed like the easiest solution.
2. You had a strong objection to the trace fields for
two reasons: the basic idea of an intermediate
doing things and the mechanism of the comment field.
I agree intermediates should leave the message alone.
Today, most spam filters inject new, non X- headers
into messages. It seemed to me that 2821 and 2822
would both be happier if that gunk was moved up to the one
line those folks were supposed to touch. The use
of the comment mechanism was Ned's request: he says
we've burned that bridge before and that was the
best place for this information.
3. You had even stronger objections to having
message senders mixed in with intermediates in one document.
It seems to me that in the real world, both actors
are going to be conveying information that is
similar, and I've tried to come up with a uniform
mechanism that allows the user to ultimately sort
out who they want to trust. Today, it would be
hard for my MUA to correlate an "ADV" in the
subject line, my Spambouncer headers that tell
me this might be pornography, and the senders
first MTA that inserted headers saying "this is
clean."
4. You indicated that we might want to do both
SYSTEM-WIDE *and* PER-RECIPIENT (e.g., more
restrictive policies for one user). I thought
about that a lot and was worried that implementation
becomes significantly harder. My goal with
system-wide was to provide a *really* easy entry
point. I could hack sendmail to do system-wide: there
is no way I could program per-recipient myself.
Note also that people seem to have strong opinions
about which of the two is most useful. You
indicated that system-wide wasn't very attractive
to you ... others feel strongly that they would
*only* use system-wide. For that reason, I felt
it best to allow both "styles" but force a choice.
5. You mentioned more general restrictions,
e.g., no application/msword documents, and
your worry that those mechanisms might conflict
with no-soliciting. You'll notice my draft
is really about transporting labels and does
not to deal with issues such as "are the
labels true" and "what actions should we take."
So, I agree with the potential for my
approach for bumping into more general solutions
in the future, and would only point out that
those solutions don't seem to exist yet and
that I've tried to set up no-soliciting so
that it is carefully isolated and fairly simple
so that it *could* coexist in the future.
In sum, your biggest issue seems to be the
idea of encouraging intermediate MTA's to
look inside the message. I really think
that bridge was burned a long time ago and
if we can at least move those labels up into
a trace field, maybe they'll leave the messages
alone? (BTW, when I envision how this will be
used, it seems to me that the only mta that
would do anything are the ones "close to
me" such as my isp and my host, but I understand
your worry about MTAs in the middle.)
I hope I've addressed some of your concerns.
Thanks again for the thoughtful analysis.
Carl