okay, I'll try to order this by priority...
1. By far the biggest problem I have with this proposal is the idea that
solicitation classes that are assigned by intermediaries can then be
copied into the SOLICIT= field of the envelope and/or used as the basis
for failure to deliver the mail. This is a showstopper as far as I'm
concerned. Allowing the sender to label a message as an advertisement
is clearly a Good Thing. Allowing an intermediary to label a message
is probably also useful. Combining the two into a single indication is
definitely a Bad Idea that will lead to even more failures of the mail
transport that are difficult to track down and fix. An indication of
sender intent by an intermediary is almost inherently unreliable, and
a lot of the concerns expressed in RFC 3238 seem at least as applicable
to this aspect of your proposal.
The simplest way to fix this is to forbid MTAs and intermediaries from
copying classification information from the Received field (or wherever
else it ends up being stored) to the message envelope. Note that this
doesn't prevent filtering of messages based on classification
information supplied by intermediaries and stored in the message
payload; what it accomplishes is to keep sender-supplied information
separate from intermediary-supplied information.
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.
thanks.
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?
yes, thanks.
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.
5.7.1 will nearly always be the right code. SHOULD should be about
right, and I'd rather see this specified here than in other standards.
My main concern in my last message about responses was that temporary
failure codes might also be reasonable in some circumstances. This
affects both response codes and enhanced status codes.
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.
I'm okay with this.
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.
Mumble. Adding of fields by intermediaries is such a well-entrenched
practice that I don't see any hope of getting intermediaries to keep the
headers pristene. I'll be happy if we can get intermediaries to stop
modifying existing header fields and if we can define future fields in
such a way that it is clear as to who said what.
OTOH, one nice thing about using Received, is that it makes it clear
_which_ intermediary added the classification information. And since
a big part of my concern about labelling of intent is that
intermediaries cannot do so reliably, I really like the idea that we
should keep track of which intermediary said what about the message. If
the information were put in a separate header I'd still want the name of
the intermediary (and where it fit into the signal path) to be included.
So while I'm still not entirely comfortable with using Received for this
purpose, I now see more benefits to doing so than I originally did.
3. You had even stronger objections to having
message senders mixed in with intermediates in one document.
Well, there are really two issues here. The first and most important,
as I mentioned above, is that the current proposal allows
sender-supplied and intermediary-supplied information to go in the same
field in the envelope. The second is that both mechanisms (sender
labelling and intermediary labelling) are being described in the same
document, when the two have very different degrees of reliability and
applicability. The document is our quantum unit of standardization - it
is awkward for us to say "this part of the document is proposed standard
and recommended, while this other part is experimental and dangerous
to interoperability".
Also, the bulk of this document is discussing a mechanism for senders
to label their content, and for MTAs to convey that labelling and to
convey recipient and/or site policies for accepting that content.
The mechanism for intermediaries to label content, while it's certainly
a related topic, doesn't currently get the amount of attention it
deserves.
So I still think that a separate document for intermediary-labelling
would be far preferable. It could certainly refer to the
sender-labelling document as needed. A fallback position would be to
place the intermediary-labelling in an appendix, but I really don't
think it belongs in the same document at all.
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.
I agree that there might be some merit in having a common set of
solicitation classes for sender-supplied and intermediary-supplied
information, though I suspect that if the intermediaries are honest
there won't be much overlap between sender-supplied labels and
intermediary-supplied labels - because intermediaries are simply not in
a good position to judge sender intent. The same message can be either
valid or spam depending on whether the recipient has expressed an
affirmative preference to receive messages from that sender or on
that topic, and that's not information that is likely to be accessible
by an intermediary. I might want to see ads from certain hand-picked
vendors of adult products even if I don't want to receive adult-oriented
advertisements in general.
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."
I don't see how your proposal helps that situation much. We're
inherently going to have different parties with varying degrees of
trustworthiness making sometimes-conflicting assertions about a message.
The best we can do under such circumstances is to keep the various
assertions separate.
Trying to get them to use a common language might help slightly in
that there will be a clear definition of each class. However I think
it likely that intermediaries will mis-label messages if they try to use
classes like those described in this proposal.
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.
Maybe I wasn't clear. I want the protocol definition to support the
ability of a single MTA to impose both system-wide and per-recipient
policies if it wants to do that. I also want the protocol definition
to allow a conforming MTA to request SOLICIT parameters from clients
and convey SOLICIT parameters to receivers even if it doesn't impose
any restrictions on mail relayed through that MTA.
So a conforming MTA should be able to:
a) implement system-wide policy OR
b) implement per-recipient policy OR
c) implement both a system-wide and a per-recipient policy OR
d) implement neither and just convey SOLICIT parameters on relayed mail
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.
I can see why system-wide is useful, at least in some corner cases. I
wasn't suggesting that it be removed.
However, I don't see why it is useful to force a choice. Clearly a
site-wide policy can be implemented using the mechanism for
per-recipient policy, but (with the current proposal) only by forfeiting
the ability of the MTA to say upfront "we don't want this kind of
message". I think it makes far more sense for the MTA to be able to say
"nobody at this site accepts ADV:ADLT messages" and then later on to say
"recipients Alice, Bob, and Carol also refuse to accept ADV messages".
In sum, your biggest issue seems to be the
idea of encouraging intermediate MTA's to
look inside the message.
That seems like a misrepresentation. It's one thing to realize that
intermediaries are going to look inside messages and that we aren't
likely to stop them from doing so anytime soon; it's quite another to
encourage that practice. It's even worse to encourage intermediaries
to look inside messages for the purpose of labelling them according
to some notion of sender intent, because such labelling can never be
reliable. And it's even worse to treat such labelling as if the
sender had supplied it.
Without going into detail right now, a lot of the robustness and
integrity issues raised in RFC 3238 seem applicable here if this
proposal continues to support labelling of messages by intermediaries,
and they certainly apply if the proposal continues to encourage
MTAs to trust such labels for use in filtering.
--
Keith Moore http://www.cs.utk.edu/~moore/