multiple layers of response here:
Layer 1: generally about standardizing spam countermeasures
Part of the difficulty with standardizing spam countermeasures is that
there's probably no comprehensive solution to the spam problem - thus
any proposal that was not grandiose in scope would arguably fail the "no
known technical omissions" test. Unfortunately, there is a potential
for partial solutions to conflict with one another - either because
they're trying to solve the same problem in different ways leading to a
lack of uniformity, or because use of one spam countermeasure precludes
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.
If we're going to start standardizing spam countermeasures I'd like to
see IESG or the Apps area adopt a strategy for dealing with the variety
of proposals I suspect we're going to see, as various groups seek to
gain legitimacy for their work. For instance:
1. Since I doubt we'll be able to decide exactly which set of
countermeasures should be widely implemented, my guess is that we'll
end up publishing several competing proposals at Experimental and/or
Proposed and re-evaluating them after a time in light of operational
experience and market acceptance. If we are going to do that we should
publicly say so up front, so that we have some semblance of uniformity
and we aren't as likely to be accused of favoritism.
2. Some spam countermeasures are "riskier" than others, in that they
use less-than-reliable criteria for classifying mail as spam, or they
adversely affect mail reliability for other reasons, or they change
SMTP or the mail format in inappropriate ways. If we are going to
publish risky proposals I'd strongly prefer that we publish them as
Experimental rather than Proposed. Proposed standards should "do no
However there still might be some value in publishing risky proposals
as Experimental -
First, to invite review of those proposals by experts within IETF and
where feasible, to encourage modification of those proposals to minimize
their potential for harm
Second, to encourage modification of those proposals so that conflicts
between them are minimized;
Third, to provide the opportunity to clearly label which proposals are
seen to be risky and for what reasons
Fourth, to encourage better collection of experience with
implementations of such proposals (since people are already widely
using risky countermeasures, we can't expect to stop them - but we might
as well try to learn from it)
Layer 2: this proposal specifically
1. The basic idea seems good and "mostly harmless", but I think it needs
substantial revision before being adopted. With appropriate changes,
I'd recommend it for Proposed PROVIDED there's a pre-announced policy
on how we're going to deal with similar proposals. I don't think we
should be appearing to endorse this specific approach over other
approaches at this time.
2. [section 2] Nit: to me it seems confusing for solicitation-keywords
to be a single ehlo-param (in RFC 1869/2821 parlance) and for the
keywords to be comma-separated. I'd like to see us keep EHLO responses
fairly simple and uniform in format. Have we had comma-separated
keywords in other EHLO responses?
I guess the idea is to keep one syntax for "solicitation-keywords"
that can be used in both EHLO response and MAIL FROM command. That
might be better than having two separate grammars.
3. [section 2] Nit: it would be better if the entire grammar for
the EHLO response were in one place, rather than spread over
4. [section 2.1] Nit: the last paragraph seems out of place;
I think it should go in an acknowledgements section near the
end of the document.
5. [section 2.2] I understand the need to define some initial
solicitation classes but I'd like to see us avoid endorsing
these. The MAPS-UBE class in particular, while it makes an
interesting topic for discussion, doesn't strike me as something
that we should endorse by making it a built-in part of a standards-
track protocol. 2.2.1 does say "for illustrative purposes only"
but similar disclaimers in other standards have been disregarded.
More generally, what I'd like to see is a separation between the
specification of the protocol engine (i.e. the grammar) and the
specification of solicitation classes. (I realize that we've
traditionally included some keywords in grammars for other protocol
specifications. I think we need to stop doing this, as it makes
the grammars more complex and less useful for both protocol
implementation and constructing protocol verifiers.)
So the protocol engine is what should be standardized, and we should
have some initial solicitation classes registered that are not part of
the standard (they could go in an appendix to the document labelled
"initial solicitation class definitions" that says "not part of the
It would be okay with me to use some of the initially defined classes
Finally I think this is one of those cases where x- fields might not
be a good idea - at least, I'd like to encourage public review of
new solicitation classes.
The grammar should be rewritten to reflect these various changes. For
Solicitation-keywords = registered-word 0*("," registered-word)
registered-word = ALPHA 0*(wordchar)
; registered-word(s) are registered
; with the IANA
wordchar = ("-" / "_" / ":" / ALPHA / DIGIT)
6. [section 2.3] Is it possible that the recipient doesn't want to
disclose the reasons for rejecting the mail? Perhaps there should
be some generic indication that the message was rejected due to
policy rather than because the recipient address was not valid.
(550 is the right code but is probably overused.) Or maybe this
proposal should just require ENHANCEDSTATUSCODES as 5.7.1 is a
clear indication that this is a policy violation without saying
exactly what policy is violated.
If nothing else this should make clear whether the policy indication
is in some machine-readable format (is it part of the protocol?
if so, what's the precise syntax?) or is meant to be human readable.
Is it conceivable that a recipient might be willing to accept some kinds
of solicitation but impose various limitations or quotas on that kind
of mail? In this case a 4xx error code and 4.7.1 status code might be
appropriate to indicate "go away, come back later".
7. [section 2.6] I have strong objections to various parts of this
- Most of this proposal is about giving the sender a way to assert
that a message is a solicitation, and that seems to me to be
"mostly harmless". Giving intermediaries a way to make similar
assertions is "risky" and I don't think such a practice should be
For example: a sender can assert (rightly or wrongly) that an
advertisement is solicited by a recipient and be in a position to know
whether that assertion is true; an intermediary cannot be expected to
know whether such an assertion is true.
- Letting intermediaries' assertions get confused with the sender's
assertion (as provided for in section 2.x) is even worse, and I'd regard
that as something that should not even be published as Experimental.
- Even accepting that it's useful for intermediaries to make assertions
about the solicitation classes of a message, it's not at all clear
that the classes that can be asserted by an intermediary are similar
to those that can be asserted by a sender. An intermediary can
make assertions about content (e.g. "this message contains a GIF image")
but is not in a good position to make assertions about intent.
- Even accepting that it's useful for intermediaries to make assertions
about the solicitation classes of a message, I don't think the Received
field is a good place to do that, and I don't like the idea of storing
protocol elements in comments or of having MTAs read and trust the
contents of comments. MTAs should as much as possible treat message
content as opaque.
I strongly recommend that this document NOT provide a way for
intermediaries to make assertions about solicitation classes,
as that seems orthogonal to the main purpose of this document,
and it seems to make it much riskier.
Even accepting that it is useful for intermediaries to make
assertions about solicitation classes, the protocol for doing this
should be defined in a separate document, and those assertions should be
kept cleanly separated from assertions made by the message originator,
and there should probably be different classes for those indications.
8. [section 2.7] The wording is muddy. It appears to apply only
to SYSTEM-WIDE, and that doesn't seem right.
IMHO, anytime a server asserts NO-SOLICITING in EHLO, this means:
- if NO-SOLICITING SYSTEM-WIDE is asserted and a set of prohibited
solicitation classes is included, client SHOULD NOT attempt to relay
mail for which the SOLICIT= MAIL FROM parameter includes a class that
is prohibited in the EHLO response.
(however if the client does so it's still the server's responsibility
to reject it)
- regardless of whether a set of solicitation classes is included
in the EHLO response, client MUST convey SOLICIT= faithfully (i.e.
as received from the previous hop) in MAIL FROM for each message
relayed to a server that supports NO-SOLICITING.
9. Actually I suggest getting rid of the SYSTEM-WIDE and PER-RECIPIENT
keywords. Here's why:
- it's useful to allow a combination of SYSTEM-WIDE and PER-RECIPIENT
policies, rather than to force one or the other. The SYSTEM-WIDE
policies would apply to all recipients supported by that server,
but individual recipients could have more restrictive policies.
- it's useful for an MTA to have the ability to relay SOLICIT=
indications even if it doesn't actually impose system-wide or
per-recipient restrictions. Yes, it could claim PER-RECIPIENT
and then never impose any restrictions, but that seems misleading.
I'd also suggest changing the name of the EHLO keyword because
supporting relaying of SOLICIT= doesn't imply that the MTA has any
restrictions on soliciting. So I suggest:
- rename the EHLO keyword something like "RESTRICT"
- allow the EHLO keyword to have system-wide options. e.g.
RESTRICT means that the SOLICIT= keyword is supported but that
no system-wide restrictions are advertised, and
RESTRICT=class1,class2,... means that the SOLICIT= keyword is
supported and that class1,class2,... are prohibited on a
10. Somewhere some text like the following seems appropriate:
Note that the system-wide option, while useful, is of marginal
value. Many MTAs want to be able to accept mail for multiple domains
that may have different policies, and any large user community will
probably need to have different policies. Typically there are some
people in an enterprise who _need_ to be able to receive advertisements-
e.g. people who do procurement and who naturally need to know what goods
are available at what prices from which sources.
11. [section 2.8] The ability to relay SOLICIT= SHOULD be enabled by
default. However the default configuration SHOULD NOT impose any
system-wide or per-recipient policy.
An MTA that advertises the EHLO keyword MUST relay SOLICIT= faithfully
to any next-hop MTA that advertises the extension in EHLO.
An MTA that advertises the EHLO keyword MAY implement the ability to
advertise a system-wide policy in EHLO. If such a policy is advertised
it MUST be enforced by rejecting messages for which MAIL FROM asserts
a solicitation class that conflicts with that policy. (It MAY also
be enforced by other mechanisms, e.g. looking at the Solicitation:
field and rejecting messages for which that field conflicts.)
An MTA MAY also implement a system-wide policy without advertising
all of that policy in EHLO.
An MTA that advertises the EHLO keyword MAY implement per-recipient
policies for zero, some, or all of its recipients.
12. [section 3] I think this belongs in an appendix, as it seems
to be non-normative.
13. It is fairly obvious that sites and recipients will want policies
based on reliable characteristics of the message other than a
solicitation class advertised by the sender. e.g. I want to be able to
reject application/ms-word documents. And then we also have things like
the content-negotiation stuff that the fax people want. Given this,
what is the potential for conflicts between these various policy
mechanisms? And should we try to sort them out now or wait until later
when we have more experience with them?
Keith Moore http://www.cs.utk.edu/~moore/